Melhorar a Exibição de Erros de Autenticação

[esmsena]

Descrição

Atualmente, quando os usuários tentam fazer login, a aplicação apenas exibe uma mensagem genérica de erro caso ocorram problemas de autenticação, como "Dados não conferem". No entanto, essa abordagem não fornece informações detalhadas o suficiente para que os usuários corrijam seus erros facilmente.

Sugestão de implementação

Sugiro aprimorar a forma como os erros de autenticação são exibidos, para oferecer uma experiência mais informativa e útil aos usuários. Aqui estão algumas sugestões:

1. Exibição Individual de Erros: Ao invés de uma mensagem genérica, a aplicação deve identificar e exibir cada tipo de erro de forma individual. Por exemplo, se o email estiver incorreto, a mensagem deve especificar "Email inválido". Se a senha estiver errada, a mensagem deve indicar "Senha incorreta". Se a senha e o email estiverem incorretos , a mensagem deve especificar "Email e Senha inválidos"

2. Detalhes Adicionais: Além de identificar o tipo de erro, a mensagem de erro também deve fornecer detalhes adicionais quando possível. Por exemplo, se o email fornecido não estiver registrado no sistema, a mensagem pode sugerir isso..

3. Feedback Orientado para Ação: As mensagens de erro devem ser formuladas de maneira a orientar os usuários sobre como corrigir o problema. Por exemplo, se o email estiver incorreto, a mensagem pode incluir uma sugestão para verificar se o email foi digitado corretamente. Se a senha estiver incorreta, a mensagem pode encorajar o usuário a tentar novamente, lembrando da contidade mínima de 8 caracteres, ou futuramente se adicionado ao cadastro de usuário, lembrando da sensibilidade a maiúsculas/minúsculas.

Benefícios Esperados:

• Melhor experiência do usuário durante o processo de autenticação.
• Redução da frustração dos usuários ao lidar com problemas de login.
• Aumento da eficácia na resolução de erros por parte dos usuários.

Observações:
Este é um passo importante para melhorar a usabilidade e a eficácia do processo de autenticação em nossa aplicação. Implementar essa melhoria não apenas tornará mais fácil para os usuários corrigir seus erros, mas também contribuirá para uma experiência geral mais positiva com nossa plataforma.

[Rafatcb]

@esmsena obrigado pela sugestão! Você tem razão quando diz que isso tornaria a usabilidade melhor: para o usuário que esqueceu algo para acessar a conta, ficaria bem mais fácil. O ponto é que o sistema está desse jeito por questões de segurança. Por exemplo:

1. A mensagem de rate-limit no endpoint /sessions (para realizar login) é uma mensagem de "Dados não conferem" e com uma lentidão falsa, como se estivesse verificando os dados. Implementa Rate Limit na API: /api/v1/sessions #635
2. A escolha por usar a mesma mensagem de erro foi consciente, e isso faz com que um invasor tenha dificuldade em saber se uma conta com aquele e-mail existe ou não. Usa email + senha para criar sessões #201 (comment)
3. Existe um issue aberto para a requisição de login demorar o mesmo tempo caso o usuário exista ou não. A validação de email+senha deve tomar o mesmo tempo quando o usuário existe ou não #186

Essa resposta no Security Stack Exchange fala um pouco mais sobre isso.

Agora, eu não acho que estamos fazendo do jeito certo. Por exemplo, vamos supor que eu queira acessar a conta de alguém que não tenho certeza do e-mail. Pelo login, não consigo descobrir se o e-mail está cadastrado, mas pela recuperação de senha eu consigo:

E também no cadastro, que já é um fluxo mais complicado para a pessoa descobrir se a conta existe, porque num teste de força bruta acabará criando contas sem querer, até cair no firewall:

Então eu acredito que temos duas opções:

1. Mudar as mensagens de erro no login. Isso impactará na mensagem de rate limit, que se for diferente, ficará fácil de perceber que a pessoa já está sem cota de requisições.
2. Mudar as outras mensagens de erro (cadastro e recuperação de senha). No caso de recuperação de senha, acho que é uma prática comum uma mensagem do tipo "Um e-mail foi enviado caso a conta exista" ou algo parecido. Já no cadastro, não sei como poderia ficar.

Quem puder contribuir nesse assunto, será ótimo.

[aprendendofelipe]

Pelo público do TabNews, acho que vale a pena priorizar a segurança ao invés de mostrarmos erros específicos em caso de falhas de login.

Tanto que ainda está pendente a #186, que tem como uma das intenções, evitar qualquer maneira de descobrir se um email já está cadastrado no sistema, o que implica não só em falsificar um tempo de validação de senha, mas também devolver mensagens padronizadas no cadastro e recuperação de senha.

[Rafatcb]

Então, para organizar aqui, o que precisamos fazer para resolver este issue é:

• Mudar a mensagem de erro no cadastro caso o e-mail já esteja utilizado. (não sei qual mensagem utilizar, seria bom ver como outros sites lidam com isso)
• Mudar a mensagem na recuperação de senha para algo neutro, do tipo "Um e-mail foi enviado caso a conta exista".

Caso alguém tenha sugestões para a mensagem no cadastro, pode comentar. Acredito que mudar para algo como "Não é possível utilizar este e-mail" já seja uma mudança positiva, visto que ainda fica claro qual é o erro, mas não fica claro se existe uma conta com esse e-mail, ou se uma conta já o utilizou e ela foi banida etc. Acho que mudar para algo genérico como "Dados inválidos, tente novamente" ou qualquer coisa assim, seria uma experiência bem pior.

O que vocês acham?

[aprendendofelipe]

@esmsena, você foi citada na publicação sobre as novidades do TabNews 🎉

https://www.tabnews.com.br/FelipeBarso/tabnews-5k-no-github-melhorias-de-seguranca-e-mais-novidades