O SRP evita enviar a senha na troca de login; não torna inofensivo um verificador roubado.
Secure Remote Password, ou SRP, permite que um cliente e um servidor se autentiquem usando uma senha sem enviá-la na troca normal do protocolo. Isso pode reduzir a exposição a um servidor que, de outra forma, receberia a senha durante o login.
Isso não remove do servidor todos os segredos relacionados à senha. O servidor mantém um verificador, e um verificador roubado pode permitir tentativas de adivinhar a senha offline. Essa distinção é essencial ao avaliar afirmações sobre “login de conhecimento zero”.
O que muda em relação a um login convencional com senha?
Em um projeto convencional, o cliente envia a senha por uma conexão TLS autenticada. Um servidor bem projetado compara um hash de senha adequado com salt, evita registrar credenciais em logs e aplica proteções contra tentativas de adivinhação. O TLS protege a conexão; o hash protege a credencial armazenada de outra forma.
O SRP altera a troca. Durante o cadastro, o sistema estabelece o salt e o material do verificador. No login, ambos os lados usam valores novos do protocolo e seus respectivos segredos para estabelecer e confirmar material de chave compartilhado. O cliente usa a senha; o servidor usa seu verificador. Um cliente honesto não envia a própria senha como conteúdo do login.
A especificação do SRP no RFC 2945 explica a base do protocolo. Perfis e implementações posteriores precisam ter seus parâmetros exatos e verificações de mensagens revisados; chamar um projeto de “SRP” não demonstra que todas as escolhas de implementação são corretas.
| Pergunta | Login convencional com senha sobre TLS | Troca SRP implementada corretamente |
|---|---|---|
| O servidor da aplicação recebe a senha digitada no login? | Normalmente sim | Não como parte da troca do protocolo |
| Que material sensível de autenticação é armazenado? | Em geral, um hash de senha com salt | Salt e um verificador derivado da senha |
| Uma base roubada pode permitir tentativas offline? | Sim, dependendo do material armazenado | Sim, material roubado de verificadores SRP pode permitir tentativas |
| Protege contra um keylogger? | Não | Não |
| Criptografa automaticamente o histórico de mensagens? | Não | Não |
Por que um verificador roubado ainda importa
A seção 3.3 do RFC 5054 discute explicitamente verificadores roubados. Ela explica que um verificador pode permitir que um invasor se passe pelo servidor e realize ataques de dicionário para recuperar a senha.
A distinção importante é que o verificador não é simplesmente um token reutilizável de login do cliente. Isso não o torna inofensivo. Um invasor pode testar senhas candidatas contra o material roubado, em vez de resolver um problema de logaritmo discreto para cada segredo possível. Uma senha fraca ou reutilizada continua sendo um risco sério.
Limites de tentativas online podem retardar ataques a um serviço ativo, mas não controlam cálculos realizados sobre uma base roubada. A proteção da base, o processamento cuidadoso de senhas e senhas fortes e únicas continuam relevantes.
O que o SRP não protege
Um dispositivo comprometido: Malware pode capturar a senha antes de o protocolo começar ou roubar uma sessão autenticada depois.
Uma página de login maliciosa: Se a própria página que pede a senha for hostil, ela pode enviar o texto digitado para outro lugar. Uma aplicação web ainda precisa de um caminho de entrega confiável.
Todos os caminhos de recuperação: Um fluxo por e-mail, SMS ou suporte que conceda acesso à conta tem seus próprios requisitos. O método normal de login mais forte pode ser prejudicado por uma alternativa mais fraca.
Todo ataque ativo de rede: Parâmetros do protocolo, validação de entradas, confirmação mútua e a conexão autenticada ao redor importam. Não substitua as proteções TLS prescritas para uma implantação pelo slogan “a senha nunca trafega”.
Metadados ou criptografia do chat: A autenticação responde se uma sessão deve ser admitida. Não determina quais registros de conversa existem nem quem possui as chaves para descriptografar mensagens.
Como a Livara separa login de recuperação de identidade
A visão geral de segurança da Livara descreve a autenticação SRP separadamente de seu protocolo de mensagens LVR1. Também documenta um backup criptografado de identidade da versão 7, protegido por uma chave de recuperação aleatória e distinta de 256 bits.
O backup é selado antes do envio e restaura a identidade criptográfica, não o histórico do chat. Saber apenas a senha da conta não restaura essas chaves de criptografia. Por outro lado, afirmar que o suporte não consegue reconstruir um segredo de criptografia não demonstra que nenhuma ação de gerenciamento da conta ou processo de alteração de senha possa existir.
O modelo de ameaças também mantém no escopo o comprometimento do dispositivo e os metadados visíveis da comunicação. O SRP não deve ser usado para reclassificar o serviço inteiro como tendo “conhecimento zero” sobre todos os aspectos da atividade de um usuário.
Uma lista prática de avaliação
Como usuário, escolha uma senha forte e única, proteja o dispositivo, mantenha o material de recuperação em um local separado e adequado e entenda como as sessões são revogadas. Não digite um segredo em um site não confiável só porque ele afirma usar SRP.
Como revisor técnico, solicite o perfil exato do protocolo, o processamento de senha para verificador, a validação de entradas, o tratamento de falhas, o fluxo de cadastro e o projeto de redefinição. Revise cliente e servidor em conjunto. Inclua testes de valores públicos inválidos, repetição de mensagens e sessões interrompidas, em vez de depender apenas de um teste de login bem-sucedido.
O SRP é uma ferramenta útil para limitar a divulgação de senhas durante a autenticação. Seu valor fica mais claro quando seus benefícios reais são descritos junto dos riscos de roubo de verificadores, comprometimento de dispositivos e recuperação, em vez de ser apresentado como o fim dos problemas de segurança de senhas.
