O SRP não envia a senha no protocolo; isso não equivale a eliminar senhas, ser imune a phishing ou tornar o verificador inofensivo.
Passkeys e SRP são duas formas diferentes de autenticação. Uma passkey utiliza um par de chaves e pode eliminar a necessidade de uma senha. O SRP continua baseado em senha, mas, na execução correta do protocolo, não envia a própria senha ao servidor para provar que ela é conhecida.
Portanto, “entrar sem enviar uma senha” não é o mesmo que “entrar sem ter uma senha”. A escolha entre esses métodos deve se apoiar no risco de phishing, na gestão de credenciais, na recuperação e na qualidade da implementação, não no rótulo genérico de “conhecimento zero”.
O que uma passkey muda?
Na autenticação com passkeys, o serviço guarda a chave pública e o usuário confirma o login por meio do controle da chave privada. Vincular a credencial ao serviço e à origem correspondentes é uma parte importante da resistência desse método a phishing. Explicação da FIDO sobre passkeys.
Nem todas as passkeys são necessariamente sincronizadas na nuvem. Algumas ficam vinculadas a um dispositivo ou a uma chave de segurança; outras são transferidas entre dispositivos por meio do provedor de credenciais. O modelo de recuperação e a proteção da sincronização precisam ser examinados para aquele provedor específico. A expressão “sincronização na nuvem”, por si só, não permite concluir que a empresa guarda as chaves em formato legível.
A segurança da sessão após o login também é uma questão separada. Uma passkey não neutraliza automaticamente malware no dispositivo nem o roubo de uma sessão válida.
O que o SRP fornece ao servidor?
O SRP pertence à família de troca de chaves autenticada por senha. Em vez de guardar a própria senha, o servidor mantém dados como um salt e um verificador, ou verifier. Ao trocar mensagens do protocolo, as duas partes verificam o conhecimento do segredo e a chave compartilhada.
Mas o verificador não é um dado inofensivo. A seção 3.3 da RFC 5054 afirma explicitamente que um invasor que obtiver o verificador pode realizar um ataque de dicionário para adivinhar a senha. Portanto, é incorreta a alegação de que “o roubo do banco de dados não oferece nenhuma possibilidade de tentativa offline”.
Uma senha forte, proteção do servidor, parâmetros adequados, validação das entradas e controle das tentativas de login continuam necessários. O SRP também não garante que a página na qual você digita a senha seja segura; código malicioso pode capturá-la antes da execução do protocolo.
Uma comparação justa
| Pergunta | Passkey | SRP |
|---|---|---|
| O usuário memoriza uma senha do serviço? | Geralmente não; é necessário controlar a credencial | Sim, o método depende do conhecimento da senha |
| O que o serviço guarda para o login? | Chave pública e informações relacionadas | Verificador e parâmetros relacionados |
| Como se obtém resistência a phishing? | Vinculação da credencial ao serviço/origem no projeto da FIDO | Não enviar a senha no protocolo não basta para tornar segura uma entrada falsa |
| A nuvem é obrigatória? | Não; também existem opções vinculadas ao dispositivo | O protocolo não exige inerentemente um provedor de identidade terceirizado, mas precisa de um serviço de autenticação |
| Como ocorre a recuperação? | Depende do tipo de credencial e do provedor | É definida pela política da conta e do produto, não pelo nome SRP |
Essa tabela não permite criar uma classificação absoluta para todas as implementações. Um fluxo de recuperação fraco pode enfraquecer a vantagem de um método de login forte.
Qual é a relação entre o login da conta e as chaves de chat?
A autenticação informa ao serviço quem tem permissão para agir. As chaves de criptografia das mensagens determinam quem pode abrir o conteúdo. Um produto pode relacionar essas duas coisas, mas essa relação precisa estar documentada.
Na documentação de segurança da Livara, o SRP é descrito para o login, enquanto o pacote de recuperação v7 para a identidade criptografada é apresentado separadamente. Esse pacote recupera a identidade, não o histórico de chat. Por isso, “a senha de login está correta” não significa “todas as chaves e mensagens antigas foram recuperadas”.
Este artigo é uma comparação conceitual, não um teste prático de todos os métodos de login da Livara nem uma confirmação da implementação exata de uma RFC no produto.
O que perguntar ao escolher?
- Se o dispositivo for perdido, qual é a alternativa para entrar e quem a controla?
- O método de recuperação é mais fraco que o login principal?
- Como as sessões desconhecidas são visualizadas e revogadas?
- Mudar o método de login altera as chaves das mensagens ou os dispositivos vinculados?
- Para sincronizar credenciais, qual conta e qual proteção independente são necessárias?
Conclusão: Não classifique passkeys como inerentemente “inseguras porque estão na nuvem”, nem o SRP como “imune a invasões porque usa conhecimento zero”. Os limites de cada método e a política de recuperação do produto são a base de uma comparação confiável.
