Toda senha precisa de um parceiro discreto

As chaves de acesso melhoram significativamente a segurança da autenticação, mas não resolvem todos os problemas relacionados à identidade. Neste tutorial, você aprenderá por que o cadastro e a recuperação de conta continuam sendo desafiadores, como a Autenticação Silenciosa preenche essas lacunas e como criar o fluxo completo usando a Verify API do Vonage. 

As senhas são o bug mais antigo ainda não corrigido no mundo do software, e as chaves de acesso são a primeira solução que elimina o segredo compartilhado, em vez de apenas realocá-lo. Todas as soluções anteriores, desde códigos de uso único até links mágicos, apenas transferiram esse segredo para um local mais bem protegido. Se você quiser conhecer toda a história disso, bem como as duas etapas que fazem uma chave de acesso funcionar, eu escrevi sobre isso em “Chaves de acesso a partir dos princípios básicos”. 

As chaves de acesso estão ganhando popularidade rapidamente. Ao substituir a senha por um par de chaves pública/privada — em que a chave privada nunca sai do dispositivo do usuário e o servidor mantém apenas a chave pública —, elas fazem com que o phishing deixe de funcionar por natureza. O navegador simplesmente se recusará a usar a chave em um site incorreto, e um banco de dados de credenciais roubadas se torna uma lista de chaves públicas sem valor. 

Apesar de todos esses pontos fortes, porém, as chaves de acesso ainda deixam duas portas desprotegidas. Elas não conseguem identificar quem está na porta na primeira vez que alguém se cadastra, e não conseguem permitir que um usuário legítimo volte a acessar o sistema quando sua última senha de acesso for perdida. Ambas as portas são exatamente onde a Autenticação Silenciosa da Vonage se destaca: ela verifica a posse de um número de telefone usando o cartão SIM e a rede da operadora, sem códigos para digitar e sem nada que um phisher possa interceptar. 

Dois fatores resistentes ao phishing e sem atrito, cada um cobrindo o ponto cego do outro. Vamos ver por que eles se encaixam tão bem e, em seguida, montar o fluxo com a API do Verify v2. 

Como funcionam as chaves de acesso e o WebAuthn 

Chaves de acesso são credenciais WebAuthn. No momento do registro, o dispositivo gera um par de chaves dentro de um hardware seguro e envia a chave pública ao servidor. Ao fazer login, o servidor emite um desafio aleatório, o dispositivo o assina após um gesto biométrico ou a inserção de um PIN, e o servidor verifica a assinatura. Um simples toque com o polegar já constitui uma autenticação multifatorial: algo que você possui (o dispositivo) mais algo que você é (o gesto). Um ponto crucial é que o navegador só oferece uma chave de acesso no domínio para o qual ela foi criada; assim, não cabe mais ao usuário decidir se uma página de login é genuína. 

Autenticação silenciosa verifica um usuário por meio de seu cartão SIM. Seu backend inicia uma verificação com a Verify API v2, recebe um check_url, e o dispositivo do usuário abre essa URL por meio de sua conexão de celular. A operadora confirma diretamente, com base em seus próprios registros, que a solicitação está vindo do dispositivo ao qual pertence aquele número de telefone e retorna uma resposta GSM verificada. Nenhum SMS é enviado, nenhum código de seis dígitos é digitado e não há nada na tela que um invasor possa usar para aplicar engenharia social contra o usuário. A autenticação ocorre diretamente entre a operadora e o dispositivo móvel, o que elimina completamente o clássico esquema de phishing com OTP. 

Observe a simetria: 

• Uma chave de acesso comprova a posse de uma chave privada vinculada ao seu serviço. 

• A autenticação silenciosa comprova a posse de um chip vinculado a um número de telefone. 

Nenhum dos dois fatores revela um segredo ao usuário; portanto, nenhum deles fornece ao usuário um segredo que ele possa divulgar. 

Quando as chaves de acesso precisam de um amigo 

É importante observar que o cadastro, o login e a recuperação de senha não são a mesma pergunta feita três vezes. O cadastro pergunta “quem é essa pessoa?”, o login pergunta “é a mesma pessoa que se cadastrou?” e a recuperação pergunta “é realmente essa pessoa, agora que o meio de identificação que comprovava isso não está mais disponível?”. As chaves de acesso oferecem uma resposta excelente para a pergunta do login e nenhuma resposta para as outras duas. 

O Problema do Primeiro Dia 

Uma chave de acesso só pode comprovar que a pessoa que está fazendo login é a mesma que se cadastrou. Ela não diz nada sobre quem se cadastrou. No primeiro dia, ainda não há uma chave de acesso, então a maioria dos cadastros sem senha recorre ao elo mais fraco de todo o sistema: um endereço de e-mail, não verificado ou verificado por um link que, por si só, é passível de phishing. Se um invasor criar a conta victim@example.com antes da vítima e associar sua própria chave de acesso a ela, você já terá um problema de apropriação antecipada da conta antes mesmo de o usuário ter se cadastrado. 

Vincular o cadastro a um número de telefone verificado de forma silenciosa muda o panorama. O Account é criado com base em um número que a operadora acaba de confirmar como ativo naquele dispositivo, e só então o processo de geração da chave de acesso é executado. A chave de acesso agora amplia criptograficamente uma identidade que você realmente verificou, em vez de uma que o usuário simplesmente digitou. 

O problema do último dispositivo 

A segunda opção é a recuperação. Um usuário com uma chave de acesso vinculada a um único dispositivo está a apenas um celular perdido de ficar sem acesso, e mesmo as chaves de acesso sincronizadas pressupõem que o usuário ainda tenha acesso à sua conta na plataforma. A maioria dos produtos recorre a um link mágico enviado por e-mail, que discretamente reintroduz tudo o que as chaves de acesso removeram: um token de portador, guardado na caixa de entrada, protegido por uma senha. 

O Silent Auth oferece um caminho de recuperação com o mesmo nível de segurança do dispositivo que está sendo recuperado. Novo celular, mesmo número: a operadora garante a autenticidade do SIM, o usuário registra novamente uma senha, e em nenhum momento um código é transmitido por um canal que um invasor possa interceptar. 
O Fluxo Combinado 

Aqui está o ciclo de vida completo: 

1. Cadastro: Verifique o número de telefone com o Silent Auth, crie a Account e, em seguida, registre a primeira senha de acesso. 

1. A partir daí, a cada vez que você fizer login: Apenas com a chave de acesso. Um único gesto, sem necessidade de comunicação com a operadora, funciona em qualquer dispositivo, inclusive computadores de mesa. 

1. Recuperação ou um novo dispositivo sem sincronização: Execute a autenticação silenciosa novamente e, em seguida, registre uma chave de acesso substituta. 

1. Etapa opcional de reforço: Para ações de alto risco (pagamento, alteração de e-mail, adição de uma nova senha a partir de um navegador não reconhecido), execute uma verificação de autenticação silenciosa em segundo plano como um segundo fator independente. 

As chaves de acesso cuidam do dia a dia; o Silent Auth cuida dos casos extremos. Vamos escrever as partes interessantes. 

Pré-requisitos 

• A Account da API da Vonage. Se você ainda não tiver uma, pode <se-inscrever></se-inscrever> hoje mesmo e começar a desenvolver com crédito gratuito. 

• Seu aplicativo foi registrado no Registro de Rede para uso em produção (durante o desenvolvimento, o ambiente de teste (sandbox) cuida de tudo; mais detalhes a seguir). 

• Um backend capaz de manter uma sessão; os trechos abaixo utilizam o curl básico e JavaScript do navegador, para que você possa adaptá-los à sua pilha de tecnologia de sua preferência. 

• Um celular com um chip SIM e dados móveis para testar a etapa de autenticação silenciosa. 

Passo 1: Verifique o número discretamente no momento do cadastro 

Quando um novo usuário insere seu número de telefone, seu backend inicia uma verificação. O array de fluxo de trabalho é onde a mágica acontece: primeiro o `silent_auth`, com um plano alternativo por SMS para os casos em que o Silent Auth não puder ser executado. 

 

curl -X POST https://api.nexmo.com/v2/verify \ 

  -H "Authorization: Bearer $JWT" \ 

  -H "Content-Type: application/json" \ 

  -d '{ 

    "brand": "ACME Inc", 

    "workflow": [ 

      { "channel": "silent_auth", "to": "447700900000" }, 

      { "channel": "sms", "to": "447700900000" } 

    ] 

  }' 

A resposta contém um request_id e, para a autenticação silenciosa, um check_url: 

{ 

  "request_id": "b3a2f4d0-1234-4d6e-9f00-example00000", 

  "check_url": "https://api-eu-3.vonage.com/v2/verify/b3a2f4d0.../silent-auth/redirect" 

} 

Entregue o check_url ao cliente e faça com que o dispositivo o abra por meio de sua conexão de celular. Esse é o único requisito obrigatório do Silent Auth: se a solicitação for enviada por Wi-Fi, a operadora nunca a verá e a verificação falhará. As bibliotecas de clientes da Vonage para iOS e Android existem justamente para forçar a solicitação a ser enviada por dados móveis, mesmo quando o Wi-Fi estiver conectado; portanto, use-as em vez de criar sua própria solução. 

O dispositivo passa por uma curta sequência de redirecionamentos na rede da operadora e retorna com um código, que seu cliente envia para o seu backend, e seu backend o encaminha para Verify: 

curl -X POST https://api.nexmo.com/v2/verify/$REQUEST_ID \ 

  -H "Authorization: Bearer $JWT" \ 

  -H "Content-Type: application/json" \ 

  -d '{ "code": "'$CODE'" }' 

A "status": "completed" significa que a operadora atestou a autenticidade do SIM. O usuário foi verificado e, aqui está a parte que vale a pena saborear: , ele nem percebeu o que aconteceu. Nenhum código chegou, nada foi digitado. Do ponto de vista dele, eles digitaram um número de telefone e foram conectados automaticamente. 

Durante o desenvolvimento, adicione "sandbox": true à entrada do fluxo de trabalho e use o Network Registry Playground, para que você possa testar todo o fluxo sem cobertura da operadora. 

Etapa 2: Registrar a primeira senha de acesso 

Agora, e somente agora, crie a Account e execute imediatamente o processo de registro do WebAuthn. Atualmente, a API nativa do navegador não requer dependências: 

// The server generated these options, including a random challenge 

// and the user object: { id: userHandle, name: phoneOrEmail } 

const options = PublicKeyCredential.parseCreationOptionsFromJSON(optionsJSON); 

 

// The OS prompts for Touch ID / Face ID / Windows Hello and mints 

// the key pair inside secure hardware. The private key never leaves. 

const credential = await navigator.credentials.create({ publicKey: options }); 

 

await fetch("/registration", { 

  method: "POST", 

  headers: { "Content-Type": "application/json" }, 

  body: JSON.stringify({ credential: credential.toJSON() }), 

}); 

Duas configurações do lado do servidor transformam uma credencial comum em uma chave de acesso. Essas configurações exigem um credencial (resident_key: "required") para que o login possa ser feito sem nome de usuário e exijam verificação do usuário para o gesto biométrico. Esteja ciente de que a opção `user_verification` apenas solicita o gesto ao navegador; é a sua etapa de verificação no servidor que também deve verificar o sinalizador de verificação do usuário na resposta do autenticador; caso contrário, um cliente adulterado pode ignorar a verificação biométrica e, discretamente, reduzir seu login multifatorial a um único fator. Com isso verificado, compare a resposta com o desafio que você emitiu, armazene a chave pública, e o Account agora terá uma credencial resistente a phishing vinculada a um número de telefone verificado pela operadora. 

Uma observação sobre o design: o número de telefone que você Verifyou é um ótimo rótulo legível por humanos para a chave de acesso (user.name nas opções de criação), e a especificação WebAuthn lista explicitamente números de telefone ao lado de e-mails e nomes de usuário exatamente para esse fim. Só não o use como identificador do usuário (user.id); esse deve permanecer um identificador aleatório e opaco. 

Etapa 3: Faça login usando apenas a senha de acesso, e nada mais

O login diário nunca envolve a Verify API. O usuário toca em um botão, o navegador exibe o seletor de contas, um único gesto assina o desafio do servidor e pronto. 

Nesse ponto, você pode se perguntar: por que não executar o Silent Auth em todos os logins também, como uma camada extra de segurança? A resposta é que, nesse caso, você estaria pagando por uma cobertura desnecessária e perdendo a cobertura de que realmente precisa. Um login com passkey já comprova a posse de um dispositivo registrado, além de um dado biométrico atual, e funciona em computadores, em redes Wi-Fi e até mesmo em um porão sem sinal — exatamente os lugares onde uma verificação pela operadora não consegue chegar. Cada verificação do Silent Auth também custa uma ida e volta na rede (e uma taxa por verificação). Isso é aceitável para momentos pontuais do ciclo de vida, mas se torna um custo perceptível a cada login. Em outras palavras, reserve a verificação da operadora para os momentos em que a chave de acesso não puder ser utilizada. 

Etapa 4: Recuperação: A mesma porta do primeiro dia 

Quando um usuário perde sua última chave de acesso, a recuperação consiste apenas na Etapa 1, seguida novamente pela Etapa 2: verificar automaticamente o número com o qual ele se registrou, abrir uma sessão de recuperação de curta duração e permitir que ele gere uma nova chave de acesso. O fluxo de trabalho com o recurso de fallback por SMS já lida com casos complicados, como o do usuário cujo novo celular tem um chip, mas que está usando um computador no momento; nesse caso, o Verify simplesmente avança no fluxo de trabalho para o próximo canal. 

Vale a pena ser honesto sobre essa escolha, já que não existe uma solução milagrosa quando se trata da verificação de usuários. : RrA recuperação vinculada a um número de telefone herda o próprio ciclo de vida desse número. Os números são reutilizados, e existe a fraude de troca de SIM; é por isso que a verificação do Silent Auth nos registros da própria operadora para detectar mudanças recentes de SIM representa um padrão de segurança significativamente mais alto do que um código por SMS, e é por isso que você deve tratar a recuperação como um bom momento para um escrutínio extra (notifique todos os outros canais que você possui, adie ações de alto valor e registre o evento). 

Por que essa combinação funciona 

Se dermos um passo para trás, a imagem fica agradavelmente nítida: 

Todo sistema de credenciais apresenta um problema de inicialização e um problema de recuperação, e a maioria das soluções recai discretamente para um canal suscetível a phishing exatamente nesses dois momentos. A combinação de chaves de acesso com a Autenticação Silenciosa mantém todo o ciclo de vida baseado em fatores que nunca revelam um segredo ao usuário. O navegador verifica a origem, a operadora verifica o SIM, e o usuário nunca é solicitado a avaliar nada que um phisher possa falsificar, o que significa que que nunca há um segredo que o usuário possa ser convencido a revelar. 

E esse é o esquema que o título prometia: o Silent Auth é o sócio silencioso. Ele cria o fundo fiduciário que dá início ao empreendimento, volta a agir quando o negócio precisa de ajuda e permanece invisível no restante do tempo, enquanto o passkey cuida da gestão do dia a dia. 

Conclusão 

Se você quiser se aprofundar em qualquer uma das duas partes, o guia de Autenticação Silenciosa aborda a cobertura e o registro no Registro de Rede, enquanto o tutorial “Introdução à Autenticação Silenciosa” apresenta o check_url fluxo de ponta a ponta com um backend em Node.js, e a postagem sobre as melhores práticas aborda em profundidade o projeto de fluxos de trabalho de fallback. 

Você já combinou as chaves de acesso com a autenticação baseada em rede ou está planejando fazer isso? Adoraríamos saber como está sendo essa experiência. Junte-se a nós no Slack da Comunidade Vonage  e no GitHub ou siga-nos no X para se manter atualizado; e se você estiver pronto para começar a desenvolver, <sign-up></sign-up> e comece hoje mesmo com crédito grátis.