security - nombre - ¿Cuáles son las mejores prácticas para los enlaces de activación/registro/restablecimiento de contraseña en correos electrónicos con nonce

como recuperar contraseña de correo

Question

Las aplicaciones envían correos electrónicos para verificar cuentas de usuario o restablecer una contraseña. Creo que la siguiente es la forma en que debería ser y estoy pidiendo referencias e implementaciones.

Si una aplicación tiene que enviar un enlace en un correo electrónico para verificar la dirección del usuario, según mi punto de vista, el enlace y el procesamiento de la aplicación del enlace deben tener las siguientes características:

1. El enlace contiene un nonce en el URI de solicitud ( http://host/path?nonce ).
2. Al seguir el enlace (GET), se le presenta al usuario un formulario, opcionalmente con el nonce.
3. El usuario confirma la entrada (POST).
4. El servidor recibe la solicitud y
   • verifica los parámetros de entrada
   • realiza el cambio,
   • e invalida el nonce.

Esto debería ser correcto según HTTP RFC en Métodos Seguros e Idempotentes .

El problema es que este proceso implica una página adicional o acción del usuario (elemento 3), que muchas personas consideran superflua (si no inútil). Tuve problemas para presentar este enfoque a mis compañeros y clientes, por lo que solicito la opinión de un grupo técnico más amplio. El único argumento que tuve para evitar el paso POST fue una posible precarga del enlace desde el navegador.

• ¿Hay referencias sobre este tema que podrían explicar mejor la idea y convencer incluso a una persona no técnica (mejores prácticas de revistas, blogs, ...)?
• ¿Existen sitios de referencia (preferiblemente populares y con muchos usuarios) que implementen este enfoque?
  • Si no, ¿hay razones documentadas o alternativas equivalentes?

Gracias,
Kariem

Detalles perdonados

He mantenido la parte principal corta, pero para reducir demasiado la discusión sobre los detalles que intencionalmente había omitido, agregaré algunas suposiciones:

• El contenido del correo electrónico no es parte de esta discusión. El usuario sabe que tiene que hacer clic en el enlace para realizar la acción. Si el usuario no reacciona, no pasará nada, que también es conocido.
• No tenemos que indicar por qué estamos enviando correos al usuario, ni la política de comunicación. Suponemos que el usuario espera recibir el correo electrónico.
• El nonce tiene una marca de tiempo de vencimiento y está directamente asociado con la dirección de correo electrónico de los destinatarios para reducir los duplicados.

Notas

Con OpenID y similares, las aplicaciones web normales se liberan de la implementación de la administración de cuentas de usuario estándar (contraseña, correo electrónico ...), pero aún así algunos clientes quieren '' sus propios usuarios ''.

Por extraño que parezca, todavía no he encontrado una pregunta satisfactoria ni una respuesta. Lo que he encontrado hasta ahora

• Respuesta de Don en HTTP POST con parámetros de consulta de URL. ¿Buena idea o no?
• Pregunta de Thomas: ¿ Cuándo usas POST y cuándo usas GET?

Answer 1

Acerca del restablecimiento de contraseña:

La práctica de hacer esto enviando un correo electrónico a la dirección de correo electrónico registrada del usuario es, aunque es muy común en la práctica, una falta de seguridad. Hacer esto externaliza completamente la seguridad de su aplicación al proveedor de correo electrónico del usuario. No importa la cantidad de contraseñas que requiera ni la cantidad de contraseñas inteligente que use. Podré acceder a su sitio leyendo el correo electrónico enviado al usuario, dado que tengo acceso a la cuenta de correo electrónico o puedo leer el correo electrónico no cifrado en cualquier lugar en el camino hacia el usuario (piense: evil sysadmins).

Esto puede o no ser importante dependiendo de los requisitos de seguridad del sitio en cuestión, pero yo, como usuario del sitio, al menos quisiera poder desactivar dicha función de restablecimiento de contraseñas ya que lo considero inseguro.

Encontré este libro blanco que analiza el tema.

La versión corta de cómo hacerlo de forma segura:

1. Requerir hechos concretos sobre la cuenta

   1. nombre de usuario
   2. dirección de correo electrónico.
   3. Número de cuenta de 10 dígitos u otra información como el número de seguro social.

2. Exija que el usuario responda al menos tres preguntas predefinidas (predefinidas por usted, no permita que el usuario cree sus propias preguntas) que no pueden ser triviales. Como "¿Cuál es tu lugar de vacaciones favorito", no "¿Cuál es tu color favorito".

3. Opcionalmente: envíe un código de confirmación a una dirección de correo electrónico o número de celular (SMS) predefinido que el usuario debe ingresar.

4. Permitir al usuario ingresar una nueva contraseña.

Answer 2

Esta pregunta es muy similar a la implementación de URL de activación seguras y exclusivas de "uso único" en ASP.NET (C #) .

Mi respuesta está cerca de su esquema, con algunos problemas señalados, como un breve período de validez, manejo de registros dobles, etc.
También es importante su uso de una función criptográfica , que muchos tienden a omitir, por ejemplo, "solo usemos un GUID" ...

Un nuevo punto que usted plantea, y esto es importante aquí, es la idempotencia de GET.
Si bien estoy de acuerdo con su intención general, es claro que la idempotencia está en contradicción directa con los enlaces de una sola vez, que es una necesidad en algunas situaciones como esta.

Me hubiera gustado postular que esto realmente no viola la idempotencia del GET, pero lamentablemente sí lo hace ... Por otro lado, el RFC dice que DEBE ser idempotente, no es IMPRESCINDIBLE. Por lo tanto, me gustaría renunciar a esto en este caso y atenerme a los enlaces de invalidación automática de una sola vez.

Si realmente desea apuntar a un estricto cumplimiento RFC, y no entrar en GET no ideopotentes (?), Puede hacer que la página GET envíe automáticamente el POST - tipo de laguna alrededor de ese bit del RFC, pero legítimo, y no requiere que el usuario opte por doble, y no lo está molestando ...

No tiene que preocuparse por la precarga (¿está hablando de CSRF u optimizadores de navegador?) ... CSRF es inútil debido a la falta de sincronización, y los optimizadores generalmente no procesan javascript (usado para enviar automáticamente) en la página precargada.

Answer 3

Generalmente estoy de acuerdo con usted con alguna modificación sugerida a continuación.

1. El usuario se registra en su sitio y proporciona un correo electrónico.
2. El correo electrónico de verificación se envía a la cuenta de los usuarios con dos enlaces: a) Un enlace con el GUID para verificar el registro b) Un enlace con el GUID para rechazar la verificación
3. Cuando visitan la url de verificación de su correo electrónico, se verifican automáticamente y la guía de verificación se marca como tal en su sistema.
4. Cuando visitan la URL de rechazo de su correo electrónico, se eliminan automáticamente de la cola de posibles verificaciones, pero lo más importante es que puede decirle al usuario que lamenta el registro por correo electrónico y brindarles más opciones, como eliminar el correo electrónico de su sistema. Esto detendrá cualquier queja de tipo de servicio personalizado sobre alguien que ingresa mi correo electrónico en su sistema ... bla, bla, bla.

Sí, debe suponer que cuando hacen clic en el enlace de verificación, se verifican. Hacer que hagan clic en un segundo botón en una página es un poco mucho y solo se necesita para optar por el doble en el registro de estilo donde planea enviar correo no deseado a la persona que se registró. Los esquemas de registro / verificación estándar generalmente no requieren esto.