Melhorar a Exibição de Erros de Autenticação about tabnews.com.br

[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. #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. #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. #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.