security - recuperar - ¿Qué es más seguro? ¿Debo enviar un correo electrónico con una URL que caduque a los usuarios para restablecer su contraseña o debo enviar una contraseña recién generada?
restablecer contraseña de facebook (14)
Envíe un correo electrónico con un enlace que caduque dentro de un cierto período de tiempo en el que el usuario puede restablecer su contraseña.
Ese, definitivamente.
El correo electrónico siempre está claro (posiblemente la conexión de su sitio puede no serlo) 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 este último utiliza una tabla extra,
No tiene que hacerlo. Puede generar un token criptográfico que autoriza a un usuario en particular a restablecer una contraseña dentro de un período de tiempo determinado; No se requieren datos adicionales.
Un ejemplo que utiliza un código de autenticación de mensaje basado en HMAC (hashing sofisticado):
details= user_id+'' ''+token_expiry_timestamp
mac= hmac_sha2(server_secret, details)
token= details+'' ''+mac
luego, envíe el token al usuario como parte de la URL en la que se puede hacer clic en un correo. Cuando reciba un clic, averigüe cuál debe ser el mac para ese usuario y la hora con su secreto del lado del servidor, y verifique eso con el mac que se aprobó. Si coincide, debe ser una solicitud de contraseña que firmó 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 no requiere estado, pero debe usar tiempos de caducidad más cortos, ya que los tokens podrían usarse varias veces si no registra el uso.
Me preguntaba cuál sería la opción más segura cuando los usuarios hayan olvidado su contraseña
- Enviar una nueva contraseña generada aleatoriamente a la dirección de correo electrónico (se confirma que todas las direcciones de correo electrónico en mi base de datos funcionan).
O
- Envíe un correo electrónico con un enlace que caduque dentro de un cierto período de tiempo en el que el usuario puede restablecer su contraseña.
Aparte del hecho de que este último utiliza una tabla adicional, ¿qué cree que es una práctica mejor / más segura?
Envíeles un correo electrónico con una contraseña aleatoria de un solo uso.
Forzarlos a cambiar la contraseña cuando llegan por primera vez.
Notificarles que han cambiado su contraseña.
Enviar la contraseña aleatoria es tan peligroso como enviar el enlace. es decir, cualquier persona puede recibir el correo electrónico primero e iniciar sesión como usuario la primera vez.
Al forzar el cambio, quien obtenga el primero no podrá volver a hacerlo sin establecer una contraseña.
Notificar al usuario sobre el cambio les dice que la contraseña ha sido cambiada, y esto puede suceder antes de que el atacante pueda 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 de sistemas cuando se muestran y descubren que no pueden iniciar sesión en su cuenta.
Ninguno de estos detiene la capacidad de una persona para interceptar el correo electrónico y obtener ALGUNO acceso, pero al menos le permite al usuario original, creado, saber que algo anda mal.
Algunos han declarado que ambos son equivalentes, esto no es cierto por las siguientes razones:
1) Con el enlace de restablecimiento si el atacante tiene acceso al correo electrónico y, en consecuencia, utiliza el enlace de restablecimiento para cambiar la contraseña, alertará al usuario incluso si el atacante elimina el correo electrónico de restablecimiento real y las notificaciones. Con la contraseña de correo electrónico, 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 avisar al usuario.
2) Además, si envía una contraseña, el usuario puede verse tentado a reutilizarla en otros sitios y el atacante con acceso al correo electrónico tiene acceso a otros sitios, incluso si los otros sitios no eran vulnerables a la toma de cuenta a través de la recuperación de la cuenta.
Con una contraseña aleatoria enviada por correo electrónico y un 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 la cantidad de manejadores del usuario que tenga; 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 se use el reinicio o si tenga un teléfono, podría enviarles un mensaje de texto además del correo electrónico, etc. Puede controlar el uso en sí mismo, pero eso es más difícil.
Un par de otros temas:
¿Se puede utilizar el enlace varias veces? Además de vencer y tener un valor impredecible (con MAC adjunto para que pueda verificarse sin el estado del servidor), es posible que desee que se active una alerta interna si se intenta restablecer la contraseña en una cuenta varias veces (registro exitoso / fallido, dirección IP remota, marca de tiempo, etc.) y cancelar después de la primera 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 la toma 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 sobre las 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 similar se puede actualizar y agregar notificaciones.
Como siempre, asegúrese de que sus notificaciones (texto, enlace, página de destino) no lo hagan fácil para los phishers.
Algunos de estos problemas, por supuesto, pueden no ser muy relevantes a menos que tenga un sitio grande.
Aunque puedo estar repitiendo algunas respuestas, me siento obligado a responder porque recientemente tuvimos algunos problemas con las herramientas de recuperación de contraseñas defectuosas. 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 las contraseñas de texto simple sin eliminar y la recuperación de contraseñas estúpidas, también se pusieron en peligro otras cuentas que no se podían eliminar.
Basta con decir que soy un gran seguidor de los enlaces enviados por correo electrónico que caducan después de 4 horas . Me quedé allí durante 4 horas iniciando sesión en una de nuestras cuentas después de recibir el enlace, asegurándome de que aún no estaba comprometido. 24-48 horas sería demasiado largo para tener que hacer eso. 4 horas fue demasiado larga. Una contraseña generada aleatoriamente que el usuario debe cambiar en el próximo inicio de sesión es la segunda mejor, pero depende completamente 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 restablecido
No existe una solución perfecta contra una persona dedicada que quiere comprometer su sistema. Hay mejores soluciones que otras.
Envíeles un enlace para que luego puedan restablecer su contraseña. Esto los obliga a confirmar de alguna manera su cuenta en la que están restableciendo la contraseña. Si restablece la contraseña sin enviar un correo electrónico, cualquiera puede iniciar sesión en el sitio y restablecer la contraseña de otra persona. Esto crea una vulnerabilidad de tipo de denegación de servicio.
Estoy de acuerdo con el proceso de voluntad.
Sin embargo, si solo elige entre las opciones que ha dado, aunque ambas opciones son esencialmente las mismas en que está enviando información por correo electrónico, creo que este último es un método más común.
si un pirata informático solicitara una nueva contraseña, la contraseña anterior del usuario ya no funcionará. al menos con la última opción, en realidad no cambia los detalles del usuario.
Extendiendo de la solución de Bobince ... Aquí se requiere que el usuario vuelva a ingresar userId y token en la página de restablecimiento de contraseña.
A petición de la página de restablecer 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 (usando la URL de pwdRestURL anterior)
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 está expuesto en la red, nadie puede restablecer la contraseña sin conocer el ID de usuario y el token.
- El token tiene un período de caducidad.
- No se transmite información personal clara de prueba por correo electrónico
Más bien desconcertado por las otras respuestas aquí. Son exactamente iguales. Ambos dan acceso a la cuenta del usuario, ambos se envían en texto sin formato y ambos son de uso común. Elige el que prefieras.
Imponga un cambio de contraseña inmediato una vez que usen el enlace / contraseña, y haga que el enlace / contraseña caduque después de 24-72 horas.
Obviamente este último es mucho más seguro. El correo electrónico es como una postal. Casi cualquiera puede leerlo quien quiera. Además, una vez que se cambie la contraseña, envíe un correo electrónico para cerrar el ciclo.
Si envías un correo electrónico con la contraseña, significa:
- La contraseña pasará por algunas redes (sin cifrar) y podría ser "vista"
- La contraseña quedará en el buzón del usuario.
- Que puede ser hackeado
- Y cualquiera que tenga acceso a la computadora puede echar un vistazo
Por lo tanto, enviar la contraseña en un correo electrónico no parece tan seguro ...
Como usuario, sentiría que mi contraseña es "más segura" con el enlace que contiene algún tipo de token y caduca al cabo de un tiempo.
Esa parte " expira después de un tiempo " es importante, por cierto: asegura que si alguien hace clic en el enlace después de un tiempo (por ejemplo, alguien que accede al buzón del usuario) , el enlace no se utilizará para generar una nueva contraseña.
Por supuesto, esto significa que no podré simplemente " buscar en mi casilla de correo " para encontrar la contraseña, pero siempre puedo pedir una nueva, la he olvidado otra vez ^^
Siempre me ha gustado configurar un código hash y darles un enlace.
Después de enviar un correo electrónico al usuario para informarle que solicitó un enlace de recuperación de contraseña, y después de establecer uno que le informa que se cambió su contraseña, generalmente es una buena cortesía en caso de que haya una violación.
Un usuario reaccionará rápidamente a un correo electrónico diciendo que su contraseña fue cambiada si no pretendían hacerlo.
Desafortunadamente no hay una manera real "SEGURA". Las preguntas de seguridad y los pines pueden ayudar, pero nunca son realmente seguros.
Siempre que la URL no solicite una contraseña o algo así, es mejor que la contraseña enviada aleatoriamente, 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.
Todos, excepto Ceeyajoz, están usando una lógica defectuosa. Es difícil pensar en la seguridad.
Ambos casos utilizan el correo electrónico que está en texto plano. Ambos son igualmente inseguros cuando el correo electrónico es hackeado.
No importa si la URL caduca, ya que el correo electrónico ha sido pirateado, el pirata informático solo puede solicitar otra URL para restablecer la contraseña. Si la contraseña temporal ha cambiado, el pirata informático podría solicitar una nueva. De cualquier manera estás jodido.
Por eso digo que simplemente envíe la contraseña, de esta manera es un paso menos para que el usuario elija una nueva.
EDITAR Cuando dije "enviar la contraseña" estaba en el contexto del OP donde enviaba una nueva contraseña aleatoria.
Una diferencia que la gente parece haber descuidado es que, al tomar una aplicación web, por ejemplo, una opción de restablecimiento de contraseña generalmente está abierta a cualquier persona que acceda a un sitio y conozca el nombre de usuario / inicio de sesión de la cuenta para la que desea restablecer la contraseña.
Al enviar un enlace en un correo electrónico en el que el usuario tiene que 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 recibirán un correo electrónico que termina con "Si no solicitó restablecer su contraseña, ignore este correo electrónico ".
Incluso si no es un riesgo de seguridad en sí mismo, restablecer las contraseñas sin confirmación podría ser una gran molestia.