Registro y autenticación sin correo electrónico ni contraseña

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 Me gusta

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 me gusta

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 me gusta

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 me gusta

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

3 Me gusta

El correo electrónico debería ser opcional. Usar el correo electrónico es cada vez más poco fiable, imposible debido al oligopolio de los grandes proveedores de correo electrónico.

Ahora, de repente, Gmail está bloqueando mi nombre de dominio.

  • Incluso después de configurar perfectamente toda la seguridad del correo electrónico (SPF, DKIM, DMARC, …) durante años
  • ¿Qué quiero decir con perfecto? Todas las herramientas de prueba e informes de seguridad de correo electrónico muestran “100% OK” y
  • el nombre de dominio tampoco ha estado en ninguna lista de spam (spamhouse…) durante años.

Pero, ¿puedes contactar con Gmail? Claro…

Cita Sender Contact Form - Gmail Help

Utilizaremos la información que proporciones para investigar y mejorar nuestros sistemas de detección de spam y abuso. Lamentablemente, no podemos proporcionar detalles sobre nuestros hallazgos durante o después de la investigación.

Así que, probablemente, la respuesta será algo como “sí, lo revisamos, no lo arreglamos, el problema es tuyo pero no compartes ningún ejemplo de spam y no te decimos cuál es el problema”… Eso, si es que hay algún problema.

De todos modos, usé ese formulario de contacto. Tarda dos semanas en responder, decía el formulario al final. Eso hace que el correo electrónico sea prácticamente poco fiable y demasiado engorroso para trabajar con él.

No es solo mi experiencia.

Mucha gente ha escrito sobre experiencias similares.

Estas artimañas se suman a todas las dificultades técnicas de autoalojar tu servidor de correo electrónico.

¿Podrías hacer que el correo electrónico sea opcional?

  • Al registrarse con dirección de correo electrónico: La recuperación de contraseña será posible.
  • Al registrarse sin dirección de correo electrónico: La recuperación de contraseña será imposible.
  • Si el administrador del sitio lo permite (configuración opcional), advierte al usuario pero permite el registro sin dirección de correo electrónico.
  • Solo nombre de usuario + contraseña.

Temas similares:

1 me gusta

Una solución rápida y sencilla es utilizar otro sistema para la autenticación utilizando Discourse Connect.

Mi estimación anterior de lo difícil que sería crear un sistema sin correo electrónico está muy equivocada. Utilizar otro identificador con un nombre de host not-email.invalid para esos correos electrónicos debería ser factible. Creo que el plugin Sign-In with Ethereum podría hacer lo que buscas, si estás dispuesto a que la gente use Ethereum, pero algo similar también podría funcionar. Necesitas alguna forma de establecer la identidad.

Necesitas alguna forma de establecer identidad.

Solo nombre de usuario + contraseña.

Entonces, ¿cualquiera (o cualquier bot) en todo Internet puede ir a tu foro y crear un número infinito de cuentas inventando un nombre de usuario y una contraseña?

Sí.

Según mi experiencia con varias aplicaciones web, los bots de spam no tienen muchos problemas para crear direcciones de correo electrónico de Gmail y otras. En mi sitio, tampoco excluimos las direcciones de correo electrónico temporales y desechables. También hay otro software de foros / foros que permiten el registro sin (o sin una dirección de correo electrónico válida) y esto tampoco ha causado ningún problema que yo haya visto. Por lo tanto, no veo las direcciones de correo electrónico como una gran barrera para evitar una avalancha de cuentas de bots / ataques DOS.

Pero puedo ver de dónde vienes. Permitir que los usuarios se registren sin dirección de correo electrónico podría generar muchos problemas de seguimiento. ¿Qué pasa si hay una gran avalancha de ataques de bots y / o ataques DOS donde se crea un número de cuentas de foro increíblemente grande?

En ese caso, se requerirían medidas de prevención contra el spam. Pero estas no serían específicas de aquellas instancias de foros donde el correo electrónico es opcional en comparación con aquellas donde el correo electrónico es obligatorio.

Eso se debe a que los spammers hoy en día también tienen acceso a muchas direcciones de correo electrónico creadas o pirateadas. También podrían usar proveedores de correo electrónico temporal. O comprar / robar un nombre de dominio y configurar su propio servidor de correo electrónico solo para fines de configuración de foros de spam.

Las mismas preguntas surgirían tanto de los usuarios que usan / no usan correo electrónico. A efectos de esta discusión, preguntas teóricas.

  • ¿Cómo ver todas las cuentas que se crearon desde hace X días, que iniciaron sesión menos de X minutos, que tienen 0 publicaciones? Probablemente cuentas de bots. Quiero encontrar y eliminar todas estas.
  • ¿Cómo agregar una pregunta personalizada / rompecabezas / captcha / lo que sea antes de aceptar un registro?
  • ¿Podría el panel de administración tener un botón fácil donde los administradores puedan aprobar / desaprobar fácilmente nuevos registros capaces de manejar el spam de registro masivo?

Parece que Google ha encontrado una solución interesante para esto usando códigos QR y Bluetooth:

1 me gusta

Relacionado: Users logging with SSO, without email address

1 me gusta

Ahora que las claves de acceso son tan prevalentes, muchos servicios ofrecen registro sin contraseña en el que nunca tienes que crear una. Tener una contraseña anula los beneficios de seguridad de las claves de acceso. De manera similar, usar el correo electrónico como método de recuperación significa que la seguridad de todas tus cuentas depende de la seguridad de tu cuenta de correo electrónico. Requerir contraseñas/correo electrónico es malo para la seguridad y la privacidad del usuario, sin mencionar lo fácil que es crear nuevas cuentas de correo electrónico. Puedo decir por experiencia que el requisito de correo electrónico no detiene en absoluto a los bots que envían spam a tu foro. Una de las principales razones por las que los servicios han requerido históricamente un correo electrónico es para que puedas recuperar tu cuenta en caso de que olvides tu contraseña, pero con las claves de acceso se almacenan en tu gestor de contraseñas y se sincronizan en todos los dispositivos. Incluso puedes añadir varias claves de acceso a una cuenta, lo que elimina en gran medida el problema de que la gente olvide su contraseña. Aquí tienes algunos ejemplos de sitios que implementan el registro sin contraseña:

https://app.uninbox.com/ Creo que este es especialmente bueno ya que no requiere correo electrónico
https://www.kayak.com/

1 me gusta

Por favor, explícamelo como si tuviera 80 años.

Target ofrece registro usando solo passkey (con opción de correo electrónico/contraseña) y Discourse te obliga a usar correo electrónico o correo electrónico a través de SSO. Kayak (realmente no me gusta ese nombre de dominio, por cierto :smirking_face:) usa solo Google SSO, y Discourse ya ofrece eso.

Entonces, la pregunta abierta aquí es si existe una opción similar a la que usa Target, porque la opción Kayak ya está ahí (no limitaría el registro solo a usuarios de Google, pero eso soy solo yo).

¿Qué sucede cuando un usuario de Target cambia, por ejemplo, de iPhone a Android?

Kayak en realidad te permite registrarte con una passkey si introduces tu correo electrónico. Desafortunadamente, el correo electrónico todavía es necesario.

Tus passkeys deberían sincronizarse con tu gestor de contraseñas para que estén disponibles. También puedes añadir múltiples passkeys a una cuenta, por lo que puedes crear una nueva con el nuevo teléfono también. Actualmente están trabajando para hacerlas exportables para que puedas moverte entre gestores de contraseñas más fácilmente.

1 me gusta