No conviene hacer que los enlaces mágicos/trágicos de email sean la única opción de inicio de sesión
(recyclebin.zip)- Los enlaces mágicos, que envían un enlace de inicio de sesión por email, pueden reducir el riesgo de phishing de contraseñas y de filtraciones por reutilización de contraseñas, pero cuando son la única opción trasladan la fricción de inicio de sesión al usuario
- Para quienes usan varias computadoras o separan dispositivos de trabajo y personales, el dispositivo que recibe el email y el navegador en el que quieren iniciar sesión son distintos, por lo que el flujo se interrumpe fácilmente
- Por los retrasos de SMTP y el proceso de pasar el enlace, el inicio de sesión puede demorarse desde 2 segundos hasta varios minutos, y en navegadores integrados en apps y apps lectoras de RSS también puede romperse la usabilidad móvil
- El método de ingresar manualmente un OTP recibido por email o SMS también es engorroso, pero cuando es difícil mover un enlace entre el cliente de email y el navegador puede ser mejor que un enlace mágico
- Aunque se usen enlaces mágicos como opción predeterminada, para una base de usuarios técnica y preocupada por la privacidad se deberían ofrecer también alternativas sólidas como passkeys
Situaciones en las que los enlaces mágicos se vuelven incómodos
- “Magic Links” antes se refería a PDA futuristas, pero hoy es un término que empresas como Auth0 usan para referirse a enlaces de inicio de sesión incluidos en emails
- 404 Media defiende los enlaces mágicos en “We Don’t Want Your Password”, con el argumento de que los enlaces por email son más difíciles de usar para phishing que las contraseñas, no derivan en filtraciones de contraseñas y reducen el riesgo de reutilizar contraseñas filtradas
- En una vida centrada en una sola laptop y dispositivos móviles puede parecer sencillo, pero para usuarios que usan varios dispositivos y navegadores, la complejidad se les traslada tal cual
- Casos incómodos:
- Varios dispositivos: a quienes no tienen su email personal en una PC gamer o en una laptop de trabajo les resulta difícil abrir directamente el enlace de inicio de sesión
- Velocidad: por los retrasos de SMTP y el proceso de mover el enlace al navegador correcto, puede volverse más lento, de 2 segundos a varios minutos
- Móvil: se rompe el uso de navegadores integrados en apps, lo que vuelve incómodo manejar enlaces locales en apps lectoras de RSS
- Seguridad: un flujo que empuja a abrir el email personal en un dispositivo de trabajo, o al revés, no es una ventaja de seguridad
Alternativas y mejoras mínimas
- El método passwordless de ingresar manualmente un OTP recibido por email o SMS también es incómodo, pero puede ser más práctico cuando no es fácil mover un enlace desde el cliente de email al navegador donde se quiere iniciar sesión
- Stratechery ofrece mediante Passport la opción de hacer clic en un enlace o ingresar un OTP; aunque tiene la limitación de trasladar la incomodidad al usuario sin implementar passkeys, considera mejor las situaciones de uso que una solución basada solo en enlaces mágicos
- Aunque se insista en usar enlaces mágicos/trágicos como opción predeterminada, conviene ofrecer también alternativas sólidas como passkeys
- Magic Links Have Rough Edges, but Passkeys Can Smooth Them Over, de Ricky Mondello, es un artículo de referencia que explica cómo mitigar este problema con passkeys
1 comentarios
Opiniones de Hacker News
Problemas que surgieron al crear una app con magic links: como el usuario puede necesitar iniciar sesión en un dispositivo donde acceder al correo es incómodo, el magic link debe incluir un código de inicio de sesión alternativo.
También hay que manejar los casos en que el cliente de correo abre automáticamente el enlace para generar una captura de vista previa, y considerar los clientes de correo que lo abren en un navegador integrado en la app en lugar del navegador preferido del usuario.
Por ejemplo, aunque un usuario de iOS prefiera Firefox móvil, la app de correo puede forzar la apertura en un navegador integrado basado en Safari.
Creo que una estrategia que lleve a una página para ingresar un código de un solo uso evitaría muchos de estos problemas.
Hace poco me pasó que una cuenta de correo nueva se verificó automáticamente y, cuando el usuario hizo clic, el magic link ya no era válido, porque Microsoft había iniciado sesión primero con ese enlace durante la inspección.
Después de que McDonald's cambiara de correo/contraseña a magic links, fue realmente difícil lograr que el enlace funcionara en la app de McD, y normalmente solo abría el sitio web de McD.
Cuando como McD, diría que el 98% de las veces, si no puedo pedir desde la app, no como ahí, así que fue bastante molesto; al final me cambié a “Sign in With Apple”(SIWA).
No encontré cómo agregar SIWA a mi cuenta existente de McD, así que tuve que usar SIWA ocultando mi correo real a McD; se creó una cuenta nueva y perdí los puntos de recompensa de la cuenta anterior, pero al menos pude volver a usar la app de McD.
En la app hay una promo de “Free Medium Fries on Friday” todos los viernes al hacer un pedido de 1 dólar o más, así que cada viernes al almuerzo suelo prepararme un sándwich en casa y acompañarlo con una galleta y papas gratis de McD.
Así que recibí el magic link en la computadora de la empresa y generé un código QR, pero el sistema de cuarentena de correo había reescrito el enlace completo, así que tuve que extraer el original.
Y no terminó ahí: la URL de redirección de regreso a Slack estaba rota por la codificación URL, así que tuve que arreglarla a mano y luego generar el código QR.
Bastaría con incluir un código QR o un código en el correo original del magic link.
En cuanto se introduce un código, esa ventaja desaparece por completo: al atacante le basta con crear un sitio web falso que pida el código.
El magic link debe iniciar sesión en el dispositivo donde se hizo clic, no en el dispositivo que solicitó la sesión de inicio.
Cualquier otro enfoque puede ser un poco menos molesto, pero es un problema de seguridad y debe tratarse como tal.
He usado magic links durante años, en parte porque en la etapa de MVP quería evitar la carga de seguridad de almacenar contraseñas de usuarios. El mayor problema es que algunos usuarios, alrededor del 0.1%, directamente no reciben los correos.
Probé IP propia, MailGun, PostMark e incluso reintentos secuenciales con varias herramientas de correo transaccional, pero todavía hay personas que nunca pueden iniciar sesión.
Además, la gente hace clic en un magic link de hace 6 meses y se frustra diciendo que “no funciona”, así que decidimos mostrar una página que, en vez de un mensaje de error, explica la situación y reenvía el enlace, al estilo Docusign.
La gente también suele escribir mal su dirección de correo y, cuando no recibe el código, culpa al sistema.
Aun así, siento que genera muchos menos tickets de soporte que el esquema de correo+contraseña, así que sigo prefiriendo los magic links.
Nunca he usado magic links, pero hace unos meses agregué Google Sign in a un SaaS y pasó a representar más del 90% de los nuevos registros.
Eso incluso con una base de usuarios de desarrolladores, que suele tener buen entendimiento técnico y alta sensibilidad por la privacidad; ya no creo que otro método sea prioritario. Claro que seguimos manteniendo correo/contraseña.
Un usuario+contraseña con un gestor de contraseñas, o passkeys, probablemente sea una de las pocas formas de intercambiar credenciales con cifrado de extremo a extremo sobre HTTPS y ofrecer una buena experiencia de usuario al público general.
El gestor de contraseñas garantiza que las credenciales solo se usen en el dominio correcto.
Era un cliente fiel de Mercury, pero incluso después de pasar por una contraseña segura, un administrador de contraseñas y un TOTP válido, cada vez que cambiaba la dirección IP me obligaban a usar un enlace mágico como tercer factor de autenticación, al punto de hacerme pensar en mover la cuenta bancaria de la empresa a otro lado
Lo entendería si iniciara sesión desde un lugar o ISP distinto al que usé durante los últimos 5 años, pero si lo único que cambió respecto de ayer es el último octeto de la dirección DHCP, no tiene sentido
Leo el correo por SSH desde una computadora distinta a la de navegación web, así que copiar y pegar un enlace de inicio de sesión de cientos de caracteres es un verdadero suplicio
En Emacs se muestra en varias líneas, y además hay que quitar manualmente los
\en los límites de líneaSi agregas fricción cada vez que inicio sesión, empeora la impresión de todas las interacciones posteriores en la app y me dan menos ganas de usarla
Si es un dispositivo usado anteriormente, no debería aparecer la solicitud de verificación de dispositivo. Para comprobarlo guardamos una cookie persistente, y tampoco la pedimos desde la misma IP. Me pregunto si tal vez las cookies se están borrando periódicamente
Agregamos esta función después de que atacantes crearan sitios clonados de http://mercury.com e incluso publicaran anuncios en Google
Cuando un cliente ingresaba su contraseña y TOTP en el sitio de phishing, el phisher usaba esas credenciales para iniciar sesión, crear tarjetas virtuales y comprar criptomonedas, oro, etc.; luego redirigía al usuario al Mercury real, esperando que lo tomara como un error temporal
Este enlace de verificación de dispositivo que enviamos aprueba la IP/el dispositivo desde donde se abre el enlace, y con este método hemos bloqueado casi por completo a los phishers
WebAuthn es inmune a este tipo de ataques de phishing, así que si usas WebAuthn no pedimos verificación de dispositivo
Si es posible, recomiendo mucho usar TouchID/FaceID o WebAuthn por dispositivo. Es más cómodo y más seguro, y puedes agregarlo aquí: https://app.mercury.com/settings/security
Dicho eso, estamos discutiendo este artículo internamente, y también somos conscientes de que, a medida que IPv6 se extienda más, las IP cambiarán con mucha más frecuencia. Vamos a considerar si debemos relajar la restricción de coincidencia con la misma IP
Me parece una muy buena reacción al artículo de 404 de la semana pasada. Me gusta 404, pero por las mismas razones que menciona el autor, los enlaces mágicos son molestos
Vale la pena leer el artículo que Ricky Mondello escribió la semana pasada[1], porque explica bien cómo las passkeys pueden usarse junto con los enlaces mágicos, como se insinuaba al final del artículo
[1]: https://rmondello.com/2025/01/02/magic-links-and-passkeys/
Intentabas iniciar sesión en la tienda, te pedía ingresar el código de dos pasos enviado por correo; no llegaba ningún correo durante varios minutos, pedías un código nuevo y tampoco llegaba; te rendías y te ponías a hacer otra cosa, y 30 minutos después llegaban ambos códigos
La verdad es que el correo electrónico es poco confiable incluso en el mejor de los casos. Puede irse a spam, el filtro antispam de la empresa puede bloquear el enlace, o la bandeja de entrada puede estar llena
En lo personal, solo tengo el correo en el iPhone, y para revisarlo en la laptop del trabajo o en la PC gamer tengo que iniciar sesión en icloud.com, lo cual es una molestia
Ojalá me dejaran ingresar una contraseña, o escanear un código QR como en dispositivos embebidos, o al menos me dieran alguna otra opción
Los enlaces mágicos te permiten acceder a las passkeys, y las passkeys son básicamente una versión reforzada de “recordar esta computadora”
Todavía estoy acostumbrado a la época en que casi no se veía públicamente a la gente de Apple
No sé si estoy entendiendo algo mal, pero no creo que las passkeys sean realmente una alternativa a los magic links.
Todas las implementaciones de passkeys que he visto hasta ahora sugerían crear una passkey después de haber iniciado sesión por algún otro medio.
No lo investigué a fondo, pero desde el punto de vista de la experiencia de usuario, las passkeys parecen más una alternativa al botón de “recordar esta computadora” que una alternativa a las contraseñas en general.
De una forma u otra, el servicio tiene que saber que este nuevo dispositivo fue aprobado.
Según el proveedor, puede haber sincronización de passkeys, pero eso no resuelve cómo hacer la autenticación inicial.
La idea central de los magic links es que un sistema de seguridad no puede ser más fuerte que su mecanismo de recuperación.
No llegará un mundo donde las passkeys se traten como el único medio de autenticación; siempre quedará un mecanismo de recuperación y, en la mayoría de los casos, será recuperación automática por email.
Entonces los magic links son honestos en el sentido de que simplifican las cosas sin fingir que encima hay una capa más segura.
Si conviertes el mecanismo de recuperación en el principal medio de interacción del flujo de autenticación, estás siendo más sincero sobre el nivel real de seguridad del sistema de autenticación.
Edit: filmgirlcw dejó un enlace a un mejor texto que explica cómo se complementan realmente ambos métodos: https://news.ycombinator.com/item?id=42628226
Los magic links tienen sus ventajas, pero no sé si convertir el email en un vector de ataque más potente sea una de ellas.
Para quienes usan un administrador de contraseñas, los magic links son claramente un punto de fricción, y las passkeys pueden reducirlo de forma clara.
Los problemas de experiencia de usuario de las passkeys también tienen margen de mejora, y cuando sea posible exportarlas, la sincronización entre sistemas mejorará mucho.
Una de las razones por las que uso 1Password como mi sistema principal de contraseñas y passkeys es precisamente el uso de passkeys entre dispositivos; mi empresa también usa 1Password, así que puedo tener iniciadas mis cuentas personal y corporativa y autenticarme desde un dispositivo personal o de trabajo cuando haga falta.
Dicho eso, si el problema que definió 404 es que no quiere asumir la responsabilidad de almacenar contraseñas o controles de autenticación, creo que para algunos usuarios las passkeys son mejores que los magic links.
Aun así, igual que Ricky, creo que no debería ser una u otra cosa, sino ambas.
[1]: https://rmondello.com/2025/01/02/magic-links-and-passkeys/
Usar passkeys no implica necesariamente que deba existir un método de inicio de sesión alternativo, pero todavía ningún servicio ha migrado a un modelo solo con passkeys.
Los usuarios de sistemas operativos antiguos o de Linux quizá todavía no puedan crear y guardar passkeys, y muchos usuarios no usan gestores de credenciales multiplataforma.
Por ejemplo, si creaste una passkey con iCloud Passwords, hoy no tienes forma de iniciar sesión desde Linux.
Creo que en unos años más empezaremos a ver flujos en los que los servicios hacen que crees una passkey desde el principio y ni siquiera recopilan contraseñas.
Espero que se implemente la especificación de portabilidad de passkeys y que Gnome/KDE también implementen soporte para passkeys.
Si usar el OTP del teléfono o copiar un enlace desde el teléfono cuando visitas un sitio web en una PC de trabajo es doloroso, me pregunto cuánto más fácil y mejor sería hacer que la computadora de trabajo se integre con una passkey personal que está en algún lugar como una laptop.
No uso servicios que solo soportan magic links para autenticación. Son muy hostiles con el usuario y, desde el punto de vista de seguridad, claramente peores que contraseñas usadas junto con un administrador de contraseñas.
Lo más grave es que, con mi configuración personal, directamente no funcionan.
Por seguridad y protección de cuentas, no accedo a mi cuenta de email desde los dispositivos que uso para iniciar sesión.
La única excepción que hago es Anthropic, porque Claude es el mejor LLM, pero cada vez que tengo que volver a iniciar sesión es un dolor enorme y ya envié varias quejas.
Cada vez que veo un magic link, siempre pienso: “¿No se suponía que, para empezar, no había que hacer clic en enlaces de emails?”
Cuando pienso en enlaces de email, también pienso en phishing.
Detesto los magic links.
El punto es no hacer clic en enlaces sospechosos. Si sabes que te enviaron un magic link, no es un enlace sospechoso.
Aun así, odio los magic links por la demora.
El enfoque de privacidad de email de Apple parece interesante. Apple siempre carga todas las imágenes, aunque no sé si eso tiene desventajas.
La mejor implementación que he visto exige hacer clic en el enlace desde el dispositivo donde se recibió el correo, pero no traslada la sesión a ese dispositivo, sino que completa el inicio de sesión en el dispositivo donde se inició originalmente el proceso de login
Una mejor solución es permitir el inicio de sesión solo en el dispositivo donde se abrió el enlace y, para usarlo entre dispositivos, ofrecer también un código OTP que pueda leerse en el dispositivo receptor e ingresarse fácilmente en el dispositivo original
O incluso podrían ofrecer solo un código OTP, sin enlace
No hay nada peor que estar trabajando en un navegador y que, al abrir el correo, te autentique en el navegador predeterminado o, peor aún, en otro dispositivo, obligándote a pasarle el enlace a ese lado y volver a abrirlo
Tampoco es un escenario tan extraño, porque a veces uno no quiere acceder a ciertos correos en ciertos dispositivos
El método en el que el sitio envía un OTP como
crazy-pink-horse-3837para que lo copies y pegues es un buen punto intermedio si implementar un enlace que autentique la solicitud original resulta demasiado difícilPero el problema de la implementación era que el enlace mágico que enviaba venía envuelto en un rastreador de clics, y ese dominio era bloqueado por herramientas como pihole
Así que no se podía llegar a la URL real de autenticación ni completar el proceso de login
Los navegadores integrados en apps deberían desaparecer. En especial los que no permiten elegir “abrir en el navegador normal”, y si se trata de un lector RSS, obviamente debería ofrecer esa opción
Todos los product managers que obligaron a los usuarios a usar navegadores integrados deberían ir a la cárcel
Una opción mucho mejor es usar un código OTP enviado por correo y passkeys con la UI de Conditional Mediation
Si el usuario inicia sesión desde un dispositivo que ya tiene una passkey, la UI de CM puede permitir seleccionarla de inmediato e iniciar sesión al instante
Si es un dispositivo sin passkey, se puede diseñar una experiencia en la que el usuario ingrese el código del correo y, si tiene éxito, configure de inmediato una passkey para poder iniciar sesión directamente la próxima vez
Así se obtiene la seguridad de las passkeys en los dispositivos existentes, y una configuración sin contraseña y recuperación de cuenta en dispositivos nuevos
Como extra, también se evita el vendor lock-in de que un proveedor de nube tenga todas las passkeys