Práticas recomendadas para gerenciar a lógica de repetição com a 2FA por SMS

Práticas recomendadas para gerenciar a lógica de repetição com a 2FA por SMS

Seres humanos são criaturas impacientes. Embora os códigos de verificação por SMS ou autenticação de dois fatores (2FA) possam ser enviados rapidamente na maioria das partes do mundo, sempre recomendamos a criação de buffers de nova tentativa em fluxos de trabalho de verificação. Isso ajuda a evitar:

• Enviar spam acidentalmente a um usuário com mensagens de texto repetidas
• Atingir os limites de taxa de API
• Fraude de tarifação ou gastos desnecessários

Embora as práticas recomendadas neste artigo tenham sido escritas com a API de verificação da Twilio em mente, muitas se aplicam a qualquer provedor de 2FA. Combinado com outras práticas recomendadas, como a criação de uma lista de códigos de países permitidos para verificação, essas etapas podem ajudar a garantir que o fluxo de trabalho de verificação do usuário seja o mais uniforme possível.

Iniciar um aplicativo de demonstração com as práticas recomendadas de repetição de SMS

Eu desenvolvi um aplicativo que mostra as práticas recomendadas descritas neste post. O aplicativo é rápido de iniciar, pois foi criado com o Twilio Functions, o ambiente sem servidor da Twilio. Você pode usar seu próprio aplicativo, seguindo estas instruções.

Os pré-requisitos incluem:

• Node.js
• Uma conta Twilio gratuita. Cadastre-se gratuitamente neste link e receba $10 em crédito ao atualizar sua conta.
• Um Serviço Verify. Crie um no Console da Twilio.

Clone ou baixe o projeto de amostra no meu GitHub:

Instale as dependências com npm install. Em seguida, renomeie o  arquivo.env.example para .env (por segurança, o arquivo .env faz parte do .gitignore e não será comprometido com a fonte) e preencha as variáveis com seu SID de conta e token de autenticação, que podem ser encontrados no Console da Twilio. Preencha o SID do Serviço Verify que você criou anteriormente:

Inicie o projeto com npm start e navegue para http://localhost:3000/index.html para testar.

Práticas recomendadas para tentar novamente códigos SMS 2FA

Implementar tempos limite no botão reenviar.

Adicione um buffer entre as tentativas para evitar comportamento indesejado ou o envio acidental de vários códigos. Recomendamos começar com 30 segundos.

Na demonstração, fazemos a contagem regressiva do tempo limite máximo e mantemos o botão desativado até que o tempo limite tenha expirado. Para uma alternativa menos animada, você pode:

• exibir a contagem regressiva com 5 segundos restantes
• esmaecer o botão reenviar até que o tempo limite tenha expirado com a cópia que informa o buffer total (sem contagem regressiva)
• exibir o link de nova tentativa somente depois que o tempo limite tiver expirado

Rastrear tentativas de repetição.

A API Verify inclui uma lista de tentativas de verificação na resposta, que você pode usar para aumentar o buffer de nova tentativa com cada tentativa adicional. Você também pode usar o número de tentativas para impor seus próprios limites de taxa além dos limites de taxa do Verify API (5 verificações começam em um período de 10 minutos).

Um exemplo de aumento do tempo limite com mais tentativas pode ser visto nesta função. O tempo limite padrão aqui é o máximo (10 minutos) que pode ajudar a impedir que seu aplicativo atinja os limites de taxa de API.

Práticas recomendadas para canais de substitutos

Oferecer canais alternativos, como chamada de voz na 3a tentativa de verificação

A chamada de voz tem prioridade em redes de telefonia e pode ajudar a garantir que seus clientes recebam um código de verificação. No entanto, o canal de voz pode ser utilizado de maneira inadequada para fraude de tarifação portanto, a menos que você detecte um telefone fixo ou tenha um caso de negócios para chamadas, recomendamos aguardar para expor este canal até que a 3ª ou 4ª tentativa de envio de SMS seja feita ou desabilitá-los todos juntos.

Exiba a opção "Ligue para mim em vez disso" em sua experiência de usuário depois que várias tentativas de SMS forem feitas:

Detectar telefones fixos

Além de usar a API Lookup do Twilio para detectar números de telefone inválidos, você pode usar a API para detectar números de telefone fixo e usar o canal call para esses números em vez de padronizar para SMS.

Se você inserir um telefone fixo no projeto de exemplo, ele ligará automaticamente em vez de enviar uma mensagem de texto para o código de verificação.

Desativar os canais não utilizados no Console da Twilio

Se você deseja desativar certos canais, você pode fazer isso na Seção de verificação do console Twilio.

Implementar reCAPTCHA para chamadas de voz

Implemente reCAPTCHA para ajudar a detectar e evitar bots em seu fluxo de verificação. Saiba mais sobre como implementar esse recurso na documentação do desenvolvedordo Google.

Adicionar limites de taxa adicionais

A API Twilio Verify suporta limites de taxa programáveis que você pode aplicar a segmentos específicos com base na solicitação, como um endereço IP, uma geolocalização ou um código de país.

Práticas recomendadas gerais de verificação do usuário

A lógica de repetição é um componente da criação de um fluxo de trabalho contínuo de verificação de usuário. Algumas outras práticas recomendadas incluem:

1. Usar a API Lookup do Twilio para detectar números e tipos de linha inválidos antes de enviar uma verificação

Além de usar o Carrier Lookup para identificar telefones fixos, o Lookup pode ser usado para identificar números inválidos antes de você tentar enviar um código de verificação.

2. Criar uma lista de permissão ou bloqueio de países

Usar uma lista de permissão de países na inscrição é uma ótima maneira de garantir que você esteja atendendo aos requisitos de conformidade, reduzindo fraudes ou controlando de outra forma seu pipeline de integração.

3. Exibir os números de telefone completos para a verificação inicial do usuário

Para casos de uso de verificação por telefone (em oposição ao login contínuo ou autenticação de dois fatores), exiba o número de telefone completo na interface para que o usuário possa detectar erros de digitação.

4. Mascarar números de telefone para login ou autenticação de dois fatores

Assim que o número de telefone for verificado pela primeira vez, os usos subsequentes devem mascarar o número de telefone para evitar o vazamento de PII. Ao contrário do anterior, não há opção de editar um número de telefone para autenticação contínua. Recomendamos expor 3 ou 4 números e mascarar o resto como +1 (5**) ***-**67 ou ********567.

Opcional: implantar o projeto com o Twilio Functions

Para implantar este projeto com o Twilio Functions, você precisa:

• A Twilio CLI. Siga as instruções para instalar e fazer login aqui.
• O plugin Twilio Serverless

Depois de instalar essas dependências, você pode implantar este projeto executando o seguinte comando da pasta verify-retry:

Próximas etapas com verificação do usuário

Como disse a pesquisadora de privacidade utilizável Miranda Wei, devemos pensar em construir a segurança utilizável como uma forma de "atendimento ao cliente, nos casos em que buscam mais segurança, sendo esse tópico algo que está em constante mudança. Não é algo que você pode definir apenas uma vez e esquecer". Essas práticas recomendadas são um bom começo, mas recomendamos monitorar seus custos de suporte e a satisfação do usuário para garantir que você esteja fornecendo a melhor solução à medida que seu produto e as tecnologias de autenticação evoluem.

Para mais recursos, você pode verificar:

• Cinco motivos pelos quais o SMS 2FA não se tornará obsoleto
• A 2FA baseada em e-mail é uma boa ideia?
• Práticas recomendadas para proteger chamadas recebidas para a sua central de contato
• Implantar rapidamente um projeto de Verificação de senha única (OTP)

Mal posso esperar para ver o que você vai criar e proteger!