El patrón de “el correo electrónico es autenticación”

• Algunos usuarios, en lugar de recordar o gestionar una contraseña, usan cada vez el proceso de “olvidé mi contraseña” como si fuera su forma de iniciar sesión
• El flujo real consiste en recibir por correo electrónico un enlace de recuperación desde la página de inicio de sesión, ingresar una contraseña temporal y luego repetir el mismo proceso en la siguiente visita
• Este hábito, más que una estrategia de seguridad consciente, se parece a un comportamiento aprendido que se fue fijando con el tiempo
• Incluso mejoras como los administradores de contraseñas y la autenticación en dos pasos o multifactor pueden sentirse para el usuario más como un aumento de fricción que como un refuerzo de seguridad
• El diseño del sistema debe partir del comportamiento repetitivo del usuario y guiarlo de forma natural hacia mejores formas de uso

---

Recuperación de contraseña usada como inicio de sesión

• Algunos usuarios, al iniciar sesión en sus cuentas en línea, no ingresan una contraseña sino que repiten cada vez el proceso de recuperación
  • Llegan a la página de inicio de sesión
  • Hacen clic en “I forgot my password”
  • Van al correo electrónico
  • Hacen clic en el enlace de recuperación
  • Ingresan una contraseña temporal que no van a recordar
  • Después repiten el mismo proceso
• Si se les pregunta por qué lo hacen, no saben responder o dicen que nunca se habían puesto a pensarlo
• Este comportamiento no es una estrategia de inicio de sesión decidida por la mañana, sino más bien un procedimiento repetido que se consolidó con el tiempo

La fricción que las mejoras de seguridad generan para el usuario

• Este método funciona como una solución de bajo esfuerzo que evita que el usuario tenga que recordar una frase de contraseña
• Los administradores de contraseñas, el robo de identidad, la autenticación en dos pasos y multifactor, y el envejecimiento del esquema de usuario/contraseña ya son temas ampliamente discutidos
• Los mejores procedimientos de seguridad a menudo aumentan las barreras y la fricción, por lo que puede resultar difícil que el usuario los adopte de manera natural
• Los diseñadores deben considerar el comportamiento aprendido de los usuarios y crear flujos que les permitan pasar con el tiempo a mejores formas de uso

[GN⁺]

Opiniones de Hacker News

• Las cuentas de correo electrónico son el denominador común más universal en la autenticación en línea. Los celulares también son competitivos, pero se pueden perder; los números telefónicos son más comunes y duran más, pero su nivel de seguridad es mucho más bajo que el de las cuentas de los principales proveedores de email.
  Si se quiere diseñar un “sistema de autenticación imaginario para internet”, primero hay que mirar la recuperación de cuentas. Si la respuesta cuando pierdes tu autenticador elegante es “simplemente ya no tienes acceso” o “un panel de colegas garantiza tu identidad”, ese sistema solo funciona si toma como usuarios a seres inteligentes imaginarios, no a humanos.

  • Esta ha sido durante años mi principal razón para oponerme a blockchain/criptomonedas. El enfoque de “si pierdes la clave, pierdes la billetera” es fundamentalmente incompatible con usuarios reales.
    Los humanos necesitan poder recuperarse de sus errores.
  • Las identificaciones digitales emitidas por el gobierno podrían resolver gran parte de este problema. Tendrán sus propios problemas, pero delegar la identificación personal al gobierno parece más valioso y menos riesgoso que el bloqueo de cuentas por parte de empresas como Google.
  • Lamentablemente, incluso en los principales proveedores de email como Google, “simplemente ya no tienes acceso” es un patrón común. Lo demuestran bien las personas que pierden o les roban el celular y quedan bloqueadas permanentemente de su cuenta.
  • Incluso una “cuenta de email de un proveedor importante” viene con la salvedad de que “suspendieron la cuenta sin motivo, no hay forma de apelar y no dicen por qué la suspendieron”.
  • El enfoque de que un panel de colegas garantice la identidad de una persona es un problema de diseño interesante. Si existiera un sistema común que permitiera recombinar secretos de autenticación adecuadamente distribuidos siguiendo las instrucciones de las partes involucradas, podría hacerse de forma bastante fluida.
    ¿Se puede lograr que funcione también para humanos comunes? Creo que tenemos suficiente creatividad para diseñarlo.

• Nuestro servicio es un negocio bastante ligero, así que los usuarios usan la cuenta solo por comodidad. El enfoque en el que nos quedamos es este: el usuario ingresa su email, enviamos un código de verificación por correo y, cuando el usuario ingresa el código, emitimos una cookie muy larga que lo mantiene logueado prácticamente de forma indefinida.
  No importa si ya existe una cuenta; si es un email nuevo, se crea una cuenta nueva. A veces, usuarios con varios correos crean una cuenta nueva por error, pero la conversión de registro e inicio de sesión mejoró tanto que vale la pena aceptarlo. La vigencia del código y la cantidad de intentos requieren análisis de riesgo y, si es posible, conviene usar algún mecanismo de bloqueo. Si el servicio no es tan importante, recomiendo esta estrategia. iOS Mail ahora también soporta este enfoque como la función de códigos de un solo uso de Messages, así que para algunos usuarios resulta bastante cómodo.

  • Según los datos que he visto, este método es abrumadoramente bueno para maximizar los ingresos de e-commerce.
    No hay que obligar al comprador a crear una cuenta; basta con pedirle los datos. De todos modos, el navegador los autocompleta. Después se le envía por email un enlace para revisar el estado del pedido y, en el siguiente pedido, se le vuelve a pedir el correo. La fricción adicional genera una pérdida de ingresos mayor que el beneficio de conseguir “usuarios registrados”.
  • Opero una app B2C pequeña: los usuarios se registran solo con su dirección de email y no existe campo de contraseña. La cuenta se crea y en ese dispositivo quedan logueados de forma indefinida.
    Solo cuando necesitan iniciar sesión en otro dispositivo se les puede pedir una nueva contraseña. Esto reduce la fricción de registro y las contraseñas débiles. La mayoría, de todos modos, casi nunca necesita iniciar sesión en otro dispositivo.
  • He implementado varias veces este método de login, y surgió de la experiencia de tener que eliminar muchísimas suposiciones sobre qué es una “cuenta de usuario”. En la práctica, para que el funnel funcione como ambas partes quieren, se necesita este tipo de simplificación.
    Si no es un ámbito donde haya que preservar el anonimato, se puede hacer así y luego integrar passkeys. La desventaja es que ya no se pueden compartir contraseñas, así que hay que pensar antes en el problema de administrar varios usuarios dentro de una misma cuenta. Pero si se aborda conscientemente, el funnel y la experiencia de usuario terminan mejorando. Además, la seguridad queda atada al nivel promedio de seguridad de los proveedores de email de los usuarios, pero normalmente eso es mejor que el nivel necesario. Las contraseñas pueden usarse más adelante como segundo factor cuando hagan falta, o se puede agregar otro factor; y si es B2B, se puede ir directamente con SAML u OIDC. En B2B o D2C siempre funcionó bien, y los casos excepcionales valían la pena resolverlos por los beneficios de adquisición.
  • He visto este método de login; ¿no se podría enviar por email un enlace que lleve al inicio de la app y deje al usuario ya logueado?
    Copiar el código, encontrar la pestaña donde quedó abierta la página de login y pegarlo es engorroso.
  • Usé este enfoque en una app CRUD pequeña, casi de un solo formulario, y durante la campaña las solicitudes de soporte fueron casi cero, así que valió totalmente la pena.

• Llegados a este punto, ¿no bastaría con enviar a la dirección de email un enlace URL de un solo uso para iniciar sesión con un clic? Que expire en 10 minutos y se descarte después de un uso.
  Claro que cualquiera que tenga el enlace primero puede iniciar sesión en la cuenta, pero de todos modos solo es accesible desde el email. Se pierde toda sensación de seguridad más allá de la cuenta de correo, pero la realidad ya llegó a ese punto. Si se usa por mensajes al celular un patrón como “haz clic para verificar el inicio de sesión: www.someurl.com?p=134234535”, se convierte en una autenticación de dos pasos sin tener que ingresar un código tontamente.

  • Varias webapps usan este enfoque, pero resulta confuso para los usuarios (“¿por qué ya tengo una cuenta? ¡Nunca me registré!”), cuesta dinero (enviar emails no es gratis) y también es lento.
    El correo puede irse a spam, o por graylisting el usuario puede pasar horas sin poder iniciar sesión, o puede tardar 1 minuto en llegar y aun eso sentirse demasiado. No estoy seguro de recomendarlo.
  • Odio cuando un sitio que solo ofrece este método no puede enviar el email en menos de 30 segundos.
    El “clic para verificar login” enviado al celular debería dar tanto el código como el enlace. El dispositivo donde uno inicia sesión no siempre es el celular, así que debería ser “ingresa 1234 o haz clic”.
  • Algunos sitios, como Netdata, hacen eso.
    Pero es más lento que cuando un gestor de contraseñas autocompleta la combinación de usuario/contraseña, porque hay que esperar el email y hacer clic en el enlace.
  • Estoy construyendo una webapp exactamente con este flujo de login y tuve problemas en mobile. Apps como Gmail no permiten copiar el enlace al navegador sin vista previa, y esa vista previa consume el enlace (next.js auth).
    No quiero iniciar sesión en el navegador integrado de Gmail, sino en el navegador normal, y es bastante molesto.
  • Si vas a hacer eso, mejor ir hasta el final con single sign-on. El 95% de los usuarios de todos modos usará Gmail, Outlook o Apple.
    Es mejor un botón de “Iniciar sesión con Google” que “enviar enlace por email”, y de cualquiera de las dos formas se puede hacer tracking.

• No es realista pensar que una persona va a crear y recordar una contraseña para cada servicio irrelevante. Crear otro sistema de autenticación basado en contraseñas es casi una especie de juego de roles
  Las contraseñas suelen usarse de una de dos formas: un gestor de contraseñas protegido por una contraseña real, o la misma contraseña repetida en cada servicio. Como casi todos los servicios ofrecen recuperación por correo, en la práctica el correo electrónico es el medio de autenticación. El correo personal no se cambia fácilmente, no se comparte y tampoco se reutiliza. Probablemente has usado tu correo personal durante más tiempo que tu número de teléfono. Mientras has usado tu dirección de correo actual, tu número de teléfono cambió al menos cinco veces, y esos números ahora los usan otras personas

  • También están las contraseñas derivadas, que son una especie de híbrido. Puede ser un patrón que la persona recuerda, o una herramienta de gestión que las calcula por dominio
    Y la función de recuperar contraseña al menos avisa al dueño de la dirección sobre todos los intentos. El inicio de sesión basado en contraseña no siempre envía un correo cada vez que alguien inicia sesión desde una ubicación nueva
  • Apple mejoró mucho el proceso de “no puedes simplemente ingresar la contraseña de 1Password/Keychain, hay que molestarte por correo”. Al menos cuando reconoce el correo o el SMS y escribe el código por ti

• La respuesta es simple. Normalmente tiene que ver con la fricción que el proveedor del servicio creó para sus usuarios. En este caso parece claro: las sesiones de los proveedores de correo electrónico por lo general prácticamente no terminan y quedan iniciadas salvo que borres la caché del navegador
  Basta con hacer que el token de autenticación de tu propio servicio dure tanto como el de Gmail y, como alternativa, permitir iniciar sesión cada vez con una contraseña de un solo uso. Pero hay que dejar de lado prácticas sacrílegas como los tokens de autenticación de 12 horas. Entonces el usuario nunca volverá a iniciar sesión mediante recuperación de contraseña

  • La verdadera razón quizá sea que esos sitios web simplemente no funcionan bien
    Antes tuve problemas con cuentas de Epic y Spotify. Creabas una cuenta, la usabas una semana, la sesión expiraba y Spotify te echaba de la cuenta. Al intentar iniciar sesión, decía que la contraseña era incorrecta, lo cual era imposible porque estaba guardada en el gestor de contraseñas. Al final no quedaba otra que restablecerla por correo. Las primeras veces recibía el correo y la restablecía, pero se repetía el mismo patrón; después de 3 o 4 veces, ni siquiera llegaba el correo y había que crear una cuenta nueva. Ahora uso Spotify iniciando sesión con una cuenta de Google y hasta ahora no he tenido problemas. Pero si usas un correo normal, su sistema de autenticación simplemente no funciona
  • Creo que esta pista está más cerca de la verdad. Gmail, Cloudflare y muchas otras “organizaciones de alta seguridad” tienen sesiones de autenticación muy largas. La razón es que, en la práctica, es muy poco probable que alguien haya accedido a la PC de una persona que usa estos sistemas y que el usuario no haya cerrado sesión. La mayoría de los hackeos apuntan de forma remota a contraseñas débiles
    El problema es que falta un lenguaje coherente para medir el riesgo y decidir “¿este sitio realmente necesita autenticación de dos factores?” o “¿tiene sentido una sesión de 30 minutos?”. Si tienen un antivirus actualizado, la mayoría preferirá mantenerse conectada. ¿Alguna vez te pidieron borrar todas las cookies para arreglar un problema de un sitio? Mi respuesta siempre es no. Una vez escuché: “la cuenta es tuya, y si quieres asumir el riesgo de hackeo por mantener la sesión iniciada, ese riesgo es tuyo, no del operador del servicio”, y cada vez estoy más de acuerdo. Si alguien borra todas tus instancias EC2 porque tu laptop quedó con la sesión iniciada, la culpa no es de AWS por no haberte cerrado la sesión antes, es tuya. AWS podría hacerlo, pero ¿por qué tendría que hacerlo? No hay razón para molestar a un millón de personas para proteger a una persona descuidada
  • Es cierto. Ya me cansé de que las plataformas actúen como niñeras con límites de sesión y autenticación de dos factores obligatoria. Bastaría con poner un interruptor en la configuración

• He visto sitios que eliminan el paso de recuperar contraseña, o directamente eliminan la contraseña. El correo electrónico es la autenticación
  El flujo es ingresar tu dirección de correo, recibir un correo con un código e ingresar ese código para iniciar sesión. Entiendo por qué lo hacen, pero como alguien que usa varios correos, me resulta bastante molesto. Tuve que poner el correo y una nota en el gestor de contraseñas para recordar cuál debía usar, y queda como una entrada sin contraseña

  • La fricción de usar magic links era tan grande que alguna vez dejé de gastar dinero en esos sitios y busqué alternativas
    Si no pueden ni crear un sistema de inicio de sesión decente, probablemente tampoco tengan la capacidad de entregar las funciones que prometen. Los magic links ya pasaron de ser una molestia a ser un filtro
  • En B2B SaaS usamos este enfoque. Como los usuarios individuales quizá inician sesión una o dos veces cada seis meses, el inicio de sesión sin contraseña resulta conveniente
    No existe la carga de recordar la contraseña de un servicio que se usa poco, y el onboarding de la empresa también es más fácil. La empresa sube un CSV de usuarios y estos pueden empezar a trabajar de inmediato, sin crear una contraseña, confirmarla ni cumplir reglas. No prefiero los enlaces por correo. Las vistas previas de las apps móviles o los escáneres antivirus corporativos pueden “hacer clic” en el enlace
  • Una proporción considerable de consumidores no técnicos no va a usar un gestor de contraseñas. Si solo ofreces registro con contraseña y no ofreces magic links ni códigos, les estás haciendo la vida más difícil a la mayoría de los consumidores
    Incluso si ofreces ambas opciones, si pides una contraseña y además confirmación por correo, creo que habrá más abandono en el flujo de registro. Además, al no tener que manejar contraseñas ni varios flujos de inicio de sesión por correo, el código también es mucho más simple
  • Un sitio de “inicio de sesión como invitado” para canjear vouchers ofrecía este método, y me parece un caso de uso válido para personas que quizá no quieran crear una cuenta
    Como el voucher debía asociarse a un correo, había que confirmar la propiedad haciendo clic en un enlace por si más adelante surgía un problema de soporte por pérdida del voucher. Si después creas una cuenta, también puedes ver los vouchers que recibiste antes
  • Significa que el sitio no almacena mi contraseña, así que hay menos de qué preocuparse

• Recién después de leer este artículo me di cuenta de que en Best Buy estoy usando exactamente este método
  No fue intencional. Sé que la contraseña es correcta porque está guardada en 1Password, pero cada vez que intento comprar algo en bestbuy.com, se activa algún mecanismo de prevención de robo de cuenta que falsamente me dice que la contraseña está mal. Puedo creer perfectamente que sea un problema de mi lado. Podría ser algo como un bloqueador de anuncios o un bloqueo de DNS local. Pero después de que pasa varias veces, se me van las ganas de depurar y simplemente sigo el camino de menor resistencia.

  • ¿No será una discrepancia en la longitud máxima? Es muy común que el campo para cambiar la contraseña y la página de inicio de sesión tengan distintos maxlength
    Por ejemplo, si al cambiar la contraseña ingresaste una de 60 caracteres, pero la página de inicio de sesión tiene una longitud máxima de 40, al iniciar sesión te dirá “contraseña incorrecta”. Por eso ahora uso la política de guardar la longitud máxima en la configuración de la aplicación y propagarla a todos los campos de contraseña. Al revisar, efectivamente hay una discrepancia de longitud. El formulario para establecer la contraseña tiene maxlength de 54, pero la página de inicio de sesión no tiene maxlength. Por lo tanto, si la contraseña supera los 54 caracteres y 1Password no recorta automáticamente la contraseña guardada a 54 caracteres o menos, no se puede iniciar sesión.

• Para la mayoría de la gente, trabajar con computadoras consiste en intentar a lo bruto repetidamente hasta que más o menos funcione. El software lo hacen personas que entienden en detalle los sistemas subyacentes, pero está hecho para personas que no tienen esa comprensión
  Cuando los usuarios encuentran un patrón que funciona una vez, se quedan con él. Ahora que muchas escuelas usan tablets en la educación, esta tendencia está creciendo aún más. No desarrollan muy bien la intuición de cómo funcionan las computadoras. La mayoría no lo piensa demasiado. Simplemente está ahí, y como ya están acostumbrados a que venga roto de fábrica, ¿qué tanto importa hacer unos clics más?

  • Probablemente solo alrededor del 10% de los desarrolladores de software entiende realmente en profundidad lo que hace. Más bien, como los desarrolladores no entienden bien lo que hacen, la gente común termina usando software mediocre a fuerza de prueba y error.

• Exagerando un poco, el flujo de inicio de sesión es el mismo
  A) Vas al sitio web, copias y pegas una cadena aleatoria desde el gestor de contraseñas y recibes por email una solicitud TOTP para verificar tu identidad. O B) vas al sitio web, haces clic en “olvidé mi contraseña”, recibes un enlace de inicio de sesión y luego ingresas una cadena aleatoria. En muchos casos B es en realidad más rápido, y casi nunca es mucho más lento. La casilla “recordarme” no sirve para nada.

  • ¿Quién copia y pega desde un gestor de contraseñas?
    Creo que mi flujo es mejor que ambos. Voy al sitio, Safari me sugiere el autocompletado, uso TouchID/FaceID y luego me pide el código de segundo factor. Si llega por SMS o email, Safari sugiere autocompletarlo. Incluso si es TOTP, Safari lo autocompleta. Es muy fácil. Las passkeys son aún más fáciles porque no tienen el segundo paso ni la espera por SMS/email.
  • TOTP no es algo que se envíe por email. La idea central de TOTP es que puedes generar directamente un código de autenticación a partir de la hora actual y un secreto compartido previamente.
  • Si hay greylisting, el flujo B puede tardar unos 10 minutos.
  • El método B funciona desde cualquier lugar donde tengas acceso al email y no depende de si tienes una app o el teléfono en la mano.
  • ¿El navegador no recuerda la contraseña?

• La motivación se entiende de inmediato. Si usas “olvidé mi contraseña”, no necesitas recordar la contraseña. Y la seguridad de la cuenta tampoco se debilita. Al fin y al cabo, esa ruta ya estaba abierta también para un atacante
  Algunos sitios web toman esto como flujo predeterminado y afirman implícitamente que, si pueden enviarle a alguien un botón de inicio de sesión por email, la contraseña en sí no tiene sentido. En lo personal no me gusta. No confío en el email y tampoco me gusta que se convierta en un punto único de falla para decenas de cuentas. Si puedes iniciar sesión solo con el segundo factor, eso no es autenticación de dos factores. Me gustaría iniciar sesión con contraseña sin opción de restablecimiento, pero la realidad no es así.

  • Si proteges el email con autenticación de dos factores, vuelve a ser autenticación de dos factores