Registro e autenticação sem email e sem senha

The insecurity and usability problems of passwords are well known. Passwords are something you know, so they are vulnerable to forgetting, which happens often. Thus, email is widely used as a backup to reset passwords.

Email has a lot of problems too. Similar to passwords, people typically reuse the same email address across lots of services, creating a privacy risk if the email is discovered from the service. It is increasingly difficult to get an email address without giving personally identifiable information to the email server. As a deterrent against spam (and probably also because it makes it easier to target ads at users), free email services typically require providing a phone number which is easy to associate with a particular person. Paid email services might not require a phone number, but paying for a service without personally identifiable information is difficult as well, and relying on paid email service subscription is vulnerable to changes in financial circumstances. Also, it’s difficult to reliably self host an email server today. In addition to the privacy issues, the centralization created by reusing an email account across many services also creates a security risk because a compromise of the email account would compromise lots of other accounts.

Nowadays, we don’t need passwords nor emails to register or authenticate to a service. Discourse already supports FIDO and TOTP, but it still requires a password and email address to register and authenticate. It would be great if Discourse made passwords and emails optional in favor of FIDO and TOTP.

One factor authentication with FIDO can be really convenient, but it is vulnerable to loss or destruction of the single FIDO token, similar to the issue of registering with a password but no email address. To resolve this, I propose that users would be required to provide at least two factors to register, which could be any combination of FIDO, TOTP, and/or password. Users who want emailless & passwordless authentication could simply register two FIDO roaming authenticators like Yubikeys. Users could be advised (or potentially required, especially for administrators) to register more than the minimum of two factors to avoid losing access to their accounts.

As FIDO platform authenticators are being built into more and more devices these days with Windows Hello, Apple Touch & Face ID, and Android, this email-less registration system could be usable by nontechnical users who do not own specialized roaming authenticator hardware like a Yubikey. Users could register with the FIDO platform authenticator plus a password. One factor authentication with the FIDO platform authenticator could work seamlessly with such a setup. However, this would create a usability problem for authentication on new devices because users wouldn’t have the FIDO platform authenticator available on a new device and relying solely on the password to setup a new device wouldn’t be secure. To resolve this, I propose a workflow similar to how Matrix authenticates new clients. The user could try to login on a new device with that device’s FIDO platform authenticator (a new factor) and their password (an already registered factor). This would not actually log in, but it would create a request to approve the new FIDO authenticator in the account. The UI on the new device would then direct the user to log in on a device they already have registered to approve the new device. With FIDO platform authenticators built into mobile devices, this could be practically usable for secure authentication without specialized roaming authenticator hardware or sacrificing the ability to use any ad-hoc device like a public kiosk.

I just came up with this anonymous registration & authentication system yesterday after receiving my Yubikeys. I am not aware of any systems which implement this. I would love to see a mature and already widely deployed web application such as Discourse pioneer a future without email or other personally identifiable information being required to use the Internet.

3 curtidas

That’s likely true. But it’s hard to imagine that anyone who would log in with the system that you propose don’t know what a password manager is. I’ve been using a password manager for a decade or so, have multiple fido keys, use Google authenticator, and don’t quite understand what you propose.

It seems improbable that such a system will be added unless at least a few enterprise customers want it. I think it’s on the order of at least 50 hours work for someone who knows a lot about the authentication system, and likely twice that with proper specs. There was an attempt a while ago to integrate with keybase, which could do some of what you want, but I don’t think it got very far.

It’s an interesting idea,though. Maybe it’s easier than I think.

1 curtida

Anyone with a recent device that has a FIDO platform authenticator built in could use this quite easily. In a few more years this could be just about anyone.

I said it in the title: make email optional. Making passwords optional would be great too.

I’m sure it would take a decent amount of work to implement. I think most of the hard part would be getting the UX design really clear. Discourse already has the building blocks in place with 2FA supporting FIDO and TOTP.

1 curtida

A small, first step towards implementing this could be adding the UI for registering FIDO and TOTP to the registration UI so it doesn’t need to be an extra step in the preferences after logging in for the first time. Later, the UI design could be improved further to make email and password optional.

1 curtida

I’m curious about @codinghorror’s thoughts on this considering his various blog posts about passwords.

3 curtidas

O e-mail deve ser opcional. Usar e-mail está se tornando cada vez mais não confiável, impossível devido ao grande oligopólio dos provedores de e-mail.

Agora, de repente, o Gmail está bloqueando meu nome de domínio.

  • Mesmo após configurar perfeitamente toda a segurança de e-mail (SPF, DKIM, DMARC, …) por anos
    • O que eu quero dizer com perfeito? Todas as ferramentas de teste e relatórios de segurança de e-mail estão mostrando “100% OK” e
    • o nome de domínio também não está em nenhuma lista de spam (spamhouse…) há anos.

Mas você pode contatar o Gmail? Claro…

Citação Sender Contact Form - Gmail Help

Usaremos as informações que você fornecer para investigar e melhorar nossos sistemas de detecção de spam e abuso. Infelizmente, não podemos fornecer detalhes sobre nossas descobertas durante ou após a investigação.

Portanto, a resposta provavelmente será algo como “sim, nós investigamos, não consertamos, o problema é seu, mas você não compartilha nenhum exemplo de spam e nós não dizemos qual é o problema”… Isso, se houver algum problema.

De qualquer forma, usei esse formulário de contato. Leva duas semanas para o e-mail responder, disse o formulário no final. Isso torna o e-mail praticamente não confiável e muito complicado para trabalhar.

Não é apenas a minha experiência.

Muitas outras pessoas escreveram sobre experiências semelhantes.

Essas artimanhas vêm em cima de todas as dificuldades técnicas de auto-hospedar seu servidor de e-mail.

Você poderia, por favor, tornar o e-mail opcional?

  • Ao se inscrever com endereço de e-mail: A recuperação de senha será possível.
  • Ao se inscrever sem endereço de e-mail: A recuperação de senha será impossível.
    • Se permitido pelo administrador do site (configuração opcional), avise o usuário, mas permita a inscrição sem endereço de e-mail.
    • Apenas nome de usuário + senha.

Tópicos semelhantes:

1 curtida

Uma solução rápida e fácil é usar outro sistema para autenticação usando o Discourse Connect.

Minha estimativa anterior de quão difícil seria criar um sistema sem e-mail está completamente errada. Usar outro identificador com um nome de host not-email.invalid para esses e-mails deve ser factível. Acho que o plugin Sign-In with Ethereum pode fazer o que você quer, se você estiver disposto a fazer as pessoas usarem Ethereum, mas algo semelhante também poderia funcionar. Você precisa de alguma forma de estabelecer identidade.

Você precisa de alguma forma de estabelecer identidade.

Apenas nome de usuário + senha.

Então qualquer pessoa (ou qualquer bot) em toda a internet pode vir ao seu fórum e criar um número infinito de contas inventando um nome de usuário e uma senha?

Sim.

Na minha experiência com vários aplicativos web, os bots de spam não têm muitos problemas para criar endereços de e-mail do Gmail e outros. No meu site, também não estamos excluindo endereços de e-mail temporários e descartáveis. Existem também outros softwares de fórum / fóruns que permitem o cadastro sem um endereço de e-mail (ou sem um endereço de e-mail válido) e isso também não causou nenhum problema que eu pudesse ver. Portanto, não vejo os endereços de e-mail como uma grande barreira para evitar uma enxurrada de contas de bots / ataques de DoS.

Mas eu entendo de onde você pode estar vindo. Permitir que os usuários se cadastrem sem endereço de e-mail pode se expandir para muitos problemas de acompanhamento. E se houver uma enorme enxurrada de ataques de bots e/ou ataques de DoS, onde um número insano de contas de fórum é criado?

Nesse caso, seriam necessárias medidas de prevenção contra spam. Mas estas não seriam específicas para as instâncias de fórum onde o e-mail é opcional versus aquelas onde o e-mail é obrigatório.

Isso porque os spammers também hoje em dia têm acesso a muitos endereços de e-mail criados ou hackeados. Eles também poderiam usar provedores de e-mail temporários. Ou comprar/roubar um nome de domínio e configurar seu próprio servidor de e-mail apenas para fins de configurações de fórum spam.

As mesmas perguntas surgiriam de ambos os usuários, que usam ou não usam e-mail. Para fins desta discussão, perguntas teóricas.

  • Como visualizar todas as contas que foram criadas desde X dias, que fizeram login menos de X minutos, que têm 0 posts? Provavelmente contas de bot. Quero encontrar e excluir todas elas.
  • Como adicionar uma pergunta personalizada / quebra-cabeça / captcha / o que for antes de aceitar um cadastro?
  • O painel de administração poderia ter um botão fácil onde os administradores podem facilmente aprovar/desaprovar novos cadastros capazes de lidar com spam de registro em massa?

Parece que o Google apresentou uma solução interessante para isso usando códigos QR e Bluetooth:

1 curtida

Relacionado: Users logging with SSO, without email address

1 curtida

Agora que as passkeys são tão prevalentes, muitos serviços oferecem cadastro sem senha, onde você nunca precisa criar uma. Ter uma senha, na verdade, anula os benefícios de segurança das passkeys. Da mesma forma, usar o e-mail como método de recuperação significa que a segurança de todas as suas contas depende da segurança da sua conta de e-mail. Exigir senhas/e-mail é ruim para a segurança e privacidade do usuário, sem mencionar o quão fácil é criar novas contas de e-mail. Posso dizer por experiência que o requisito de e-mail não impede bots de enviarem spam para o seu fórum. Uma das principais razões pelas quais os serviços historicamente exigiram um e-mail é para que você possa recuperar sua conta caso esqueça sua senha, mas com as passkeys elas são armazenadas no seu gerenciador de senhas e sincronizadas entre dispositivos. Você pode até adicionar várias passkeys a uma conta, eliminando a maior parte do problema de as pessoas esquecerem suas senhas. Aqui estão alguns exemplos de sites que implementam cadastro sem senha:

https://app.uninbox.com/ Este, na minha opinião, é especialmente bom, pois não exige um e-mail
https://www.kayak.com/

1 curtida

Por favor, explique isso como se eu tivesse 80 anos.

O Target oferece registro usando apenas passkey (com opção de e-mail/senha), e o Discourse força o uso de e-mail ou e-mail via SSO. O Kayak (eu realmente não gosto desse nome de domínio, aliás :smirking_face:) usa apenas o Google SSO, e o Discourse já oferece isso.

Então, a pergunta em aberto aqui é se há uma opção semelhante à que o Target usa, porque a opção Kayak já existe (eu não limitaria o registro apenas a usuários do Google, mas isso sou só eu).

O que acontece quando um usuário do Target muda, por exemplo, do iPhone para o Android?

O Kayak na verdade permite que você se inscreva com uma chave de acesso (passkey) se você inserir seu e-mail. Infelizmente, o e-mail ainda é necessário.

Suas chaves de acesso (passkeys) devem ser sincronizadas com seu gerenciador de senhas para que estejam disponíveis. Você também pode adicionar várias chaves de acesso a uma conta para que possa simplesmente criar uma nova com o novo telefone também. Atualmente, eles estão trabalhando para torná-las exportáveis para que você possa migrar entre gerenciadores de senhas com mais facilidade.

1 curtida