Endereço de e-mail é inadequado como identificador 'permanente' de uma conta

Endereço de e-mail não é adequado como identificador 'permanente' de uma conta

• Usar um endereço de e-mail como identificador interno permanente de uma conta é problemático. Os endereços de e-mail das pessoas podem mudar até mesmo dentro de uma organização, por vários motivos, de forma semelhante a mudanças de nome ou de informações de login.
• Pode não ser juridicamente sustentável que uma organização nunca altere nem redefina os endereços de e-mail atribuídos às pessoas.
• Endereços de e-mail podem ser reutilizados ou reatribuídos a uma pessoa específica, o que pode causar problemas de segurança.

Identificadores internos devem ser sem significado

• Mesmo que seja necessário lembrar o endereço de e-mail para recuperação de conta, o identificador interno da conta deve ser algo sem significado. Isso simplifica a administração do sistema no longo prazo.
• Em sistemas de autenticação como o OIDC, deve-se usar um ID interno único e permanente em vez do endereço de e-mail.
• Atribuir significado demais a um endereço de e-mail pode causar problemas de segurança.

Opinião do GN⁺

• O ponto mais importante deste texto é que usar um endereço de e-mail como identificador permanente de conta pode causar vários problemas.
• Este tema é interessante porque muitos sistemas usam endereços de e-mail para autenticação de usuários, mas o texto aponta que essa prática pode gerar riscos potenciais de segurança e problemas de administração.
• Este texto pode ajudar engenheiros de software a ampliar a conscientização sobre aspectos importantes de segurança e administração que devem ser considerados no projeto de sistemas internos.

[GN⁺]

Opinião do Hacker News

• Limitações do e-mail e do nome de usuário

  • Endereços de e-mail podem mudar, e as pessoas podem perder acesso aos e-mails antigos.
  • Há insatisfação com nomes de usuário, e as pessoas querem escolher nomes que não sejam únicos, por exemplo, em vez de algo como user53267.
  • Também há casos em que a pessoa perde o dispositivo, e um UUID secreto armazenado em cookie ou apenas a passkey do dispositivo não bastam.
  • Algumas pessoas têm e-mail ou nome de usuário estáveis, mas quase ninguém usa o mesmo dispositivo principal por muitos anos.
  • Há problemas frequentes com contas de e-mail corporativas ([e-mail]) e com a forma como softwares de fornecedores usam “Entrar com o Google”.
  • As pessoas se casam, se divorciam, fazem transição de gênero e mudam de cultura, escolhendo novos nomes. Nomes e endereços de e-mail mudam.
  • Coisas como OIDC talvez precisem de uma API padrão que permita alterar nome de usuário e endereço de e-mail.

• Medidas pessoais para lidar com isso

  • O Gmail pode ser bloqueado arbitrariamente por algoritmos de IA, e é difícil conseguir ajuda quando algo dá errado.
  • O Yahoo pode exigir autenticação por um e-mail antigo, o que pode levar à perda de acesso.
  • Yahoo/AOL/Tutanota/Protonmail etc. podem excluir contas automaticamente se você não entrar com frequência.
  • Hospedagem própria exige um e-mail inicial, e perdê-lo pode significar perder o acesso à conta de hospedagem.
  • O Duo Push pode virar um problema quando o telefone quebra.
  • A autenticação por SMS pode ser arriscada por causa de telefone quebrado, perda de acesso ao plano ou problemas de segurança envolvendo funcionários.
  • Usar um endereço Gmail da universidade parece ser a melhor opção no momento. Quando há problemas, é possível pedir ajuda ao suporte da universidade.

• Problemas de e-mail e número de telefone

  • E-mail não é um bom identificador permanente, e usar número de telefone como parte da identificação é ainda pior.
  • A pessoa usa o mesmo e-mail há quase 20 anos por meio do próprio domínio, mas nesse mesmo período já passou por quase 12 números de telefone.
  • Está pagando cerca de US$ 150 por mês para a AT&T só para manter um número dos EUA enquanto mora no exterior.

• Proposta de endereços de e-mail com chave pública

  • Foi apresentada a ideia de suportar endereços de e-mail com chave pública (<[e-mail]>).
  • Mesmo que Google ou Hotmail encerrem o serviço, seria possível autenticar em outro serviço com a chave privada e acessar a mesma conta.
  • Isso permitiria que clientes de e-mail mapeassem esses endereços ou os rastreassem pela chave pública.
  • A ideia exigiria suporte em grande escala, mas vale a reflexão.

• Uso de UUID

  • Há quem ache que um UUID aleatório é a melhor opção.
  • Fazer hash do e-mail inicial do usuário talvez não seja suficiente apenas com salting.

• Vincular vários endereços de e-mail

  • O sistema de e-mail está sendo alterado para permitir vincular vários endereços a uma conta.
  • Verificar um e-mail educacional é a forma mais fácil de oferecer desconto estudantil, mas a maioria das pessoas não quer se cadastrar com esse e-mail.
  • Ao permitir vários e-mails, é possível aproveitar o melhor dos dois mundos.

• Problema de vincular endereço de e-mail e endereço físico

  • Há o exemplo de uma fornecedora de energia que não permite usar um mesmo endereço de e-mail para vários endereços físicos.
  • Isso causa problemas ao configurar contas online, porque não é possível reutilizar o mesmo e-mail.

• Soluções no lado do cliente

  • É possível pagar por um domínio e ter controle 100% sobre aliases de e-mail.
  • Mesmo que haja problema com o provedor atual (Google), dá para hospedar o e-mail em servidor próprio, localizar a conta e manter a posse do alias.

• Problemas de identificação e autenticação

  • Existe um problema em tratar identificação e autenticação como se fossem a mesma coisa.
  • O problema de identificação está praticamente resolvido com strings ou números únicos ligados a humanos, como nome, e-mail ou documento.
  • O problema de autenticação é verificar quem a pessoa realmente é, e esse é um dos maiores desafios da tecnologia moderna.
  • Usa-se uma combinação de senha, localização geográfica, endereço IP, e-mail, número de telefone, token de segurança e certificados, mas esses sistemas são comprometidos regularmente, e reforçar a segurança costuma prejudicar usuários legítimos.

• Problema de backend

  • Para o usuário, o e-mail é o ID, mas dentro dos dados do sistema ele não deve ser usado como chave primária.
  • Isso é uma questão básica de modelagem de banco de dados: em vez de usar um identificador como e-mail, deve haver uma tabela de consulta que o associe a um ID único (UUID ou um valor autoincremental de sequência).
  • O artigo não deixa essa distinção clara, e pode dar a entender que o usuário precisa estar ciente dessa abstração.