Implementar la mejor práctica de recuperación de contraseñas

Quiero implementar la recuperación de contraseña en mi aplicación web.

Me gustaría evitar el uso de preguntas secretas.

Podría enviar la contraseña por correo electrónico, pero creo que sería arriesgado.

Tal vez podría generar una nueva contraseña temporal aleatoria y enviarla por correo electrónico, pero creo que es tan arriesgado como el anterior.

¿Puedo enviar una URL por correo electrónico, por ejemplo, http://example.com/token=xxxx, donde xxxx es un token aleatorio asociado con el usuario? Entonces, cuando el usuario navega hacia esa url, puede restablecer la contraseña.

En primer lugar, no almacene una copia de texto sin formato de la contraseña del usuario, o incluso una versión encriptada. Solo desea mantener una copia hash de la contraseña del usuario.

En cuanto a las soluciones de recuperación, encuentro que el enlace de recuperación para cambiar la contraseña del usuario es la mejor solución en mi experiencia. Probablemente sea un poco más conveniente para el usuario, aunque en gran medida es lo mismo desde el punto de vista de la seguridad que el envío de una nueva contraseña aleatoria que se cambiará después del siguiente inicio de sesión. Aún así, recomendaría que la url de recuperación caduque después de un período de tiempo razonablemente corto, y que solo se pueda usar una sola vez.

Cuando estaba en la Fuerza Aérea, la regla de seguridad que teníamos era: Al configurar o restablecer las contraseñas, no envíe el ID de usuario y la contraseña en el mismo correo electrónico. De esta forma, si alguien intercepta correos electrónicos buscando las contraseñas, debe interceptar AMBOS correos electrónicos y poder conectarlos para violar la seguridad.

He visto muchos sitios que usan “ir a esta URL para restablecer su contraseña”. Tal vez me esté perdiendo algo, no pretendo ser un experto en seguridad, pero no veo cómo eso es más seguro que simplemente inventar una nueva contraseña temporal y enviarla. Si un hacker intercepta el correo electrónico, ¿por qué no puede ir a ese enlace y ver la nueva contraseña tan bien como el usuario legítimo podría? Me parece una molestia extra para el usuario sin ganancia de seguridad.

Por cierto, felicidades por NO usar preguntas de seguridad. La lógica de este dispositivo se me escapa. Desde los albores de la seguridad informática, le hemos estado diciendo a las personas: “NO DEBE crear una contraseña que sea información sobre usted mismo que un hacker podría descubrir o adivinar, como el nombre de su escuela secundaria o su color favorito. para buscar el nombre de su escuela secundaria, o incluso si no lo conocen o no saben nada de usted, si todavía vive cerca de donde fue a la escuela, puede obtenerlo probando las escuelas locales hasta que lleguen a ella. una pequeña cantidad de posibles colores favoritos para que un hacker pueda adivinar eso. Etc. En cambio, una contraseña debe ser una combinación sin sentido de letras, dígitos y signos de puntuación “. Pero ahora también les decimos: “¡Pero si te resulta difícil recordar esa combinación sin sentido de letras, dígitos y signos de puntuación, no hay problema! Toma alguna información sobre ti que puedas recordar fácilmente, como el nombre de tu escuela secundaria , o su color favorito, y puede usarlo como la respuesta a una ‘pregunta de seguridad’, es decir, como una contraseña alternativa.

De hecho, las preguntas de seguridad lo hacen aún más fácil para el pirata informático que si simplemente eligiera una contraseña incorrecta para comenzar. Al menos, si acaba de utilizar una parte de la información personal para su contraseña, un hacker no necesariamente sabrá qué parte de la información personal que utilizó. ¿Usaste el nombre de tu perro? ¿Tu fecha de nacimiento? ¿Tu sabor de helado favorito? Tendría que probarlos a todos. Pero con preguntas de seguridad, le decimos al pirata informático exactamente qué parte de la información personal usó como contraseña.

En lugar de utilizar preguntas de seguridad, ¿por qué no solo decimos: “En caso de que olvide su contraseña, aparece en la parte inferior de la pantalla. Si está tratando de hackearla en la cuenta de otra persona, está absolutamente prohibido desplazando hacia abajo.” Sería solo un poco menos seguro.

Para que no se pregunte, cuando los sitios me preguntan por la ciudad donde nací o el fabricante de mi primer auto, no le doy una respuesta real a la pregunta. Doy una contraseña sin sentido.

Es difícil decir lo que debe hacer, ya que casi cualquier solución a este problema debilitará la seguridad. A menos que tal vez desee investigar el envío de un SMS, verificación de callback, generadores de contraseñas de un solo uso u otros esquemas similares que lleven la recuperación de contraseñas a un medio diferente.

Sin embargo, lo que no debes hacer :

  • Envía la contraseña, porque después de todo, como ya se ha mencionado, no la tienes.

  • Genere una nueva contraseña temporal: no solo es tan inseguro como enviar la contraseña, sino que también genera la posibilidad de un ataque de denegación de servicio. Puedo ir al sitio, pretender ser tú, solicitar una nueva contraseña y luego (si no has revisado tu correo electrónico) no puedes iniciar sesión, no sé por qué y tengo que solicitar una nueva contraseña. .

El token es probablemente el camino a seguir. Recibirlo notifica una solicitud de contraseña olvidada, pero no realiza ninguna acción a menos que confirme. También lo convertirías en un token de un solo uso con un tiempo de caducidad relativamente corto para limitar el riesgo.

Por supuesto, mucho depende de la aplicación. Obviamente, proteger la información financiera y otra información confidencial es más importante que evitar que su cuenta sea pirateada en mytwitteringfacetube.com, porque aunque es inconveniente, si alguien quiere robar la identidad de alguien en un sitio de red social, puede abrir su propia cuenta y hacerse pasar por robado. información de todos modos.

Obviamente, no puede enviar la contraseña original por correo electrónico, porque no la está almacenando (¿verdad?). Enviar una contraseña temporal (que debe modificarse, ya que solo funciona para un inicio de sesión único) y un enlace para restablecer la contraseña son equivalentes desde un punto de vista de seguridad.

No entiendo la actitud hacia el método de la pregunta secreta. No es que voy a hacer mi contraseña “BlueHouse” y luego hago mi pregunta de seguridad “¿Cuáles son tus dos cosas favoritas?” y la respuesta “Azul y casas”. La pregunta de seguridad no es la clave mágica para obtener la contraseña real. Por lo general, es una forma de obtener una nueva contraseña enviada a la dirección de correo electrónico registrada. No sé de qué otra manera lo hacen, pero parece que hacen una de dos cosas.

1) El usuario hace clic en el botón “Olvidé mi contraseña” y la nueva contraseña se envía al usuario.

2) El usuario hace clic en el botón “Olvidé mi contraseña” y luego tiene que responder una pregunta de seguridad antes de recibir la nueva contraseña por correo electrónico a la dirección registrada.

Me parece que la opción número 2 es más segura.

¿Por qué enviar un token es más seguro que enviar la contraseña? Si una cuenta de correo electrónico ha sido pirateada, ha sido pirateada. No importa si hay un enlace para restablecer la contraseña, un token o una nueva contraseña. No olvides que la mayoría de los sitios no dicen “La nueva contraseña ha sido enviada a la siguiente dirección de correo electrónico para que la piratees”. Un hacker debería adivinar la dirección de correo electrónico que debe ser pirateada.

Estoy de acuerdo con Andy. ¿Las preguntas de seguridad normalmente no son independientes de la contraseña? (el mío lo es) Lo que significa que tienen una pregunta y una respuesta, y que no están relacionadas con la contraseña. Parece que esto se usa para evitar solicitudes espurias de restablecimiento de contraseña y realmente tiene un uso.

Imagínese: alguien podría ir a la utilidad de “olvido de contraseña” de un sitio e ingresar un trillón de direcciones de correo electrónico, o simplemente una persona a la que quiera molestar. Si la contraseña se restablece en ese punto, las personas que pertenecen a esas direcciones de correo electrónico tendrían que notar en su correo electrónico el restablecimiento de la contraseña e iniciar sesión en el sitio con la contraseña de reinicio la próxima vez que ingresen allí. Con la pregunta de seguridad, esto no es tan fácil de hacer para alguien.

Veo que Amazon envía un enlace al correo electrónico dado. También requieren que ingrese un captcha para evitar ataques de DOS. Como se trata de un enlace, supongo que eso significa que no restablecieron la contraseña de inmediato y se restablecería una vez que el usuario haya hecho clic en el enlace. Con el escenario anterior, el usuario simplemente vería el correo electrónico y notaría que “no, yo no hice eso” y se ocupará de su negocio sin tener que cambiar su contraseña innecesariamente. Una pregunta de seguridad podría haber evitado que el bash al principio y el usuario legítimo obtuvieran el correo electrónico en primer lugar.

Aquí hay un documento técnico: http://appsecnotes.blogspot.com/2010/09/latest-forgot-password-best-practices.html

En realidad, este recomienda preguntas secretas como parte principal del proceso de autenticación. Y enviar un código de autenticación por correo electrónico y solicitarlo es solo una capa adicional que opcionalmente puede incluir.

Realmente se reduce a cuánta seguridad quieres tener. Uno de los extremos es un proceso de restablecimiento de contraseña que implica contactar y certificar que usted es quien dice ser, por ejemplo, a través de una identificación, porque su buzón podría verse comprometido también. En realidad, como las personas tienden a usar la misma contraseña en todas partes, es muy probable que así sea. En el otro extremo está el enfoque estándar que implica simplemente enviar un correo electrónico con una nueva contraseña aleatoria.

Las preguntas y respuestas “secretas” son solo otra forma de nombre de usuario y contraseñas con el defecto fatal de que generalmente son increíblemente fáciles de adivinar, tan buenas que no desea usarlas.

A su punto sobre el token, no creo que haga una gran diferencia en la seguridad general. Ya sea que envíe un token que le permita a un usuario cambiar la contraseña o si envía una contraseña aleatoria de inmediato, eso no cambiará mucho.

Solo asegúrese de que el token solo se pueda utilizar una vez y preferiblemente solo en un lapso de tiempo limitado, por ejemplo, + 24 horas después de solicitarlo.

Y, como se señaló en las respuestas anteriores, NUNCA VAYA a almacenar contraseñas simples. Hash ellos. Preferiblemente agregue sal .

Así es como lo resolví:

retrieve_expiration campos retrieve_token y retrieve_expiration a mi tabla de ‘usuarios’.

El usuario solicita un restablecimiento de contraseña al proporcionar su correo electrónico y completar el captcha. Se genera un valor hash aleatorio para su campo retrieve_token , es decir, md5($user_id.time()) , mientras que md5($user_id.time()) se establecerá en una fecha y hora que expira en los próximos 45 minutos. El correo electrónico se envía al usuario con un enlace:

https://example.com/reset-password?retrieve_token=912ec803b2ce49e4a541068d495ab570

SSL debe ser obligatorio cuando se requiere autenticación. También puede agregar una tabla para registrar las solicitudes de reinicio que almacena el correo electrónico y la dirección IP. Ayuda a rastrear posibles ataques brutales y puede bloquear la IP del atacante si es necesario.

Podría implementar una pregunta de seguridad para solicitar el restablecimiento de contraseña, pero creo que el captcha sería suficiente para disuadir a cualquiera de repetir la solicitud varias veces.

@Arrendajo. El motivo por el que accedes a una URL para restablecer tu contraseña en lugar de solo enviarle a alguien una nueva contraseña temporal es más que solo seguridad. Sin algo así como una URL con un token, una persona podría restablecer la contraseña de otra persona. No hay necesidad de obtener acceso al correo electrónico. Si alguien tiene un hueso para elegir con alguien, podría seguir iniciando un nuevo restablecimiento de contraseña. Entonces el objective pobre tiene que iniciar sesión y cambiar la contraseña una y otra vez.

Al enviar un token, la contraseña del usuario no cambia hasta que inicie sesión con ella y la confirme. El correo no deseado de los correos electrónicos de reinicio se puede ignorar. Los tokens son igual de fáciles (si no más fáciles) de generar como una nueva contraseña usando un GUID, en realidad no es una molestia adicional para el desarrollador.

Además, dado que el GUID es único (una contraseña generada podría no serlo), un token puede vincularse a un nombre de usuario. Si el nombre de usuario incorrecto se proporciona en la URL, el token se puede cancelar (es decir, cuando una persona diferente lo inicia y alguien lo intercepta … suponiendo que el nombre de usuario no sea el mismo que el del correo electrónico).

@Arrendajo. El uso adecuado de las preguntas de seguridad es iniciar un correo electrónico de restablecimiento de contraseña, no para restablecer realmente la contraseña. Sin un mecanismo como una pregunta de seguridad, uno podría iniciar un restablecimiento de contraseña. A pesar de que parece ser legítimo, el envío de un correo electrónico de reinicio podría enviarse a un correo electrónico que podría no pertenecer al propietario original. Esto no es raro Por ejemplo, cuando los empleados abandonan una empresa, a menudo esos correos se envían a otro empleado. Una pregunta de seguridad, agrega un bajo nivel de obstrucción a ese escenario. También reduce los problemas en los que una persona continúa iniciando un restablecimiento de contraseña en la cuenta incorrecta, lo que hace que algunos usuarios pobres reciban correo basura involuntariamente. Las preguntas de seguridad en realidad no están pensadas para ser verdaderamente seguras, solo están destinadas a reducir escenarios como esos. Cualquiera que use una pregunta de seguridad para restablecer realmente la contraseña lo está haciendo mal.

En cuanto a la pregunta / respuesta de seguridad. Como usuario de sitios web, personalmente no los utilizo (ingreso basura en ellos). Pero ciertamente no son inútiles o sin sentido como algunos dicen aquí.

Considere esta situación: un usuario de su sitio ha abandonado su escritorio para ir a almorzar y no ha bloqueado su estación de trabajo. Un usuario nefasto ahora puede visitar la página para recuperar / restablecer la contraseña e ingresar el nombre de usuario del usuario. El sistema enviará por correo electrónico la contraseña recuperada / restablecida sin solicitar la respuesta de seguridad.

Aquí hay un ejemplo de cómo alguien lo hizo con Node.js, básicamente genera un token aleatorio, un tiempo de caducidad, envía el enlace con el token adjunto, tiene una ruta reset/:token que asegura que un usuario existe con ese token (que es tampoco caducado) y, de ser así, redirija a una página de restablecimiento de contraseña.

http://sahatyalkabov.com/how-to-implement-password-reset-in-nodejs/