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

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, de acuerdo con mi punto de vista, el vínculo y el procesamiento de la aplicación de la relación 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
   • parámetros de entrada cheques,
   • realiza el cambio,
   • e invalida el nonce.

Ésta debe ser correcta por HTTP RFC on Safe and Idempotent Methods.

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.

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

Gracias,
Kariem

---

detalles salvó

he guardado la parte principal corto, pero para reducir el exceso de discusión en torno a los detalles que he tenido intencionalmente omitido, añadiré algunas suposiciones:

• El contenido del correo electrónico no forma 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 el correo 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 similares, aplicaciones web normales OpenID y están exentos de la aplicación de gestión de cuenta de usuario estándar (contraseña, correo electrónico ...), pero todavía algunos clientes quieren 'su propios usuarios '

Curiosamente, todavía no he encontrado una pregunta satisfactoria ni una respuesta. Lo que he encontrado hasta ahora:

• Answer by Don in HTTP POST with URL query parameters — good idea or not?
• Question from Thomas -- When do you use POST and when do you use GET?

Answer 1

Esta pregunta es muy similar a Implementing secure, unique “single-use” activation URLs in ASP.NET (C#).

Mi respuesta no está cerca de su esquema, con algunas cuestiones señaló - tales como corto período de validez, el manejo de dobles inscripciones, etc.
El uso de un criptográfica nonce es también importante, que muchos tienden 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 a postular que esto realmente no viola la idempotentness del GET, pero desafortunadamente ... Por otro lado, el RFC dice consigue DEBERÍAN idempotente, no es una necesidad.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 para el estricto cumplimiento de RFC, y no entrar en no idempotente GET, puede hacer que la página de obtención automática a presentar el POST - una especie de vacío legal en torno a ese poco de la RFC, pero legítimo, y no requiere que el usuario opte por doble, y no le está molestando ...

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

Answer 2

por lo general de acuerdo con usted con alguna modificación se sugiere a continuación.

1. El usuario se registra en su sitio proporcionando un correo electrónico.
correo electrónico
2. verificación se envía a los usuarios de la cuenta con dos enlaces: a) Un vínculo con el GUID para verificar el registro b) Un vínculo 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 que es más importante, puede decirle al usuario que lamenta el registro de correo electrónico y darles más opciones como eliminar su correo electrónico. 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 que están verificados. 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.

Answer 3

Acerca de 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, si bien es muy común en la práctica, no es bueno 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 querría poder desactivar dicha función de restablecimiento de contraseña ya que lo considero inseguro.

He encontrado this white paper que trata sobre el tema.

La versión corta de cómo hacerlo de una manera segura:

1. Requerir datos concretos sobre la cuenta

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

2. requieren que el usuario responde al menos tres preguntas predefinidas (predefinidos por usted, no permiten al usuario crear sus propias preguntas) que no puede ser trivial. Como "¿Qué es su lugar de vacaciones favorito", no "¿Cuál es tu color favorito".

3. Opcionalmente: enviar un código de confirmación a una dirección de correo electrónico o número predefinido celular (SMS) que el usuario ha de introducir.

4. Permitir al usuario que introduzca una nueva contraseña.