Implementar las mejores prácticas de recuperación de contraseñas

Cuando estaba en la Fuerza Aérea la regla de seguridad que teníamos era: Al establecer o restablecer contraseñas, no envíe el id de usuario y la contraseña en el mismo correo electrónico. De esa manera, si alguien está interceptando correos electrónicos buscando contraseñas, tiene que interceptar con éxito AMBOS correos electrónicos y poder conectarlos para violar la seguridad.

He visto un montón de sitios que utilizan el "ir a esta URL para restablecer su contraseña". Tal vez me estoy perdiendo algo I no pretendo ser un experto en seguridad but pero no vea cómo eso es más seguro que simplemente inventar una contraseña nueva y 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, así como el usuario legítimo podría? Me parece una molestia adicional para el usuario sin ganancia de seguridad.

Por cierto, felicitaciones por NO usar preguntas de seguridad. La lógica de este dispositivo se me escapa. Desde los albores de la seguridad informática hemos estado diciendo a la gente, " NO hagas una contraseña que sea información sobre ti que un hacker podría descubrir o adivinar, como el nombre de tu escuela secundaria o tu color favorito. Un hacker podría ser capaz de buscar el nombre de tu escuela secundaria, o incluso si no te conocen o saben nada sobre ti, si aún vives cerca de donde fuiste a la escuela, podrían obtenerlo probando escuelas locales hasta que lo golpeen. Hay un pequeño número de posibles colores favoritos por lo que un hacker podría adivinar eso. Sucesivamente. En su lugar, una contraseña debe ser un combinación de letras, dígitos y puntuación."Pero ahora también les decimos," Pero! Si tiene dificultades para recordar esa combinación sin sentido de letras, dígitos y puntuación, ¡no hay problema! Tome alguna información sobre usted que pueda recordar fácilmente, como el nombre de su escuela secundaria o su color favorito, y puede usarla como 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 hacker que si usted acaba de elegir una mala contraseña para empezar. Al menos si solo usaras una información personal para tu contraseña, un hacker no sabría necesariamente qué información personal usaste. ¿Usaste el nombre de tu perro? ¿Tu fecha de nacimiento? Su sabor favorito de helado? Tendría que probarlas todas. Pero con preguntas de seguridad, le decimos al hacker exactamente qué pieza de información personal que utilizó como contraseña!

En lugar de usar preguntas de seguridad, ¿por qué no solo decimos: "En caso de que olvide su contraseña, se muestra en la parte inferior de la pantalla. Si está tratando de hackear la cuenta de otra persona, está absolutamente prohibido desplazarse hacia abajo."Sería un poco menos seguro.

Para que no te preguntes, cuando los sitios me preguntan por la ciudad donde nací o el fabricante de mi primer automóvil, no doy una respuesta real a la pregunta. Le 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 desee investigar el envío de un SMS, la verificación de devolución de llamada, los generadores de contraseñas de una sola vez u otros esquemas que lleven la recuperación de contraseñas a un medio diferente.

Sin embargo, lo que usted no debe hacer :

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

• Generar un nuevo contraseña temporal: esto no solo es tan inseguro como enviar la contraseña, sino que también conduce a la posibilidad de un ataque de denegación de servicio. Puedo ir al sitio, fingir ser tú, solicitar una nueva contraseña y luego (si no has revisado tu correo electrónico) no puedes iniciar sesión, no sabes por qué y tienes 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 lo confirme. También que sea un token de una sola vez 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 hackeada mytwitteringfacetube.com, porque si bien es inconveniente, si alguien quiere robar la identidad de alguien en una red social, puede abrir su propia cuenta y enmascararse con información robada de todos modos.

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

No entiendo la actitud hacia el método de la pregunta secreta. No es que vaya a hacer mi contraseña "BlueHouse "y luego hacer mi pregunta de seguridad" ¿Cuáles son sus 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 se de que otra manera lo hacen, pero suena como que hacen una de dos cosas.

1) El usuario hace clic un "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 hackeada, ha sido hackeada. No importa si hay un enlace para restablecer la contraseña, un token, o una nueva contraseña. No se olvide, 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 usted piratee". Un hacker tendría que adivinar la dirección de correo electrónico que necesita ser hackeado.

Estoy de acuerdo con Andy. ¿Las preguntas de seguridad no son normalmente independientes de la contraseña? (los míos son) Lo que significa que tienen una pregunta y una respuesta y no están relacionados con la contraseña. Parece que esto se usa para evitar solicitudes falsas de restablecimiento de contraseñas y en realidad tiene un uso.

Imagine que alguien podría ir a la utilidad "olvidé mi contraseña" de un sitio e ingresar un millón de direcciones de correo electrónico, o solo 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ía que darse cuenta en su correo electrónico el restablecimiento de la contraseña e iniciar sesión en el sitio con la contraseña de restablecimiento la próxima vez que fueron 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 DOS. Debido a que es un enlace, imagino que eso significa que no restablecieron la contraseña inmediatamente y que se restablecería una vez que el usuario haga clic en el enlace. Con el el escenario anterior, el usuario solo vería el correo electrónico y notaría que "no, no hice eso" y se dedicaría a su negocio sin tener que cambiar su contraseña innecesariamente. Una pregunta de seguridad podría haber evitado el intento al principio y que el usuario legítimo recibiera el correo electrónico en primer lugar.

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

Este en realidad recomienda preguntas secretas como una parte importante 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 puede incluir opcionalmente.

Todo se reduce a cuánta seguridad quieres tener. Uno de los extremos es un proceso de restablecimiento de contraseña que implica ponerse en contacto y certificar que usted es quien dice ser, por ejemplo, a través de id, porque su buzón también podría verse comprometido. En realidad, como la gente tiende a usar la misma contraseña en todas partes, esto es muy probable. En el otro extremo está el enfoque estándar que implica simplemente enviar un correo electrónico con una nueva contraseña al azar.

Preguntas "secretas" y las respuestas son solo otra forma de nombre de usuario y contraseñas con el defecto fatal que generalmente son increíblemente fáciles de adivinar, tan buenas que no quieres usarlas.

A su punto sobre el token, no creo que haga una gran diferencia en la seguridad general. Si envía un token que permite a un usuario cambiar la contraseña o si envía una contraseña aleatoria de inmediato, no hace una gran diferencia.

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

Y, como se señaló en las respuestas anteriores, NUNCA almacene contraseñas simples. Hash de ellos. Preferiblemente añadir sal.

Así es como lo resolví:

Agregué retrieve_token y retrieve_expiration campos a mi tabla 'users'.

El usuario solicita un restablecimiento de contraseña proporcionando su correo electrónico y rellenando captcha. Se genera un valor hash aleatorio para su campo retrieve_token, es decir, md5($user_id.time()), mientras que retrieve_expiration se establecerá en una fecha y hora que caduca 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 registro de solicitudes de restablecimiento que almacenan 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 la pregunta de seguridad para solicitar el restablecimiento de contraseña, pero creo que captcha sería suficiente para desalentar a cualquiera de repetir la solicitud varias veces.

@Jay. La razón por la que vas a una URL para restablecer tu contraseña en lugar de simplemente enviar a alguien una nueva contraseña temporal es más que solo seguridad. Sin algo 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 tuviera un problema con alguien, podría seguir iniciando un nuevo restablecimiento de contraseña. Entonces el objetivo pobre tiene que iniciar sesión y cambiar la contraseña una y otra vez.

Enviando un token, el la contraseña del usuario no cambia hasta que inicia sesión con ella y la confirma. El spam de los correos electrónicos de restablecimiento puede ser ignorado. Los tokens son tan fáciles (si no más fáciles) de generar como una nueva contraseña mediante el uso de un GUID, no es realmente una molestia adicional para el desarrollador.

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

@Jay. 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. Aunque aparentemente parezca mentira, el envío de un correo electrónico de restablecimiento podría enviarse a un correo electrónico que ya no pertenezca al propietario original. Esto no es raro. Por ejemplo, cuando los empleados dejan una empresa, a menudo esos correos se reenvían a otro empleado. Una pregunta de seguridad, añade un bajo nivel de obfucation a ese escenario. También reduce los problemas en los que una persona sigue iniciando un restablecimiento de contraseña en la cuenta incorrecta, lo que hace que un pobre césped reciba spam involuntariamente. La pregunta de seguridad realmente no está destinada a ser verdaderamente segura, solo están destinadas a reducir escenarios como esos. Cualquiera que use una pregunta de seguridad para restablecer la contraseña lo está haciendo mal.

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

Considere esta situación: Un usuario de tu sitio ha dejado 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 el 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 tampoco está caducado) y, si es así, redirige a una página de restablecimiento de contraseña.

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