¿Qué es más seguro? ¿Debo enviar un correo electrónico con una URL que expira a los usuarios para restablecer su contraseña o debo enviar por correo electrónico una contraseña recién generada?

8

Envíe un correo electrónico con un enlace que caduque dentro de un período de tiempo determinado en el que el usuario puede restablecer su contraseña.

Eso, definitivamente.

El correo electrónico siempre está limpio (es posible que la conexión de su sitio no sea así) y puede tocar más máquinas. Mantenga las contraseñas fuera del correo electrónico. El token de restablecimiento temporal también significa que si el buzón se piratea más adelante, el token ya no sirve.

Aparte del hecho de que la segunda utiliza una mesa adicional,

No tiene por qué. Puede generar un token criptográfico autorizando a un usuario en particular para restablecer una contraseña dentro de un marco de tiempo determinado; no se requieren datos adicionales.

Un ejemplo utilizando un código de autenticación de mensajes basado en HMAC (hash de fantasía):

details= user_id+' '+token_expiry_timestamp 
mac= hmac_sha2(server_secret, details) 
token= details+' '+mac

continuación, enviar el token al usuario como parte de la URL se puede hacer clic en un correo electrónico. Cuando reciba un clic atrás, averigüe qué debe ser el mac para ese usuario y la hora con su secreto del lado del servidor, y compruebe que contra el mac pasado. Si coincide, debe ser una solicitud de contraseña que haya firmado anteriormente.

user_id, token_expiry_timestamp, mac= token split on ' ' 
details= user_id+' '+token_expiry_timestamp 
if hmac_sha2(server_secret, details)!=mac 
    complain 
else if token_expiry_timestamp<now 
    complain 
else 
    allow password for user_id to be changed

Esto requiere ningún estado, pero debería utilizar más cortos tiempos de expirar como las fichas podrían ser utilizados varias veces si no registro de uso.

Fuente

2010-02-16 23:19:21 bobince

+0

Creo que está malinterpretando el bit de contraseña enviada. Enviaría una nueva contraseña generada aleatoriamente, no la contraseña antigua y real. El usuario tendría que elegir una nueva contraseña una vez que esté ingresada. No se compartirá la contraseña maestra. – ceejayoz

+5

OK, pero hecho de esa manera no se puede cambiar la * real * contraseña al azar en una solicitud de contraseña porque sería un problema obvio de DoS. Tendría que tener dos contraseñas, que al final no es muy diferente a tener un token de restablecimiento por separado. – bobince

+0

buena solución. Estoy extendiendo esto más en mi publicación. –

1

Mientras la URL no solicite una contraseña o algo así, sigue siendo mejor que la contraseña enviada al azar, pero solo porque no deja la contraseña en texto sin formato en una Bandeja de entrada.

En otras palabras, el enlace reduce la ventana de oportunidad.

Fuente

2010-02-16 23:19:37

+2

¿Por qué? La clave aleatoria en la URL es, en esencia, una contraseña, y es solo como texto sin formato. Ellos son lo mismo. – ceejayoz

+1

@ceejayoz: Porque la URL se invalida cuando se usa. La contraseña del correo electrónico tiene el potencial de nunca cambiar. Realmente serían lo mismo si iniciar sesión con la contraseña enviada lo obliga a cambiarlo Y la contraseña aleatoria enviada tiene una fecha de caducidad. –

+1

@ceejayoz: Considere el caso de alguien leyendo por encima del hombro. Si ven un correo electrónico que dice "Su nueva contraseña es 'secreta'", pueden salir corriendo e iniciar sesión como usted. Si ven un enlace, es menos probable que puedan recordarlo y no tengan la oportunidad de hacer clic. Si puede recordar cadenas como '2b574cb4478ce2f65b00d111a38631833c1f6ba696224896ee4abccffac38fe3d3e0dfbd1984ed0bdae3b6293b94fd7b', entonces tendrá más poder para usted. Además, si el correo electrónico se envía en formato HTML, un enlace que dice 'haga clic aquí para restablecer su contraseña' es considerablemente menos útil. – Duncan

2

Obviamente, este último es mucho más seguro. El correo electrónico es como una postal. Casi todo el mundo puede leerlo y quiere hacerlo. Además, una vez que se cambia la contraseña, envíe un correo electrónico para cerrar el ciclo.

Fuente

2010-02-16 23:19:44 wallyk

+2

El enlace también está en un correo electrónico, si fuera interceptado y si no solicita autenticación, es igualmente inseguro. –

21

Si envía un correo electrónico con la contraseña, significa:

La contraseña pasará por algunas redes (sin cifrar) y podría ser "visto"
La contraseña se mantendrá en el buzón de correo del usuario
- Cuál puede ser hackeado
- Y de la misma cualquiera que tenga acceso a la computadora podría echar un vistazo

Por lo tanto, el envío de la contraseña en un correo electrónico no parece tan seguro ...

Como usuario, me siento que mi contraseña es "más seguro" con el enlace que contiene algún tipo de token y caduca después de un tiempo.

Ese "expira después de un tiempo" parte es importante, por cierto: se asegura de que si alguien hace clic en el enlace después de algún tiempo (por ejemplo, alguien que tiene acceso a buzón del usuario), el enlace no lo hará ser usado para generar una nueva contraseña.

Por supuesto, esto significa que no será capaz de simplemente "búsqueda en mi buzón de correo electrónico" para encontrar la contraseña - pero siempre puedo pedir uno nuevo me he olvidado de nuevo ^^

Fuente

2010-02-16 23:19:46

+2

Una contraseña aleatoria, no la contraseña original del usuario (que nunca debe almacenarse en una forma recuperable, de todos modos). Un enlace es tan bueno como una contraseña en esta situación. – ceejayoz

+0

excepto que el enlace es de corta duración * (no se puede usar después de un tiempo) *; mientras que la contraseña se encuentra en el buzón del usuario para siempre. –

+5

O puede enviar al usuario una contraseña temporal que expira. Una vez que el usuario inicia sesión con la contraseña temporal, inmediatamente se le solicita que la cambie. –

10

Bastante desconcertado por las otras respuestas aquí. Son exactamente lo mismo. Ambos dan acceso a la cuenta del usuario, ambos se envían en texto plano, y ambos son de uso común. Elige lo que prefieras.

Imponga un cambio inmediato de contraseña una vez que utilicen el enlace/contraseña, y haga que el enlace/contraseña caduque después de 24-72 horas.

Fuente

2010-02-16 23:28:24 ceejayoz

+0

Estoy de acuerdo contigo por completo, ambos parecen iguales. La mayoría de las demás respuestas presuponen que no es posible caducar una contraseña ni tener una segunda contraseña temporal. Lo único que cambiaría es el tiempo. Creo que 24 - 72 horas es demasiado tiempo. Para ser honesto, 10 minutos deberían ser tiempo suficiente. – Peter

+2

He tenido correos electrónicos que demoran una hora o más en aparecer en mi bandeja de entrada de ciertos remitentes. – ceejayoz

+0

Enviar una nueva contraseña permite molestar a los usuarios ya que no pueden usar su contraseña normal. Cuando se envía un token, el usuario puede continuar utilizando la contraseña anterior (caduca el token). – eckes

1

Siempre he sido fan de establecer un hashcode y darles un enlace.

Enviando un correo electrónico al usuario luego haciéndoles saber que solicitó un enlace de recuperación de contraseña, y después de que establezcan uno diciéndoles que se cambió su contraseña es generalmente una buena cortesía en caso de que haya una violación.

Un usuario reaccionará muy rápidamente a un correo electrónico diciendo que su contraseña ha cambiado si no fue su intención.

Lamentablemente, no existe una forma real de "SEGURO". Preguntas de seguridad que los pines pueden ayudar pero nunca son realmente seguros.

Fuente

2010-02-16 23:44:14 Chris

7

Una diferencia que las personas parecen haber ignorado es que, por ejemplo, una aplicación web, una opción de restablecimiento de contraseña generalmente está abierta para cualquiera que acceda a un sitio y sepa el nombre de usuario/inicio de sesión de la cuenta que desea restablecer. contraseña para.

Al enviar un enlace en un correo electrónico que el usuario debe hacer clic para poder restablecer su contraseña, evita que los usuarios reinicien accidental o maliciosamente las contraseñas de otras personas; todo lo que sucederá es que reciben un correo electrónico que termina con "Si no solicitó restablecer su contraseña, ignore este correo electrónico".

Incluso si no se trata de un riesgo de seguridad per se, restablecer las contraseñas sin confirmación podría ser una gran molestia.

Fuente

2010-02-16 23:49:47 Latedeveloper

+0

Well OP podría haber considerado ya este problema. La mayoría de los sitios le envía un correo electrónico con una URL para restablecer o emitir una nueva contraseña. Luego obtienes un segundo correo electrónico con lo que OP está decidiendo. Simplemente podemos ignorar el primer problema y asumir que OP lo ha considerado. – Pyrolistical

+0

Si OP lo hubiera considerado, por qué tendrían que enviar un correo electrónico en primer lugar. La única razón para usar el correo electrónico es verificar que la persona que solicita el cambio de acceso tenga, al menos, acceso a la cuenta utilizada para crear la credencial. –

-1

Todo el mundo excepto ceeyajoz está utilizando una lógica defectuosa. Es difícil pensar en seguridad.

Ambos casos utilizan el correo electrónico que está en texto sin formato. Ambos son igualmente inseguros cuando se piratea el correo electrónico.

No importa si la URL caduca porque el correo electrónico está pirateado, el pirata informático puede solicitar otra URL de restablecimiento de contraseña. Si la contraseña temporal ha cambiado, el pirata informático podría simplemente solicitar una nueva. De cualquier manera estás jodido.

Así que digo simplemente envíe la contraseña, de esta manera es un paso menos para que el usuario elija una nueva.

EDIT Cuando dije "envíe la contraseña" fue en el contexto del OP donde envía una nueva contraseña aleatoria.

Fuente

2010-02-16 23:53:00 Pyrolistical

+1

Entonces, cualquiera puede ir al sitio y restablecer las contraseñas de otras personas. –

+0

??? ¿Cómo? Debe estar malentendiéndome – Pyrolistical

+0

Si el correo electrónico se ha visto comprometido, entonces cualquiera de las dos formas es inseguro. Sin embargo, si envía la contraseña, acaba de darle acceso potencial al hacker a numerosos sitios, ya que muchas personas usan la misma contraseña, incluso si esos otros sitios no exponen la contraseña o están registrados con diferentes direcciones de correo electrónico. Enviar un enlace mitiga el daño hecho. Es más seguro, no necesariamente seguro. Supongo que tu comentario acerca de todos, excepto ceejayoz, usando una lógica defectuosa significa que estás usando una lógica defectuosa. – Duncan

1

enviarles un correo electrónico con un azar, un uso del tiempo, contraseña.
Forzarlos a cambiar la contraseña cuando lleguen por primera vez.
Notificarles que cambiaron su contraseña .

Enviar la contraseña aleatoria es tan arriesgado como enviar el enlace. es decir, cualquier persona puede obtener el correo electrónico primero e iniciar sesión como usuario la primera vez.

Al forzar el cambio, quien obtenga la primera no puede volver allí sin establecer una contraseña.

La notificación al usuario del cambio indica que la contraseña se ha cambiado, y esto puede suceder antes de que el atacante pueda realmente iniciar sesión y cambiar el correo electrónico de notificación.

Por lo tanto, si alguien llegara primero al sitio, el correo electrónico original para el usuario ya no funcionará, ya que la contraseña original ya no es válida. Además, se les notificará el cambio de contraseña.

Esto les brinda la oportunidad de notificar a los administradores del sistema cuando se muestran y descubren que no pueden iniciar sesión en sus cuentas.

Ninguno de estos detienen la capacidad de una persona que intercepta el correo electrónico y obtiene ALGUN acceso, pero al menos le permite al usuario original y con derechos adquiridos saber que algo anda mal.

Fuente

2010-02-17 00:03:23

1

Algunos han afirmado que ambos son equivalentes - esto no es cierto para las siguientes razones:

1) con enlace de restablecimiento si el atacante tiene acceso al correo electrónico y por lo tanto utiliza enlace de restablecimiento para cambiar la contraseña, van a alertar al usuario incluso si el atacante elimina el correo electrónico y las notificaciones de restablecimiento real. Con la contraseña de correo si el usuario solicita el restablecimiento y el atacante ve la contraseña aleatoria (incluso mucho más tarde), el atacante puede acceder a la cuenta del usuario en su sitio sin alertar al usuario.

2) Además, si envía una contraseña, el usuario puede tener la tentación de volver a utilizar la contraseña en otros sitios y el atacante con acceso al mismo tiene acceso a otros sitios incluso si los otros sitios no son vulnerables. Recuperación de Cuenta.

Con la contraseña aleatoria enviada en el correo electrónico y el enlace de restablecimiento, si el atacante controla el correo electrónico del usuario, tiene acceso a la cuenta del usuario. Lo que puede hacer en este caso depende de cuántos controles tiene el usuario; por ejemplo, si tiene su dirección de correo electrónico principal y alternativa, entonces debe enviar notificaciones a ambas cuentas de correo electrónico cuando se solicite y use el restablecimiento, o si tiene un teléfono, puede enviarles un mensaje de texto además del correo electrónico, etc. Puede monitorear el uso en sí mismo, pero eso es más difícil.

Un par de otras cuestiones:

Se puede utilizar el enlace varias veces? Además de caducar y tener un valor impredecible (con MAC adjunto para que pueda verificarse sin el estado del servidor), es posible que desee activar una alerta interna si se intenta restablecer la contraseña en una cuenta varias veces (registrar éxito/falla, dirección IP remota, marca de tiempo, etc.) y abortar primero y poner la cuenta en algún estado inactivo.

Sería una buena idea ver cuánto abuso está ocurriendo para ver si necesita más mecanismos de defensa para evitar adquisiciones de cuentas a través de los flujos de recuperación de su cuenta (depende del valor de una cuenta).

También es muy importante en este caso mantenerse actualizado en direcciones de correo electrónico y otra información de contacto si puede (las direcciones de correo electrónico se reciclan cuando no se usan) y cómo la dirección de correo electrónico u otra información puede actualizarse/agregarse y notificaciones

Como siempre, asegúrese de que sus notificaciones (texto, enlace, página de inicio) no sean fáciles para los phishers.

Algunos de estos problemas, por supuesto, pueden no ser muy relevantes a menos que tenga un sitio grande.

Fuente

2010-02-17 00:03:42 mar

0

Envíales un enlace para que luego puedan restablecer su contraseña. Esto los obliga a confirmar en cierta forma su cuenta para la que están restableciendo la contraseña. Si restablece la contraseña sin enviar un correo electrónico, cualquier persona puede iniciar sesión en el sitio y restablecer la contraseña de otra persona. Esto crea una vulnerabilidad de tipo denegación de servicio.

Fuente

2010-02-17 00:09:26

-1

Estoy de acuerdo con el proceso de will's.

Sin embargo, si solo elige entre las opciones que ha dado, aunque ambas opciones son básicamente las mismas en las que está enviando información por correo electrónico, creo que este último es un método más común.

si un hacker solicitara una nueva contraseña, la contraseña anterior del usuario ya no funcionaría. al menos con esta última opción, en realidad no cambia ningún detalle del usuario.

Fuente

2010-02-17 00:10:31 benpage

+0

No deshabilita la contraseña anterior. Eso sería terriblemente inutilizable. Establece una segunda contraseña temporal. El usuario aún puede iniciar sesión con su contraseña real (evitando abusos), o usar la contraseña temporal le permite establecer una contraseña real. – ceejayoz

0

Aunque pueda estar repitiendo algunas respuestas, me siento obligado a responder porque recientemente tuvimos algunos problemas con las herramientas de recuperación de contraseñas. Una de las cuentas personales de mi compañero de trabajo se vio comprometida, lo que permitió que nuestras aplicaciones de dominio alojadas en Google se vieran comprometidas. Debido a contraseñas de texto sin cifrar y preguntas de recuperación de contraseña estúpidas que eran googleables, otras cuentas se vieron comprometidas también.

Baste decir que soy un fiel seguidor de los enlaces por correo electrónico que caducan después de 4 horas. Estuve allí 4 horas ingresando a una de nuestras cuentas luego de recibir el enlace asegurándome de que aún no se había comprometido. 24-48 horas sería demasiado tiempo para tener que hacer eso. 4 horas fue demasiado tiempo. Una contraseña generada aleatoriamente que el usuario debe cambiar en el siguiente inicio de sesión es la segunda mejor opción, pero depende por completo de que el usuario realmente inicie sesión. La contraseña se cambia permanentemente, mientras que si el usuario no hace nada con el enlace, la contraseña no ser reiniciado

No existe una solución perfecta contra un individuo dedicado que quiera comprometer su sistema. Hay mejores soluciones que otras.

Fuente

2010-02-17 00:30:27

+0

Gracias a Dios Google Apps for Domains ofrece autenticación de dos factores, especialmente para las funciones de administración. – eckes

0

Extender desde la solución de bobince ... Aquí el usuario debe volver a ingresar el identificador de usuario y el token en la página de restablecimiento de contraseña.

A petición de la página de restablecimiento de contraseña

urserId = Input userId 
token = Randomly generated token (or one time password) 
tokenExpire = Decide token expiry date/time 
Store in DB tokenExpiry for this urserId 
urlToken= MD5 hash value of (urserId + token + tokenExpire) 
pwdRestURL = server pwd reset url + "?urlToken=" + urlToken 

Send above generated URL and make sure you do not 
    include either of userId or token in email 

Display token to user (This is to be used on password reset page)

.

En la página de restablecimiento de contraseña (utilizando por encima de URL pwdRestURL)

urlToken = Token from URL request 
userId = Input userId 
token = Input token 
tokenExpiry = tokenExpiry from DB for this user 
resetToken = MD5 hash value of (urserId + token + tokenExpire) 
IF 
    resetToken == urlToken 
    AND tokenExpiry for user is valid 
THEN 
    Clear tokenExpiry 
    Allow user to change password 
ELSE 
    Display Error 
END IF

.

Ventajas del enfoque anterior:

Incluso si el correo electrónico es de alguna forma expuesta en la red, no se puede restablecer la contraseña sin conocer el ID de usuario y token.
simbólico tiene un periodo de caducidad
No existe una prueba clara información personal se transmite por correo electrónico

Fuente

2010-02-17 03:28:36

+0

utilice HMAC_SHA2 en lugar de MD5 con concatenación secreta. – eckes

¿Qué es más seguro? ¿Debo enviar un correo electrónico con una URL que expira a los usuarios para restablecer su contraseña o debo enviar por correo electrónico una contraseña recién generada?

Respuesta

Cuestiones relacionadas