¿Cuál es el mejor método" olvidé mi contraseña"? [duplicar]


Posible Duplicado:
Contraseña olvidada: ¿cuál es el mejor método para implementar una función de contraseña olvidada?

Estoy programando un sitio web comunitario.

Quiero crear una función "olvidé mi contraseña".

Mirando alrededor en diferentes sitios, he encontrado que emplean una de tres opciones :

  1. Enviar al usuario un correo electrónico con un enlace a una URL única y oculta que le permita cambiar su contraseña (Gmail y Amazon)

  2. Enviar al usuario un correo electrónico con una nueva contraseña generada aleatoriamente (Wordpress)

  3. Enviar al usuario su contraseña actual (www.teach12.com)

La opción # 3 parece la más conveniente para el usuario, pero como guardo las contraseñas como un hash MD5, no veo cómo estaría disponible la opción #3 ya que MD5 es irreversible . Esto también parece ser inseguro opción ya que significa que el el sitio web debe guardar la contraseña en texto claro en algún lugar, y al menos la contraseña de texto claro se envía por correo electrónico inseguro al usuario. O me estoy perdiendo algo aquí?

Así que si no puedo hacer la opción #1, opción #2 parece ser la más sencillo programa ya que sólo tengo que cambiar la contraseña del usuario y enviarla a él. Aunque esto es algo inseguro ya que debe tener una contraseña activa que se comunica a través de un correo electrónico inseguro. Sin embargo, esto podría también ser mal utilizado por los creadores de problemas para molestar a los usuarios escribiendo correos electrónicos aleatorios y cambiando constantemente las contraseñas de varios usuarios.

La opción #1 parece ser la más segura pero requiere un poco de programación adicional para lidiar con una URL oculta que caduca, etc., pero parece ser lo que usan los grandes sitios.

¿Qué experiencia has tenido usando / programando estas diversas opciones? ¿Hay alguna opción que me haya perdido?

Author: Community, 2009-05-23

17 answers

4) Acreditar su cuenta bancaria con dos cantidades aleatorias y pedirles que las ingresen.
5) Snail envíeles una nueva contraseña y pídales que la ingresen.
6) Pídales que envíen mensajes de texto o llamen a algún número e ingresen algún valor a un número de teléfono con el teléfono móvil que registraron en el archivo.
7) Sal del problema de gestión de contraseñas por completo externalizándolo a proveedores de OpenID como Stack Overflow, Facebook, motores de blogs y otros que están empezando a hacerlo.

Fuera de ésos, utilice la opción #1 o #2 con la característica añadida que ambos expiran en una hora.

 34
Author: Jeff Moser,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2009-05-23 23:36:12

Estoy sorprendido por los votos positivos en las respuestas que describen #1 y #2 como equivalentes. No lo son en absoluto. Enviar al usuario un enlace a corto plazo para cambiar su contraseña es el enfoque más conveniente, más utilizado y más seguro que no implica una interacción fuera de banda (correo, mensaje de texto, etc.).). Algunas razones:

  1. Establecer una contraseña temporal a través de un enlace de contraseña olvidada permite a los usuarios cambiar efectivamente la contraseña de un usuario y bloquear a un usuario de su cuenta si conocen la inicio de sesión del usuario. Con un enlace, el usuario simplemente sabe que alguien está jugando y su acceso no se ve afectado.
  2. El enlace de restablecimiento de contraseña solo es válido por un período corto, por lo que hay una ventana muy pequeña para que un atacante ataque. E incluso si lo hicieran, el usuario lo sabría porque el enlace de restablecimiento ya no funcionaría si el atacante interceptaba el enlace y lo usaba para cambiar la contraseña. Si la nueva contraseña asignada no es cambiada por el usuario inmediatamente, el atacante que interceptó la password puede suplantar silenciosamente al usuario indefinidamente. Así que la gran diferencia es que, mientras que un hacker puede interceptar el correo electrónico del enlace de restablecimiento de contraseña, si usa el enlace para cambiar la contraseña del usuario, el usuario sabrá que algo está mal porque el enlace no funcionará y generará otra solicitud de restablecimiento de contraseña.
  3. Más fácil de usar: el usuario simplemente hace clic en un enlace en su correo electrónico en lugar de escribir una nueva contraseña aleatoria que ha generado.

Y preguntas de seguridad a menudo hacen que un sitio sea menos seguro, no más: son otro vector de ataque y, a menudo, el eslabón más débil. Recomiendo encarecidamente leer El Manual de Hackers de Aplicaciones Web para una excelente discusión sobre este tema.

 9
Author: Cory House,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2010-08-04 17:00:50

Tenga en cuenta que la opción #2 también requiere que mantenga un registro de la contraseña antigua y expire la nueva contraseña aleatoria si no se usa dentro de, digamos, 24 horas.

De lo contrario podría molestarte emitiéndote repetidamente una nueva contraseña aleatoria if si no estás cerca de tu correo electrónico es posible que no sepas por qué no puedes iniciar sesión con tu contraseña normal.

También, por favor evite requerir una "pregunta de identificación". Las respuestas a estas preguntas suelen ser mucho más fáciles de adivinar/buscar que contraseñas reales so para que todos puedan identificarse como yo. Vea la historia de Sarah Palin para un ejemplo reciente de lo inseguro que es esto.

 8
Author: Martin Geisler,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2009-05-23 14:54:47

Las opciones 1 y 2 son tan inseguras como las demás.

Ahí. Lo dije. Si la cuenta de correo electrónico del usuario ha sido violada, no hay una forma segura razonable de hacer las cosas a menos que recopile más datos privados como su dirección, el nombre de soltera de su madre, todo lo cual se puede adivinar.

La mejor versión (aunque la más molesta) que he visto es donde necesitas recordar una pregunta secreta y una respuesta secreta. Significa que el usuario tiene que recordar qué pregunta hizo, cuál, de por supuesto, siempre se puede olvidar también!

Si olvidan la pregunta y eres una empresa "real", siempre existe la opción de enviar al usuario un token a través del post, con instrucciones sobre cómo restablecer toda su seguridad... Es muy poco probable que un hacker tenga acceso a su correo de la vida real.

Un sesgo en eso sería recopilar un número de teléfono cuando el usuario creó la cuenta. Si eso existiera y no pudieran recordar ninguno de sus detalles, podría configurar algunos una especie de sistema de llamadas automatizadas que les decía cómo restablecer sus datos.

Y una cosa para mencionar sobre #2: No dejes que el proceso sobrescriba la contraseña de la cuenta actual. Si eso sucediera, cualquiera podría decir que olvidó la contraseña de cualquier cuenta, lo que desencadenaría muchos cambios de contraseña no deseados.

 6
Author: Oli,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2009-05-23 14:58:58

No hay ninguna diferencia real entre la seguridad de la opción 1 o 2. La opción 1 es efectivamente la misma que la precarga de la nueva contraseña en el formulario.

De hecho, con la prevalencia de los ataques de phishing, se podría argumentar que alentar el uso de la opción 1 con URL largas podría hacer que las personas estén menos alertas sobre hacer clic en URL largas y misteriosas.

 4
Author: Cade Roux,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2009-05-23 14:45:18

Lea el OWASP top ten para asegurarse de que su método es compatible.

Aquí está el enlace directo.

 4
Author: karim79,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2009-05-23 14:47:03

Solo una nota rápida sobre algo no específicamente en lo que respecta a su pregunta. Mencionaste que usaste MD5 para hash de contraseñas almacenadas. Independientemente de si elige usar las Opciones 1 o 2 (3 va a ser la menos segura ya que, por razones obvias), MD5 es un algoritmo de hash agrietado, y en realidad puede hacer que sea bastante fácil para los hackers obtener acceso a cuentas protegidas por el hash MD5.

Puede leer más sobre la vulnerabilidad en la siguiente URL: en.wikipedia.org/wiki/MD5

Una mejor solución de hash sería algo como SHA, que sigue siendo un algoritmo de hash estable y seguro. Combinado con la opción #1 o #2, debe tener un sistema razonablemente seguro para proteger las contraseñas de sus usuarios, excepto los hackers más decididos.

 4
Author: jrista,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2009-05-23 16:49:01

La opción #1 es probablemente la mejor. #3 es inseguro (y también sugiero usar algo más fuerte que MD5, como SHA1). La opción # 2 no es buena porque permite que cualquier persona al azar te bloquee de tu cuenta hasta que revises tu correo electrónico, a menos que uses una pregunta de seguridad. Y las preguntas de seguridad suelen ser más fáciles de descifrar que las contraseñas.

 2
Author: Zifre,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2009-05-23 14:54:07

La opción #1 tiene un par de ventajas importantes sobre la #2. Si un usuario al azar escribe mi dirección de correo electrónico en el cuadro "He olvidado mi contraseña", entonces mi contraseña no se restablecerá. Además, es un poco más seguro ya que no hay un registro permanente de la contraseña del sitio almacenada en su bandeja de entrada de gmail para siempre.

Una pieza crítica que falta aquí es que el enlace que proporcionas en #1 solo debería funcionar para un restablecimiento de contraseña y tener un límite de tiempo

Todas estas soluciones significan que está tratando su bandeja de entrada de correo electrónico como el "anillo único" que los gobierna a todos. La mayoría de los servicios en línea parecen estar haciendo esto hoy en día de todos modos.

Mi enfoque preferido es ir con openid cuando sea posible. La gestión de contraseñas es un infierno que nadie parece acertar. Es más fácil entregar este problema a alguien más.

 2
Author: Sam Saffron,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2009-05-23 20:30:42

Opción 4: Requiere que el usuario restablezca la contraseña ingresando su nombre de cuenta y dirección de correo electrónico. Mientras no esté revelando nombres reales o direcciones de correo electrónico en el sitio (¿POR qué lo haría en este día y edad?) este es un método razonablemente seguro y a prueba de manipulaciones. Envía un enlace a una página de restablecimiento, no a la contraseña en sí.

Opción 5: Use OpenID y pase la responsabilidad a un tercero para que se preocupe por ello.

Honestamente, esto es mucho más esfuerzo que la mayoría de los sitios requieren. Me GUSTA recibir contraseñas en texto plano por correo electrónico porque las almaceno en una carpeta de" registros " en mi bandeja de entrada. De esa manera puedo buscar contraseñas para sitios cuando los olvido (¡lo cual sucede mucho!). Si alguien está leyendo mi correo electrónico, tengo problemas más grandes de los que preocuparme que las personas que usan mi cuenta de Twitter (si tuviera una). Por supuesto, los bancos y las corporaciones tienen requisitos más fuertes, pero no especificó cuál es su sitio. Esa es la clave de la mejor respuesta.

 1
Author: SpliFF,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2009-05-23 16:03:12

Estoy de acuerdo con sus comentarios sobre la opción #3 como insegura.

En cuanto a la programación #1 o #2, la opción #2 es más fácil de programar, pero la #1 no es mucho más difícil y ambas probablemente sean tan seguras como las otras.

Cualquiera que sea la opción que elija, también puede considerar hacerla más segura incluyendo solicitudes de información personal (que obtiene durante el registro) como parte del proceso de contraseña olvidada.

He programado sistemas donde tienes un nombre de usuario y para obtener una nueva contraseña, debe ingresar su nombre de usuario y su dirección de correo electrónico. Puede recibir un recordatorio de su nombre de usuario, pero el punto principal es que probablemente alguien no será capaz de adivinar su nombre de usuario y su correo electrónico, pero si lo hace solo en el correo electrónico, hay menos seguro.

Las preguntas secretas son una aproximación a la parte de información personal. Personalmente creo que no ofrecen mucho valor, ya que la gente tiende a elegir preguntas que muchas personas conocerán la respuesta, podrán para adivinar o ser capaz de averiguarlo. Sin embargo, es mejor que nada, siempre y cuando lo use junto con un método ya relativamente seguro.

Obviamente, cuanto más de esto haces, más trabajo de programación es.

El método más simple es:

  1. Tenga un enlace "recuérdame mi nombre de usuario" (ingrese el correo electrónico). No le digas al usuario si se envió un correo electrónico o no porque las personas pueden usarlo para averiguar si una dirección de correo electrónico es de un miembro. Siempre dile al usuario que revise su bandeja de entrada para el correo electrónico de recordatorio, pero solo enviarlo si alguien es miembro; y
  2. Requiere tanto el nombre de usuario como el correo electrónico para recibir una nueva contraseña de un solo uso. Esa contraseña solo debería durar una hora más o menos. Cuando el usuario lo utiliza, debe ser obligado a cambiar su contraseña inmediatamente.
 1
Author: cletus,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2012-05-10 06:21:53

Cualquiera de las opciones 1 o 2 estaría bien. Como ha dicho, la opción 3 es insegura, ya que tendría que almacenar la contraseña de texto claro. Probablemente podría ponerse elegante y usar un algoritmo de cifrado reversible para almacenar/recuperar la contraseña, pero con mejores alternativas disponibles para usted no hay razón para ir por ese camino.

 0
Author: Justin Ethier,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2009-05-23 14:48:35

Hay una opción adicional que puede usar en combinación con cualquiera de las opciones que mencione:

Puede dejar que el usuario escriba un recordatorio de su contraseña, que le envía como primer paso cuando ha olvidado la contraseña. Si el recordatorio no ayuda al usuario, puede pasar a la siguiente opción.

Como el recordatorio no es la contraseña en sí, es seguro enviarlo por correo (o tal vez incluso mostrarlo directamente en la página).

 0
Author: Guffa,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2009-05-23 14:50:20

Si hash Opción 3 no está disponible y, si no los hash ellos, que vergüenza. :)

Prefiero la opción 1, enviar un enlace de restablecimiento de contraseña enviado a su correo electrónico que les permite (por un tiempo limitado) restablecer su contraseña. Requiere más trabajo, pero es fácil de usar y, en última instancia, tan seguro como su proceso de inicio de sesión por correo electrónico.

 0
Author: Anthony Potts,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2009-05-23 14:51:21

Usted podría hacer una mezcla entre #1 y #2, tomando ventajas de ambos:

Envíe al usuario un correo electrónico con un enlace a una URL única y oculta que le permita cambiar una nueva contraseña generada aleatoriamente.

Esa página podría ser SSL, y la contraseña podría caducar en 12-24 horas.

 0
Author: eKek0,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2009-05-23 15:01:42

He probado un par de métodos con los que realmente no he estado contento. Lo que he decidido para el próximo proyecto es:

  1. El usuario introduce el nombre de usuario y la dirección de correo electrónico
  2. Correo electrónico enviado con un enlace que contiene url y guid param que se ha almacenado en la base de datos con una caducidad de 48 horas
  3. El usuario confirma que la contraseña se restablecerá
  4. Se envía una nueva contraseña al usuario
  5. Iniciar sesión con una nueva contraseña muestra un mensaje o redirige a la página cambiar contraseña.
 0
Author: Duncan,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2010-07-01 21:21:52

Instruir al usuario que venga personalmente a sus oficinas y acredite su identidad con dni o pasaporte.

Esto, por supuesto, supone que tiene oficinas cerca de sus usuarios y que la cuenta es lo suficientemente valiosa como para justificar este procedimiento. Adecuado por ejemplo bancos.

 0
Author: Juha Syrjälä,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2010-08-19 08:49:09