passwords - resguardo - Implementar la mejor práctica de recuperación de contraseña
recuperar password (12)
@Arrendajo. El uso correcto 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 parezca que está listo, 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 abandonan una empresa, a menudo esos correos se reenvían a otro empleado. Una pregunta de seguridad, agrega un bajo nivel de obfucació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 provoca que algunos tíos pobres reciban spam no intencionalmente. Las preguntas de seguridad realmente no tienen la intención de ser verdaderamente seguras, solo están destinadas a reducir escenarios como esos. Cualquier persona que use una pregunta de seguridad para restablecer la contraseña, lo está haciendo mal.
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 aleatoria temporal y enviarla por correo electrónico, pero creo que es tan arriesgado como el punto anterior.
¿Puedo enviar un 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 a esa url, él / ella puede restablecer la contraseña.
@Arrendajo. La razón por la que va a una URL para restablecer su contraseña en lugar de simplemente enviarle 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 acceder al correo electrónico. Si alguien tuviera un hueso para elegir 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.
Al enviar un token, la contraseña del usuario no cambia hasta que inicie sesión con él y lo confirme. El spam de los correos de reinicio puede ser ignorado. Los tokens son tan fáciles (si no más fáciles) de generar como una nueva contraseña usando 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 se proporciona el nombre de usuario incorrecto en la URL, entonces el token se puede cancelar (es decir, cuando una persona diferente lo inicia y alguien lo intercepta ... asumiendo que el nombre de usuario no es el mismo que el correo electrónico).
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 garantiza que un usuario existe con ese token (que es tampoco caducado) y, si es así, redirigir a una página de restablecimiento de contraseña.
http://sahatyalkabov.com/how-to-implement-password-reset-in-nodejs/
Así es como lo resolví:
retrieve_expiration campos retrieve_token y retrieve_expiration a mi tabla de ''usuarios''.
El usuario solicita un restablecimiento de la contraseña proporcionando su correo electrónico y completando captcha. Se genera un valor aleatorio aleatorio para su campo retrieve_token , es decir, md5($user_id.time()) , mientras que retrieve_expiration 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 restablecimiento que almacenan el correo electrónico y la dirección IP. Ayuda a rastrear posibles ataques brutos y puede bloquear la IP del atacante si es necesario.
Podría implementar una pregunta de seguridad para solicitar el restablecimiento de la contraseña, pero creo que captcha sería suficiente para disuadir a cualquiera de repetir la solicitud varias veces.
Cuando estuve 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 ni 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 AMBOS correos electrónicos y poder conectarlos para violar la seguridad.
He visto muchos sitios que utilizan el "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 que eso sea más seguro que solo inventar una contraseña nueva y temporal y enviarla. Si un pirata informático intercepta el correo electrónico, ¿por qué no puede ir a ese enlace y ver la nueva contraseña como lo podría hacer el usuario legítimo? Me parece una molestia adicional para el usuario sin ningún beneficio de seguridad.
Por cierto, felicitaciones por NO usar preguntas de seguridad. La lógica de este dispositivo se me escapa. Desde el comienzo de la seguridad informática, le hemos dicho a la gente: "NO haga una contraseña que sea información sobre usted que un pirata informático pueda descubrir o adivinar, como el nombre de su escuela secundaria o su color favorito. Un pirata informático podría ser capaz de para buscar el nombre de su escuela secundaria, o incluso si no lo conocen o no saben nada sobre usted, si aún vive cerca de donde asistió a la escuela, pueden obtenerlo al probar escuelas locales hasta que lleguen a ese punto. un pequeño número de colores favoritos para que un pirata informático pueda adivinar eso. Etc. En cambio, una contraseña debe ser una combinación sin sentido de letras, dígitos y puntuación ". Pero ahora también les decimos: "¡Pero! Si tienes dificultades para recordar esa combinación sin sentido de letras, dígitos y puntuación, ¡no hay problema! Toma información sobre ti que puedas recordar fácilmente, como el nombre de tu escuela secundaria , o su color favorito, y puede usarlo 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 el pirata informático que si, para empezar, eligiera una contraseña incorrecta. Al menos, si solo usó un elemento de información personal para su contraseña, un pirata informático no necesariamente sabría qué tipo de información personal utilizó. ¿Usaste el nombre de tu perro? ¿Tu fecha de nacimiento? ¿Tu sabor favorito de helado? Tendría que probar todos ellos. Pero con las preguntas de seguridad, ¡le informamos al hacker exactamente qué información personal usó como contraseña!
En lugar de utilizar preguntas de seguridad, ¿por qué no simplemente decimos: "En caso de que olvide su contraseña, se muestre en la parte inferior de la pantalla. Si está intentando piratear la cuenta de otra persona, está absolutamente prohibido desplazando hacia abajo." Sería solo un poco menos seguro.
Para que no se pregunten, cuando los sitios me preguntan por la ciudad donde nací o el fabricante de mi primer automóvil, no le doy una respuesta real a esta pregunta. Le doy una contraseña sin sentido.
</rant>
En primer lugar, no almacene una copia de texto sin formato de la contraseña del usuario, ni siquiera una versión encriptada. Solo desea mantener una copia de 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 será un poco más conveniente para el usuario, mientras que en gran medida es el mismo desde el punto de vista de seguridad que el envío de una nueva contraseña aleatoria que se cambiará después del próximo inicio de sesión. Seguiría recomendando que la url de recuperación caduque después de un breve período de tiempo razonable, y que solo sea utilizable una sola vez.
Es difícil decir lo que debe hacer, ya que prácticamente cualquier solución a este problema debilitará la seguridad. A menos que desee investigar el envío de un SMS, una verificación de devolución de llamada, generadores de contraseña únicos u otros esquemas similares que lleven la recuperación de la contraseña a un medio diferente.
Sin embargo, lo que no debes hacer :
Envíe la contraseña, porque después de todo, como ya se ha mencionado, no la tiene.
Genere una nueva contraseña temporal: no solo es tan inseguro como enviar la contraseña, sino que también conlleva la posibilidad de un ataque de denegación de servicio. Puedo ir al sitio, pretender ser usted, solicitar una nueva contraseña y luego (si no ha revisado su correo electrónico) no puede iniciar sesión, no sé por qué y debo solicitar una nueva contraseña nueva. .
El token es probablemente el camino a seguir. Al recibirla, se notifica una solicitud de contraseña olvidada, pero no realiza ninguna acción a menos que lo confirme. También lo convertiría en 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 información financiera y de otro tipo es más importante que evitar que su cuenta sea hackeada en mytwitteringfacetube.com, ya que si bien es inconveniente, si alguien quiere robar la identidad de alguien en un sitio de una red social, puede abrir su propia cuenta y disfrazarse con objetos robados. información de todos modos.
Estoy de acuerdo con Andy. ¿No son las preguntas de seguridad 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 de restablecimiento de contraseña falsas y realmente tiene un uso.
Imagínese: alguien podría ir a la utilidad de "contraseña olvidada" de un sitio e ingresar un millón de direcciones de correo electrónico, o solo una persona que quiera molestar. Si la contraseña se restablece en ese momento, las personas que pertenecen a esas direcciones de correo electrónico deberán notificar 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 vayan 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 es un enlace, me imagino que eso significa que no restablecieron la contraseña inmediatamente y que se restablecerá una vez que el usuario haga clic en el enlace. Con el escenario anterior, el usuario solo vería el correo electrónico y notaría que "no, yo no hice eso" y seguiría con su negocio sin tener que cambiar su contraseña innecesariamente. Una pregunta de seguridad podría haber evitado el intento al principio y el usuario legítimo de recibir el correo electrónico en primer lugar.
Aquí hay un documento técnico en él: http://appsecnotes.blogspot.com/2010/09/latest-forgot-password-best-practices.html
Este realmente 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.
No entiendo la actitud hacia el método de la pregunta secreta. No es como que voy a hacer mi contraseña "BlueHouse" y luego hacer mi pregunta de seguridad "¿Cuáles son tus dos cosas favoritas?" y la respuesta "azul y casas". La pregunta de seguridad no es la llave 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 archivada. No sé de qué otra manera lo hacen, pero parece que ustedes 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 en el archivo.
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 lo olvide, la mayoría de los sitios no dicen "La nueva contraseña se ha enviado a la siguiente dirección de correo electrónico para que la pueda piratear". Un hacker tendría que adivinar la dirección de correo electrónico que necesita ser hackeada.
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 cambiarse, porque solo funciona para un inicio de sesión), y un enlace para restablecer la contraseña son equivalentes desde un punto de vista de seguridad.
Realmente se reduce a cuánta seguridad desea tener. Uno de los extremos del proceso es el proceso de restablecimiento de la contraseña que implica ponerse en contacto y certificar que usted es quien dice ser, por ejemplo, a través de una identificación, ya que su buzón también podría verse comprometido. En realidad, como las personas tienden a usar la misma contraseña en todas partes, esto es muy probable. En el otro extremo, existe 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 error fatal que generalmente son increíblemente fáciles de adivinar, tan bueno que no quiere usarlas.
Para su punto sobre el token, no creo que haya una gran diferencia en la seguridad general. Si envía un token que le permite a un usuario cambiar la contraseña o si envía una contraseña aleatoria de inmediato, no hay una gran diferencia.
Solo asegúrese de que el token solo se pueda usar una vez y, de preferencia, solo en un período de tiempo limitado, por ejemplo, +24 h después de solicitarlo.
Y, como se señaló en las respuestas anteriores, NUNCA NUNCA almacene contraseñas simples. Hash ellos Preferiblemente añadir la salt .
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 su sitio dejó su escritorio para ir a almorzar y no cerró 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.