O padrão “o e-mail é a autenticação”

• Alguns usuários, em vez de lembrar ou gerenciar senhas, usam o processo de “esqueci minha senha” toda vez, como se fosse a forma de login
• Na prática, o fluxo consiste em receber um link de recuperação por e-mail na página de login, inserir uma senha temporária e repetir o mesmo processo na visita seguinte
• Esse hábito está mais próximo de um comportamento aprendido que se consolidou com o tempo do que de uma estratégia de segurança consciente
• Melhorias como gerenciadores de senhas e autenticação em duas etapas ou multifator também podem ser percebidas pelos usuários mais como aumento de atrito do que como reforço de segurança
• O design do sistema precisa partir do comportamento repetido do usuário e guiá-lo naturalmente para formas melhores de uso

---

Recuperação de senha usada como login

• Alguns usuários não digitam a senha ao entrar em contas online e, em vez disso, repetem o processo de recuperação toda vez
  • Chegam à página de login
  • Clicam em “I forgot my password”
  • Vão até o e-mail
  • Clicam no link de recuperação
  • Digitam uma senha temporária que não vão lembrar
  • Depois repetem o mesmo processo
• Quando se pergunta por que fazem isso, eles não conseguem responder ou dizem que nunca pensaram no motivo
• Esse comportamento não é uma estratégia de login definida pela manhã, mas algo mais próximo de um procedimento repetitivo que se fixou com o tempo

O atrito que melhorias de segurança criam para o usuário

• Esse método funciona como uma solução de baixo esforço, já que o usuário não precisa lembrar uma passphrase
• Gerenciadores de senhas, roubo de identidade, autenticação em duas etapas e multifator, e o envelhecimento do modelo de nome de usuário/senha já são temas amplamente discutidos
• Procedimentos de segurança melhores muitas vezes aumentam barreiras e atrito, o que pode dificultar sua adoção natural pelos usuários
• Os designers precisam considerar o comportamento aprendido dos usuários e criar fluxos que permitam migrar, ao longo do tempo, para formas melhores de uso

[GN⁺]

Opiniões no Hacker News

• Contas de e-mail são o denominador comum mais universal na autenticação online. Celulares também são competitivos, mas podem ser perdidos; números de telefone são mais comuns e duradouros, mas têm um nível de segurança muito inferior ao de contas dos principais provedores de e-mail.
  Para projetar um “sistema de autenticação imaginário para a internet”, é preciso olhar primeiro para a recuperação de conta. Se, quando você perde seu autenticador sofisticado, a resposta é “simplesmente perdeu o acesso” ou “um painel de colegas atesta sua identidade”, então esse sistema só funciona se tiver como usuários não seres humanos, mas formas de vida inteligentes imaginárias.

  • Esse foi o principal motivo pelo qual me opus a blockchain/criptomoedas por anos. O modelo “se você perde a chave, perde a carteira” é fundamentalmente incompatível com usuários reais.
    Humanos precisam conseguir se recuperar de erros.
  • Identidades digitais emitidas pelo governo poderiam resolver grande parte desse problema. Teriam seus próprios problemas, mas delegar a identificação pessoal ao governo parece mais valioso e menos arriscado do que ficar sujeito ao bloqueio de conta por empresas como o Google.
  • Infelizmente, mesmo nos principais provedores de e-mail, como o Google, “simplesmente perdeu o acesso” é um padrão comum. Pessoas que perdem o celular ou têm o aparelho roubado e acabam bloqueadas permanentemente fora da conta mostram isso bem.
  • Mesmo “conta de e-mail de um grande provedor” vem com a ressalva de “suspenderam minha conta sem motivo, não há como recorrer e nem dizem por que ela foi suspensa”.
  • O modelo em que um painel de colegas atesta a identidade de uma pessoa é um problema de design interessante. Se houvesse um sistema comum capaz de recombinar segredos de autenticação devidamente distribuídos conforme as instruções das partes envolvidas, talvez desse para tornar isso bastante fluido.
    Dá para fazer funcionar para pessoas comuns? Acho que há criatividade suficiente para projetar algo assim.

• Nosso serviço é um negócio bem leve, então os usuários usam a conta apenas por conveniência. O modelo em que nos estabelecemos é este: o usuário informa o e-mail, enviamos um código de verificação por e-mail e, quando o usuário digita o código, emitimos um cookie de duração muito longa que o mantém logado praticamente por tempo indeterminado.
  Não importa se a conta já existe; se for um e-mail novo, basta criar uma conta nova. Às vezes usuários com vários e-mails criam uma conta nova por engano, mas a conversão de cadastro e login melhorou bastante, então vale a pena aceitar isso. O tempo de validade do código e o número de tentativas exigem análise de risco e, se possível, é melhor usar um mecanismo de bloqueio. Se o serviço não for tão crítico, recomendo essa estratégia. O iOS Mail agora também oferece suporte a esse fluxo, como o recurso de códigos de uso único do Messages, então para alguns usuários ele é bem conveniente.

  • Pelos dados que vi, esse modelo é disparado o melhor para maximizar a receita de e-commerce.
    Não force o comprador a criar uma conta; peça apenas os detalhes necessários. O navegador vai preencher automaticamente de qualquer forma. Depois envie por e-mail um link para consultar o status do pedido e, no próximo pedido, peça o e-mail novamente. O atrito adicional causa uma perda de receita maior do que o benefício de obter um “usuário cadastrado”.
  • Opero um pequeno app B2C em que os usuários se cadastram apenas com o endereço de e-mail, e simplesmente não há campo de senha. A conta é criada e, naquele dispositivo, o usuário fica logado por tempo indeterminado.
    Só quando precisa entrar por outro dispositivo é que ele pode solicitar uma nova senha. Isso reduz o atrito no cadastro e as senhas fracas. A maioria das pessoas quase nunca precisa fazer login em outro dispositivo mesmo.
  • Já implementei esse tipo de login várias vezes, e ele veio da experiência de ter que remover inúmeras suposições sobre o que é uma “conta de usuário”. Na prática, para fazer o funil funcionar do jeito que ambos os lados querem, esse tipo de simplificação foi necessário.
    Se não for uma área em que a anonimidade precise ser preservada, dá para fazer assim e integrar passkeys depois. A desvantagem é que o compartilhamento de senhas se torna impossível, então é preciso pensar mais cedo no problema de gerenciar vários usuários em uma única conta. Mas, se isso for tratado conscientemente, o funil ou a experiência do usuário acabam melhorando. Além disso, a segurança fica vinculada ao nível médio de segurança dos provedores de e-mail dos usuários, mas em geral isso é melhor do que o necessário. Senhas podem ser usadas depois como um segundo fator, quando se tornarem necessárias, ou outro fator pode ser adicionado; em B2B, dá para ir direto para SAML ou OIDC. Em B2B ou D2C isso sempre funcionou bem, e os casos excepcionais valeram a pena resolver por causa do ganho de aquisição.
  • Já vi esse tipo de login; não daria para enviar no e-mail um link que leva à tela inicial do app já com o usuário logado?
    Copiar o código, encontrar a aba em que a página de login ficou aberta e colar é um processo trabalhoso.
  • Usei esse modelo em um pequeno app CRUD quase de formulário único e, durante a campanha, os pedidos de suporte ficaram próximos de zero, então valeu muito a pena.

• A essa altura, não bastaria enviar para o endereço de e-mail um link de URL descartável e permitir login com um clique? Ele poderia expirar em 10 minutos e ser invalidado após um único uso.
  Claro que qualquer pessoa que tiver o link primeiro pode entrar na conta, mas, de qualquer forma, o acesso só vem pelo e-mail. Qualquer sensação de segurança além da conta de e-mail desaparece, mas a realidade já chegou a esse ponto. Se você usar por mensagem no celular um padrão como “clique para confirmar o login: www.someurl.com?p=134234535”, isso vira uma autenticação de dois fatores sem precisar digitar um código idiota.

  • Vários web apps usam esse modelo, mas ele é confuso para o usuário (“por que já existe uma conta? Eu nunca me cadastrei!”), tem custo (envio de e-mail não é gratuito) e também é lento.
    O e-mail pode cair no spam, o usuário pode ficar horas sem conseguir entrar por causa de greylisting, ou pode levar 1 minuto para chegar — e às vezes até isso parece tempo demais. Não sei se eu recomendaria.
  • Odeio quando um site que oferece só esse método não consegue enviar o e-mail em 30 segundos.
    No caso de “clique para confirmar o login” enviado ao celular, é preciso fornecer tanto o código quanto o link. O dispositivo em que você está tentando entrar nem sempre é o celular, então deve ser “digite 1234 ou clique”.
  • Alguns sites, como o Netdata, fazem isso.
    Mas é mais lento do que um gerenciador de senhas preencher automaticamente a combinação de nome de usuário/senha, porque é preciso esperar o e-mail e clicar no link.
  • Estou criando um web app exatamente com esse fluxo de login, e tive problemas no mobile. Apps como o Gmail não permitem copiar o link para o navegador sem pré-visualização, e essa pré-visualização consome o link (next.js auth).
    Eu não quero fazer login no navegador embutido do Gmail, e sim no navegador normal, o que é bem irritante.
  • Nesse caso, é melhor ir até o fim com single sign-on. 95% dos usuários vão usar Gmail, Outlook ou Apple de qualquer forma.
    Um botão “Entrar com o Google” é melhor do que “enviar link por e-mail”, e o rastreamento é possível de qualquer maneira.

• A ideia de que uma pessoa vai criar e lembrar uma senha para cada serviço insignificante não é realista. Criar mais um sistema de autenticação baseado em senha é quase uma encenação de faz de conta
  Senhas geralmente são usadas de uma de duas formas: um gerenciador de senhas protegido por uma senha real, ou a mesma senha repetida em cada serviço. Como quase todos os serviços oferecem recuperação por e-mail, na prática o e-mail é o meio de autenticação. O e-mail pessoal não costuma ser trocado, não é compartilhado e também não é reutilizado. Provavelmente você usa seu e-mail pessoal há mais tempo do que seu número de telefone. Enquanto uso meu endereço de e-mail atual, meu número de telefone mudou pelo menos cinco vezes, e esses números agora estão sendo usados por outras pessoas

  • Também existem senhas derivadas, que são uma espécie de híbrido. Pode ser um padrão que a pessoa memoriza, ou uma ferramenta de gerenciamento que calcula por domínio
    E a função de recuperação de senha pelo menos informa ao dono do endereço sobre todas as tentativas. O login baseado em senha nem sempre envia um e-mail a cada login feito de um novo local
  • A Apple tornou muito melhor o processo de “não basta digitar a senha do 1Password/Keychain, é preciso incomodar por e-mail”. Pelo menos quando reconhece um e-mail ou SMS e preenche o código por você

• A resposta é simples. Normalmente tem a ver com incômodos que o provedor do serviço criou para o usuário. Neste caso parece claro: a sessão do provedor de e-mail geralmente praticamente nunca termina e continua logada a menos que você limpe o cache do navegador
  Basta fazer com que o token de autenticação do próprio serviço tenha a mesma duração do Gmail e, como alternativa, permitir login sempre com senha de uso único. Mas é preciso parar com práticas blasfemas como tokens de autenticação de 12 horas. Assim, o usuário nunca mais vai entrar por recuperação de senha

  • O verdadeiro motivo pode ser que esses sites simplesmente não funcionem direito
    Já tive problemas com contas da Epic e do Spotify. Você cria uma conta, usa por uma semana, a sessão expira e o Spotify te expulsa da conta. Quando tenta entrar, diz que a senha está errada, o que é impossível porque ela está salva no gerenciador de senhas. No fim, não há alternativa senão redefinir por e-mail. Nas primeiras vezes, mesmo recebendo o e-mail e redefinindo, o mesmo padrão se repetia; depois de 3 ou 4 vezes, nem o e-mail chegava mais e era preciso criar uma conta nova. Hoje entro no Spotify com a conta Google e ainda não tive problema. Mas, usando e-mail comum, o sistema de autenticação deles simplesmente não funciona
  • Acho que isso é uma pista mais próxima da verdade. Muitas “organizações de alta segurança”, incluindo Gmail e Cloudflare, têm sessões de autenticação muito longas. O motivo é que a probabilidade de alguém ter acesso ao PC de uma pessoa que usa esses sistemas enquanto ela não fez logout é, na prática, muito baixa. A maioria dos hacks mira remotamente senhas fracas
    O problema é que falta uma linguagem consistente para medir risco e julgar “este site realmente precisa de autenticação de dois fatores?” ou “uma sessão de 30 minutos faz sentido?”. Se houver um antivírus atualizado, a maioria vai querer continuar logada. Você já recebeu um pedido para limpar todos os cookies para corrigir algum problema em um site? Minha resposta é sempre não. Já ouvi alguém dizer: “A conta é sua; se você quer permanecer logado e assumir o risco de ser hackeado, esse risco é seu, não do operador do serviço”, e concordo cada vez mais. Se alguém apagou todas as suas instâncias EC2 enquanto seu notebook estava logado, a culpa não é da AWS por não ter te deslogado antes; é sua. A AWS poderia fazer isso, mas por que deveria? Não há motivo para irritar 1 milhão de pessoas para proteger 1 pessoa descuidada
  • É isso mesmo. Cansei de plataformas agindo como babás com limites de sessão e autenticação de dois fatores obrigatória. Bastaria colocar um toggle nas configurações

• Já vi sites que eliminaram a etapa de recuperação de senha ou eliminaram a própria senha. O e-mail é a autenticação
  Você informa o endereço de e-mail, recebe um e-mail com um código e digita o código para entrar. Entendo por que fazem isso, mas, como uso vários e-mails, detesto bastante. Precisei colocar o e-mail e uma anotação no gerenciador de senhas para lembrar qual e-mail usar, e isso fica como um item sem senha

  • O atrito de usar magic links é tão grande que já deixei de gastar dinheiro nesses sites e procurei alternativas
    Se não conseguem nem criar um sistema de login decente, é bem provável que também não tenham competência para entregar a funcionalidade prometida. Magic links deixaram de ser apenas um incômodo e viraram um filtro
  • Usamos esse método em um SaaS B2B. Usuários individuais talvez entrem uma ou duas vezes a cada seis meses, então o login sem senha é vantajoso
    Não há o peso de lembrar a senha de um serviço usado raramente, e o onboarding da empresa também fica fácil. A empresa envia um CSV de usuários, e eles podem começar a trabalhar imediatamente, sem criar e confirmar senha nem cumprir regras. Não preferimos links por e-mail, porque pré-visualizações em apps de celular ou scanners antivírus corporativos acabam “clicando” nos links
  • Uma parcela significativa de consumidores não técnicos não vai usar gerenciador de senhas. Se você oferecer apenas cadastro com senha, sem magic link ou código, estará tornando a vida mais difícil para a maioria dos consumidores
    Mesmo oferecendo ambos, se exigir senha e ainda confirmação por e-mail, acho que mais gente vai abandonar o fluxo de cadastro. Além disso, o código fica muito mais simples por não precisar lidar com senha e vários fluxos de login por e-mail
  • Vi esse método ser oferecido em um site de “login de convidado” para resgatar vouchers, e acho que é um caso de uso válido para pessoas que talvez não queiram criar uma conta
    Como o voucher precisava ser associado ao e-mail, era necessário confirmar a posse clicando no link, para o caso de problemas de suporte no futuro por perda do voucher. Se a pessoa criasse uma conta depois, também poderia ver os vouchers recebidos anteriormente
  • Isso significa que o site não armazena minha senha, então há menos com que me preocupar

• Só depois de ler este texto percebi que estou usando exatamente esse método na Best Buy
  Não foi intencional. Sei que a senha está correta porque ela está salva no 1Password, mas toda vez que tento comprar algo no bestbuy.com, algum mecanismo de proteção contra sequestro de conta é acionado e diz falsamente que a senha está errada. Acredito perfeitamente que possa ser um problema do meu lado. Pode ser algo como um bloqueador de anúncios ou bloqueio de DNS local. Mas, depois de algumas repetições, a vontade de depurar desaparece e você simplesmente segue o caminho de menor resistência

  • Será que não é uma incompatibilidade de comprimento máximo? É muito comum o campo de alteração de senha e a página de login terem maxlength diferentes
    Por exemplo, se você definiu uma senha de 60 caracteres ao alterá-la, mas o comprimento máximo da página de login é 40 caracteres, ao fazer login aparece “senha incorreta”. Por isso agora adoto a política de salvar o comprimento máximo nas configurações da aplicação para que ele seja propagado a todos os campos de senha. Verificando, há de fato uma incompatibilidade de comprimento. O formulário de definição de senha tem maxlength de 54, mas a página de login não tem maxlength. Portanto, se a senha tiver mais de 54 caracteres e o 1Password não cortar automaticamente a senha salva para 54 caracteres ou menos, não será possível fazer login

• Para a maioria das pessoas, usar computador é tentar na força bruta, repetidamente, até mais ou menos funcionar. Software é criado por pessoas que entendem em detalhes os sistemas subjacentes, mas é feito para pessoas que não têm esse entendimento
  Quando usuários encontram um padrão que funciona uma vez, ficam nele. Agora que muitas escolas usam tablets na educação, essa tendência está ficando ainda maior. As pessoas não pegam muito bem a intuição de como computadores funcionam. A maioria não pensa profundamente nisso. Está simplesmente ali e, como já estão acostumadas com coisas quebradas por padrão, qual é o grande problema de clicar mais algumas vezes?

  • Entre desenvolvedores de software, talvez só uns 10% realmente entendam a fundo o que estão fazendo. Na verdade, é justamente porque desenvolvedores não entendem direito o que fazem que pessoas comuns acabam usando software ruim na base da tentativa e erro

• Exagerando um pouco, os fluxos de login são iguais
  A) você vai ao site, copia e cola uma string aleatória pelo gerenciador de senhas e recebe por e-mail uma solicitação de TOTP para verificar sua identidade. Ou B) você vai ao site, clica em “esqueci minha senha”, recebe um link de login e então digita uma string aleatória. Em muitos casos, B é na prática mais rápido, e quase nunca muito mais lento. A caixa “lembrar” não tem efeito nenhum

  • Quem copia e cola de um gerenciador de senhas?
    Acho meu fluxo melhor que os dois. Vou ao site, o Safari sugere o preenchimento automático, uso TouchID/FaceID e recebo a solicitação do código de segunda etapa. Se vier por SMS ou e-mail, o Safari sugere o preenchimento automático. Mesmo se for TOTP, o Safari preenche automaticamente. É muito fácil. Passkeys são ainda mais fáceis porque não há a segunda etapa nem a espera por SMS/e-mail
  • TOTP não é algo que se envia por e-mail. O ponto central do TOTP é que você consegue gerar diretamente o código de autenticação usando a hora atual e um segredo pré-compartilhado
  • Com graylisting, o fluxo B pode levar uns 10 minutos
  • O método B funciona em qualquer lugar onde você tenha acesso ao e-mail e não depende de você estar com o app ou o celular em mãos
  • O navegador não lembra a senha?

• A motivação dá para entender na hora. Se você usa “esqueci minha senha”, não precisa lembrar a senha. E isso também não torna a segurança da conta mais fraca. Afinal, esse caminho já estava aberto também para atacantes
  Alguns sites adotam isso como fluxo padrão e afirmam implicitamente que, se podem enviar um botão de login por e-mail para alguém, a senha em si é irrelevante. Pessoalmente, não gosto. Não confio em e-mail e também não gosto de ele virar um ponto único de falha para dezenas de contas. Se é possível fazer login só com o segundo fator, então isso não é autenticação de dois fatores. Eu gostaria de fazer login com senha, sem opção de redefinição, mas a realidade não é assim

  • Se o e-mail for protegido com autenticação de dois fatores, volta a ser autenticação de dois fatores