¿Mejores prácticas para contraseñas en el registro?

Su desarrollador está tratando de combinar tres procesos diferentes en uno: registro de contraseña, validación de correo electrónico y detección de robot. Desafortunadamente, eso hace que toda la configuración sea menos segura y menos resistente de lo que debería ser.

• El correo electrónico es un texto claro y, en la actualidad, garantiza en gran medida vivir para siempre y ser incluido en varios índices y, a menudo, mantenerse durante mucho tiempo en varios servidores a lo largo del camino. Si le envió una contraseña a alguien por correo electrónico, está seguro de que la está haciendo muy vulnerable. El correo electrónico no es seguro a menos que lo asegure explícitamente (S / MIME o PGP).
• El correo electrónico no es un proceso síncrono: no hay un tiempo mínimo para que un correo electrónico llegue a su objetivo. De hecho, a menudo puede tomar varios minutos para que un correo electrónico llegue al servidor de correo final. Esto hace que todo el proceso sea lento y hostil para el usuario final.
• El correo electrónico no es muy confiable: como ha descubierto, el correo electrónico se puede perder por varios motivos sin que se notifique a nadie. Como tal, lo convierte en un medio realmente deficiente para transmitir información importante, crítica en cuanto al tiempo, como la información de conexión inicial.
• Para la detección de robots, este proceso es terriblemente ineficiente: hay muchos servicios de correo electrónico desechables que pueden se puede utilizar fácilmente para solucionar este proceso (o dominios de correo de captura completa ).

Ahora, no hay una manera "correcta" de hacer esto: lo que funcionará mejor dependerá en gran medida del nivel de seguridad que necesite y de cómo lo compense con la facilidad de uso: no es lo mismo diseñar seguridad para un sitio web bancario que para un repositorio de recibos de cocina.

Sin embargo, es importante recordar estas cosas al diseñar el sistema (y mantener la coherencia, que es, en mi opinión, el problema que tiene con el suyo):

• ¿Cuál es tu público objetivo? Esto le permitirá saber cuán complejo para el usuario puede realizar el proceso de registro.
• ¿Cuál es el valor del registro en su sitio web para sus usuarios? Esto debería indicarle cuánto esfuerzo puede esperar de ellos.
• ¿Cuál es el valor del registro para usted? Debería indicarle cuánto esfuerzo debe poner en la verificación de los detalles del registro.
• ¿Cuál es el valor del registro para un tercero potencialmente hostil? Debería indicarle cuánto esfuerzo debe hacer para asegurarse de que la información del usuario esté segura.

OWASP tiene una hoja de trucos que describe los elementos de un proceso de autenticación seguro. Su guía de autenticación es un poco de luz sobre el tema, pero trae algún buen elemento sobre cómo hazlo bien (o no lo hagas mal).

Este es un tema complejo si me preguntas.

Si permite que alguien ingrese la contraseña y el nombre de usuario por adelantado en el formulario de registro del proceso de registro y los haga trabajar de inmediato, entonces tiene un problema cuando se trata de notificar a su usuario por cualquier motivo, si no lo está. Notificado por sus mensajes en el correo electrónico proporcionado. Hay muchas razones por las que podría suceder, incluyendo:

• el usuario informó el correo electrónico incorrecto (error tipográfico o cualquier otra razón);
• el mensaje va a su carpeta de SPAM;
• su sistema no está autorizado por el usuario para enviarle mensajes: algunos proveedores de correo electrónico tienen algún sistema en el que responderían automáticamente con un correo electrónico que proporciona instrucciones sobre cómo proceder para recibir los mensajes, con el fin de Proteger contra la mayoría de SPAM. Tal vez el usuario tendría que configurar alguna excepción para no requerir esos pasos de algunos remitentes;
• el buzón está lleno;

Cualquiera sea la razón, si la aplicación requiere validación de correo electrónico para permitir que el usuario acceda a ella, es menos probable que su sistema no pueda enviar mensajes a sus usuarios. El envío de múltiples correos electrónicos a usuarios no válidos puede aumentar las posibilidades de que su sistema de entrega de correo electrónico se marque automáticamente como SPAM, y no desea eso.

Hay otro problema a considerar. ¿Qué sucede si el usuario proporcionó otro correo electrónico válido debido a algún error tipográfico? Luego habría otro usuario recibiendo todos esos mensajes molestos. O que otro usuario podría incluso hacerse cargo de esa cuenta si lo deseara. Esas son algunas de las razones por las que se desea la verificación por correo electrónico.

Por lo tanto, un enfoque para la autenticación del usuario es simplemente solicitar la dirección de correo electrónico del usuario en el primer paso del proceso de registro. No solicite nada más para no molestar al usuario que se registra en su aplicación. Sólo la dirección de correo electrónico. Luego obtendrían un enlace con un token aleatorio generado por unos minutos. Una vez que el usuario haga clic en el enlace, pasará al siguiente paso del registro y ese correo electrónico se marcará como confirmado.

Algo a considerar en este enfoque es que alguien podría usar esto para, de manera intencional o no, enviar SPAM a otro usuario con mensajes molestos y pedirle al usuario que proceda con el registro que no ha solicitado. No estoy seguro de cómo evitarlo, pero probablemente sea una buena idea limitar los mensajes por límite de velocidad. Por ejemplo, un token podría ser válido durante 10 minutos y, si bien es válido, el sistema no enviaría otro token por correo electrónico. Esos usuarios podrían molestarse con los mensajes cada 10 minutos, pero tal vez querría manejar estos casos una vez que sucedan.

No hay absolutamente ninguna razón para enviar contraseñas a los correos electrónicos con fines de recuperación. Los tokens deberían usarse en su lugar y luego la aplicación podría solicitar una contraseña. Solo tenga en cuenta que una contraseña no es realmente necesaria para autenticar a un usuario si su dirección de correo electrónico es válida. Siempre pueden solicitar un token cuando desean iniciar sesión, sin proporcionar nunca una contraseña.

Si aún prefiere que se muestre el formulario de registro completo por adelantado, también existe la posibilidad de solicitar al usuario que confirme su dirección de correo electrónico para poder recibir cualquier mensaje que se le envíe. De esta manera, el sistema nunca intentará enviar mensajes a direcciones de correo electrónico no verificadas. Cuando estén usando la aplicación, se podría mostrar un ícono de notificación para recordarle al usuario que su dirección de correo electrónico aún no está verificada, lo que significa que no podrá recuperarse de una contraseña perdida ni recibir notificaciones de la aplicación por parte de correo electrónico.

Además, tenga en cuenta que los nombres de usuario no son realmente necesarios si establece una restricción única en la dirección de correo electrónico para que se pueda proporcionar el correo electrónico en lugar de un nombre de usuario con fines de autenticación. Es posible que desee mantener las direcciones de correo electrónico en una tabla separada para admitir múltiples correos electrónicos por cuenta.