Planteamiento y contexto
Un usuario con la sesión iniciada envía una nueva dirección de correo electrónico. El servicio debe comprobar el control de la nueva dirección y, al mismo tiempo, reducir el riesgo de toma de control de la cuenta debido a una sesión robada, enumeración de correos electrónicos, clics repetidos y solicitudes concurrentes. Explica el modelo de datos, el ciclo de vida del token, las notificaciones, la política de sesiones, los límites de tasa, los eventos de auditoría y la ruta de recuperación.
Asume que cambiar un correo electrónico afecta el inicio de sesión, la recuperación de contraseña y los avisos de seguridad, por lo que es una acción de cuenta de alto riesgo. La sesión actual podría estar comprometida, cualquiera de las dos direcciones podría estar temporalmente inaccesible y solo puede haber una solicitud de cambio activa para una cuenta.
Qué evalúa el entrevistador
El entrevistador busca escuchar una distinción entre una sesión activa y una identidad recientemente revalidada. Las respuestas sólidas exigen reautenticación o un método de autenticación multifactor existente para cuentas de alto riesgo. Mantienen la dirección propuesta por separado hasta que la comprobación sea exitosa.
También buscan un token aleatorio de un solo uso, tiempo de vida corto, resumen (digest) del token en el servidor, prevención de repetición (replay), notificación a la dirección antigua, errores uniformes y eventos de auditoría. Las respuestas excelentes cubren la revocación de sesiones, la recuperación y los invariantes para actualizaciones concurrentes.
Respuesta de 30 segundos
«Exigiría una reautenticación reciente y un método MFA existente para cuentas de mayor riesgo. Almacenaría la dirección propuesta en un registro pendiente separado en lugar de reemplazar la actual. Se enviaría por correo a la nueva dirección un token criptográficamente aleatorio y de un solo uso; la base de datos conservaría únicamente su resumen (digest), propósito, expiración y estado de consumo. La transacción de confirmación bloquea la cuenta, verifica el resumen, la expiración y la versión, y luego cambia la dirección de forma atómica y marca la solicitud como consumida. La dirección antigua recibe un aviso de seguridad y una opción de cancelación. Las sesiones se revocan o se someten a autenticación reforzada (step-up) según el riesgo. Las respuestas son seguras contra la enumeración, las solicitudes tienen límites de tasa y los eventos de auditoría nunca contienen el token».
Análisis detallado paso a paso
Paso 1: Modelar la cuenta y la solicitud pendiente
Mantén current_email en la cuenta y almacena un registro pending_email_change separado que contenga el ID de la cuenta, la dirección propuesta normalizada, el resumen del token, el propósito, la expiración, el estado, la versión, la hora de creación y el contexto de riesgo de la sesión que inició la solicitud. Hasta que la comprobación tenga éxito, el valor propuesto no debe afectar el inicio de sesión ni la recuperación.
Paso 2: Reautenticar y establecer el límite de riesgo
Un inicio de sesión activo solo demuestra que la sesión es aceptada. Exige una verificación de contraseña reciente o un factor MFA existente, y considera las señales del dispositivo, la IP y las anomalías. Conocer la nueva dirección no demuestra la identidad actual. El resultado del step-up debe ser de corta duración y de un solo propósito, no una credencial universal duradera.
Paso 3: Generar y entregar un token de un solo uso
Utiliza un generador aleatorio criptográficamente seguro, un TTL corto y un único propósito. Almacena solo un resumen unidireccional en la base de datos; el enlace del correo electrónico lleva el token en bruto. El mensaje no debe revelar si existe una cuenta. Los reenvíos se limitan por tasa e invalidan los tokens anteriores. Los tokens consumidos, expirados o reemplazados no se pueden reutilizar.
Paso 4: Verificar y confirmar atómicamente
Al confirmar, realiza comprobaciones de formato y de límites de tasa, luego bloquea la cuenta y la fila pendiente en una sola transacción. Compara el resumen en tiempo constante y comprueba el estado, el TTL, el propósito y la versión. Aplica la unicidad de la nueva dirección en la misma transacción, actualiza atómicamente el correo electrónico actual, marca la solicitud como consumida y añade un evento de auditoría. Un clic duplicado devuelve un resultado procesado idempotente o seguro sin repetir efectos secundarios.
Paso 5: Gestionar la dirección antigua, las sesiones y los avisos
Envía a la dirección antigua un aviso de seguridad y permite la cancelación mientras la solicitud aún esté pendiente. Si la operación tiene éxito, revoca los refresh tokens de larga duración o exige que otras sesiones se reautentiquen; las cuentas de alto riesgo pueden requerir una revocación global inmediata. La nueva dirección no debe convertirse en la única prueba de recuperación instantánea.
Paso 6: Controlar la enumeración, el abuso y las carreras
Utiliza tiempos y mensajes uniformes para los endpoints de solicitud y confirmación, de modo que los atacantes no puedan saber si una dirección está registrada. Aplica límites de tasa por cuenta, dirección de destino, dispositivo y red. Una restricción de unicidad combinada con bloqueo de filas o actualización condicional de versión evita que dos solicitudes tengan éxito; la comprobación de ocupación y la escritura comparten el mismo límite de transacción.
Paso 7: Diseñar la recuperación y los casos de indisponibilidad
Permite reenvíos limitados ante retrasos en la entrega mientras se invalidan los tokens antiguos. Si se pierde el acceso a la dirección antigua, no aceptes una nueva dirección no verificada como prueba suficiente de toma de control; utiliza el proceso de recuperación más estricto de la cuenta. Los fallos de entrega, las direcciones ocupadas y las denegaciones por políticas deben mostrar mensajes seguros a la vez que conservan códigos de motivo internos en los registros de auditoría.
Paso 8: Probar amenazas y medir resultados
Prueba sesiones robadas, repetición y expiración de tokens, confirmaciones concurrentes, cancelación desde la dirección antigua, revocación de refresh tokens, propiedad de direcciones entre cuentas y enumeración de endpoints. Mide los fallos de step-up, los intentos de repetición, la latencia entre confirmación y revocación, la entrega de notificaciones y el volumen de recuperación manual. Una prueba de fuga de base de datos debe demostrar que los resúmenes almacenados no son tokens utilizables.
Compensaciones, límites y ganancia de información
Un TTL corto reduce la exposición, pero aumenta la necesidad de reenvíos cuando el correo se retrasa; los reenvíos acotados y un estado explícito equilibran ambos factores. Revocar todas las sesiones es más seguro, pero interrumpe el uso en múltiples dispositivos, por lo que los niveles de riesgo pueden determinar el alcance. Una ventana de cancelación para la dirección antigua mejora la recuperación, pero no puede deshacer un cambio de alto riesgo ya completado.
El almacenamiento exclusivo de resúmenes protege contra la filtración de la base de datos, pero los tokens en bruto aún pueden filtrarse a través de enlaces, historial del navegador, registros, rastreo y analíticas. Filtra esas rutas y redirige tras el consumo a una URL limpia. Una restricción de unicidad simplifica la propiedad de la identidad, pero el producto debe definir si una misma dirección puede pertenecer a varias cuentas.
Respuesta modelo de alta calidad
«Trataría el cambio de correo electrónico como una máquina de estados de alto riesgo. El usuario completa una reautenticación reciente y, cuando sea necesario, una comprobación de MFA existente. La dirección propuesta pasa a un registro pendiente; la dirección actual sigue siendo la autoritativa para el inicio de sesión y la recuperación. Un CSPRNG genera un token de un solo uso con un TTL corto, mientras que la base de datos solo almacena su resumen, propósito, versión y estado.
La transacción de confirmación bloquea la cuenta y la solicitud, comprueba el resumen, la expiración, la versión y la restricción de unicidad, y luego actualiza la dirección de forma atómica, marca la solicitud como consumida y registra un evento de auditoría. La dirección antigua recibe un aviso de seguridad y puede cancelar una solicitud aún pendiente. Tras el éxito, se revocan los refresh tokens y las demás sesiones deben volver a autenticarse según el riesgo.
Todos los endpoints utilizan errores uniformes y límites de tasa por cuenta, destino y red. Los registros contienen códigos de motivo en lugar de tokens. La repetición, las condiciones de carrera, los buzones antiguos perdidos y los fallos de entrega tienen cada uno una ruta de recuperación definida, y las pruebas miden la expiración de tokens, la latencia de revocación y la resistencia a la enumeración».
Errores comunes
- Reemplazar la dirección al enviar el formulario. Una dirección no comprobada puede bloquear al usuario o permitir que una sesión robada tome el control.
- Confiar únicamente en la sesión existente. Quien robe la sesión puede completar una acción de alto riesgo.
- Almacenar tokens en bruto en bases de datos o registros. Esos sistemas se convierten en vías para la toma de control de cuentas.
- Permitir la reutilización de tokens. La repetición puede duplicar notificaciones o sobrescribir la dirección.
- Revelar la existencia de direcciones. Las respuestas de confirmación y de solicitud se convierten en un oráculo de enumeración.
- Ignorar las condiciones de carrera de unicidad. Dos cuentas o solicitudes podrían reclamar la misma dirección.
- Mantener todas las sesiones de larga duración tras el éxito. Un refresh token robado sigue siendo útil.
- Confiar en una nueva dirección cuando se pierde la antigua. Esto elude las garantías de recuperación de la cuenta.
Preguntas de seguimiento y respuestas
¿Por qué no escribir primero la nueva dirección y verificarla de forma asíncrona?
El inicio de sesión, la recuperación y los avisos podrían consumirla de inmediato, mientras que una reversión (rollback) introduce condiciones de carrera. Un valor pendiente separado mantiene la entrada no verificada fuera del límite de identidad.
¿Cuánto tiempo debe vivir el token?
No existe un número independiente del riesgo. Elige una ventana corta basada en la distribución de entrega y los objetivos frente a amenazas, añade reenvíos acotados y mide el comportamiento real desde la emisión hasta la expiración.
¿Puede un aviso a la dirección antigua sustituir a la MFA?
No. El aviso y la cancelación son mecanismos de defensa en profundidad y señales de recuperación, no una prueba de identidad de alta seguridad. Las cuentas de alto riesgo aún necesitan un método MFA existente o una recuperación más estricta.
¿Qué ocurre si dos pestañas confirman simultáneamente?
Utiliza una versión, un estado de un solo uso y un bloqueo de transacción para que solo una solicitud pase de pendiente a consumida. La segunda solicitud devuelve un resultado idempotente y no ejecuta efectos secundarios duplicados.
¿Cómo se mantienen los tokens fuera de las analíticas?
Utiliza una ruta de un solo uso, filtra los parámetros de consulta en el edge y en las capas de aplicación, redirige a una URL limpia tras el consumo y desactiva el almacenamiento en caché para respuestas sensibles.