Estamos implementando el restablecimiento automático de la contraseña en una aplicación web, y sé cómo deseo hacerlo (URL de restablecimiento de la contraseña limitada en el tiempo del correo electrónico para los usuarios de direcciones de correo electrónico previamente registradas).
Mi problema es que no puedo encontrar ninguna referencia que indique a los desarrolladores que usen esa técnica. ¿Alguien puede indicarme algunas buenas referencias sobre esta técnica?
Algunas sugerencias:
No restablezca la contraseña del usuario hasta que se confirme. No reinicie inmediatamente la contraseña del usuario. Solo restablézcalo una vez que el usuario haga clic en un enlace de confirmación enviado a su dirección de correo electrónico previamente registrada.
Requerir un CAPTCHA. Cuando un usuario solicita que se restablezca su contraseña, obligue a resolver un CAPTCHA antes de continuar. Esto es para evitar que las herramientas automatizadas intenten causarle dolor a muchos usuarios y obligar al usuario a demostrar que son humanos (no un robot).
Aleatoriedad. La URL de restablecimiento de contraseña por tiempo limitado debe incluir un componente aleatorio e indiscutible. Asegúrate de usar aleatoriedad de calidad criptográfica. La salida de /dev/urandom o System.Security.Cryptography.RNGCryptoServiceProvider sería una buena opción. La salida de rand() o random() o System.Random no es lo suficientemente aleatoria y sería una mala elección. Un GUID o marca de tiempo no es lo suficientemente aleatorio y no sería una buena opción.
Incluya un límite de tiempo. El enlace de confirmación de restablecimiento debe expirar después de un tiempo razonable: por ejemplo, 24 horas. El enlace debe ser utilizable solo una vez, y debe expirar inmediatamente tan pronto como se use.
Incluya texto explicativo en el correo electrónico. Es posible que desee agregar un texto explicativo al correo electrónico, para explicar por qué se envió el correo electrónico, en caso de que alguien solicite un restablecimiento de una cuenta que no sea suya. propio. Podría incluir un texto como "Alguien ha solicitado que se restablezca la contraseña de su cuenta username en site . Si realizó esta solicitud, haga clic aquí para cambiar su contraseña. Si no la hizo, haga clic aquí para Cancelar la solicitud. "
Enviar correo electrónico una vez que se haya restablecido la contraseña. Una vez que la contraseña se haya restablecido correctamente, envíe un correo electrónico al usuario para informarle que se ha cambiado la contraseña. No incluya la nueva contraseña en ese correo electrónico.
Cancelaciones de monitores. Podría considerar incluir alguna lógica para monitorear la frecuencia con la que los usuarios hacen clic en el enlace de cancelación, lo que indica que no solicitaron un reinicio. Si esto supera un cierto umbral, puede ser útil enviar una alerta a los operadores del sistema. Además, si se visita un enlace de cancelación para alguna solicitud después de , se visita el enlace de confirmación, eso es una posible indicación de un ataque contra ese usuario; es posible que desee tomar medidas en ese punto, por ejemplo, invalidar La contraseña del usuario y le requieren restablecer su contraseña de nuevo. (Esta es una defensa contra el siguiente ataque: el atacante obtiene acceso al buzón del usuario, luego solicita que se restablezca su contraseña en su sitio y luego visite el enlace de confirmación. Si el atacante no elimina estos correos electrónicos de la bandeja de entrada del usuario, luego, cuando el usuario real lee su correo electrónico, puede hacer clic en el enlace de cancelación, lo que le da una indicación de posibles problemas.
Use HTTPS. El enlace debe usar https (no http :), para protegerse contra varios ataques (por ejemplo, ataques de Firesheep a usuarios que navegan por Internet desde un café de Internet).
Registrar estas operaciones. Sugiero registrar todas esas solicitudes. Además de registrar el nombre de usuario del usuario, es posible que desee registrar la dirección IP del cliente que solicitó que se envíe por correo electrónico un enlace de restablecimiento al usuario, así como la dirección IP del cliente que visitó el enlace de restablecimiento.
Lectura adicional. También puede leer la excelente publicación del blog de Troy Hunt, Todo lo que siempre quiso saber sobre la creación de una función de restablecimiento de contraseña segura . Gracias a @coryT por un enlace a este recurso.
Por último, considere la autenticación sin contraseña. Las contraseñas tienen muchos problemas como mecanismo de autenticación, y puede considerar otros métodos de autenticación de usuarios, como el almacenamiento de una cookie segura y persistente en su máquina con un indiscutible Secreto para autenticarlos. De esta manera, no se puede olvidar una contraseña y no se puede falsificar al usuario, aunque sí necesita proporcionar una forma para que el usuario autorice el acceso desde una nueva máquina o un nuevo navegador (posiblemente por correo electrónico a los usuarios que lo soliciten previamente). Dirección de correo electrónico registrado). Este documento de encuesta tiene una excelente encuesta de muchos métodos de autenticación de respaldo y sus fortalezas y debilidades.
Troy Hunt tiene una muy buena reseña sobre esta pregunta exacta. Todo lo que siempre quiso saber sobre la creación de una función de restablecimiento de contraseña segura
Bien, entonces su pregunta es, ¿cómo debería estructurar el proceso de recuperación de la cuenta / contraseña? Eso dependerá de lo que desee optimizar para: una experiencia de usuario sin complicaciones o una buena seguridad.
Si desea una buena seguridad:
Durante el registro, el usuario debe ingresar un canal secundario para la autenticación: número de teléfono móvil o pregunta de desafío & conteste (es decir, " cuál es el nombre de soltera de su madre " o mejor).
Durante la recuperación, su sistema primero obtiene una verificación aproximada de la identidad por medio del canal secundario anterior: la pregunta de seguridad, o mediante el envío de un código SMS al teléfono móvil o similar.
Cuando se borra la primera verificación de identidad anterior, el sistema envía un correo electrónico de restablecimiento de contraseña solo a la dirección de correo electrónico ingresada anteriormente . Esta es una medida adicional importante para prevenir f.x. vulnerabilidades de tipo Sarah Palin .
El correo electrónico no debe contener una nueva contraseña o similar. Debería tener un enlace de acceso a una página web cifrada HTTPS en su sitio que a) esté vinculada a la cuenta a través de un valor secreto no adivinable que se proporciona en la URL, b) tiene un límite de tiempo, por lo que la recuperación de la cuenta solo funciona x horas después de que se solicitó, c) proporciona una manera para que el usuario final cree una contraseña de nueva .
Tenga un buen inicio de sesión en todas las transacciones de restablecimiento de cuenta, y haga que un ser humano realmente las supervise y actúe si parece sospechoso (mire los registros del servidor para las direcciones IP fx, ¿muchas solicitudes provienen de la misma dirección IP?) , ¿hay instancias en las que un usuario esté intentando restablecer las contraseñas de un país diferente al propietario de la cuenta registrada, etc.?
También puede eludir esta complejidad por completo: todavía son primeros días, pero OAuth / OpenID / iniciar sesión a través de Facebook, Google, etc. elimina esta complejidad completamente de sus sistemas, pero con un quizás una usabilidad menos bien establecida .
Cualquier lugar que pueda enviarte una contraseña significa que no tienen hash de la contraseña, sino que la almacenan donde de alguna manera se puede descifrar en "texto sin formato". Esto por sí mismo es malo.
Probablemente no sea "más" seguro, pero más seguro sería:
Al solicitar la contraseña, envíe un enlace para restablecer la contraseña al usuario con GUID incorporado. La sesión en el GUID caduca en, hmm, aproximadamente una hora.
Otro que puede o no ser apropiado para su aplicación, pero que se usa en aplicaciones de banca en línea y otros tipos similares, es enviar la mitad del código de reinicio mediante mensajes SMS a un teléfono móvil registrado. Desde la perspectiva de un atacante, este es un PITA completo, ya que requiere el compromiso de un par de canales para interrumpirse.
La forma más segura de realizar un restablecimiento de contraseña es generar un token de reinicio único único aleatorio grande, con una fecha de caducidad, vinculado a la ID de usuario. El token se debe incluir en la base de datos, ya que un atacante con acceso a SQL podría usarlo para restablecer contraseñas de usuarios arbitrarias.
Se debe enviar un enlace de restablecimiento a la dirección de correo electrónico, que contiene el token de restablecimiento. Cuando el usuario haga clic en el enlace, el hash del token se encontrará en la base de datos y se verificará la fecha de caducidad en el futuro. Si se cumplen estas condiciones, se le debe presentar al usuario una pantalla que le permita ingresar una nueva contraseña.
Todo este proceso se debe a través de SSL, de lo contrario, un atacante podría oler la URL y restablecer la contraseña antes de que el usuario lo haga.
Algunos otros consejos:
autenticación de 2 factores a través de SMS! Si conoce al cliente y su número de teléfono móvil, envíe un SMS a un código único para agregarlo al sitio web para validarlo.
Haz unos pocos pasos del procedimiento. Por ejemplo, algo como esto:
www.yourdomain.com/lostpassword?param_1=x;param_2=y
Una y única captura está en el punto 3). Los valores de X e Y deben ser aleatorios, impredecibles y estar conectados a esta cuenta en particular. Deben ser también de un solo uso y deben quedar obsoletos después de un corto período de tiempo (¿24 horas?). Almacene ambos valores en una tabla dedicada con las columnas correspondientes:
| some_id | user_id | X | Y | expire_time
Si un usuario intenta usar la verificación de enlace adecuada si no se cumple el tiempo de caducidad y, de no ser así, permítale cambiar la contraseña.
Lea otras preguntas en las etiquetas web-application password-management appsec