Almacenar la contraseña de un usuario de manera recuperable

Question

Almacenar la contraseña de un usuario de manera recuperable

#1 de Adam Katz (4 votos)
#2 de rook (0 votos)

4

Actualmente guardo las contraseñas de mis usuarios como hash PBKDF2, para la parte de autenticación de mi aplicación web.

Cada usuario también tiene su propia clave privada y pública (también almacenada en su perfil de usuario en la base de datos). La clave privada se cifra con su contraseña de texto sin formato al registrarse.

Ahora, he llegado a la parte en la que necesito recuperar la clave privada del usuario para descifrar otros datos, por lo que el problema es. ¿Cuál sería la mejor manera de permitirme acceder a la clave privada del usuario?

Tengo un par de ideas en mente:

Podría (al iniciar sesión) descifrar la clave privada, luego cifrarla con DPAPI y almacenarla en la memoria persistente (lado del servidor).

Podría cifrar la contraseña del usuario con una OTP, y luego almacenar la contraseña cifrada en una cookie (en cada solicitud podría generar una nueva OTP, volver a cifrar la contraseña y volver a colocarla en la cookie) La OTP tendría para ser almacenado en la memoria persistente del servidor (probablemente encriptada con DPAPI).

Podría almacenar la tienda OTP y la contraseña cifrada en la memoria persistente (lado del servidor).

Podría almacenar la mitad de la contraseña (cifrada) en una cookie y la otra mitad en la memoria persistente (lado del servidor).

¿Cuál de estas opciones sería la más segura? ¿Hay otro método que no haya pensado?

Sé que hacer rodar la suya es una cuestión básica, pero esta aplicación no necesita ser super segura a nivel gubernamental, pero me gustaría que fuera lo más segura posible.

passwords password-management encryption

pregunta binks 06.09.2014 - 16:57

fuente

2 respuestas

Lea otras preguntas en las etiquetas passwords password-management encryption

¿Qué es esta extraña solicitud GET (GET / A0A32579-2767) DoSed my apache? Cifrado y HMAC con la misma contraseña

score 4 · Answer 1

Parece que quieres una puerta trasera y que no te preocupa la privacidad ni la legalidad. consecuencias.

Dos historias recientes para proporcionar algún contexto

2013: Lavabit intencionalmente no tuvo acceso al contenido de sus usuarios por lo que no pudo ser accedido por una orden judicial. Cuando la NSA descubrió que podían obtenerla exigiendo la clave privada SSL del servidor y leyendo todo de tráfico (en lugar de la del usuario en cuestión, Edward Snowden ), Lavabit decidió cerrar en lugar de arriesgarse a comprometer la seguridad de cada usuario.

2016: debacle entre Apple y FBI es una historia similar, en este momento, sobre la insensatez de las puertas traseras. He elegido vincular un resumen de la explicación del comediante John Oliver sobre el tema porque está bastante bien compuesto. Ese enlace también incluye la función HBO de 18 minutos de Oliver sobre este problema, que puede ver directamente en La semana pasada de esta noche con John Oliver - Encriptación

Si todavía quieres hacer esto

PGP admite múltiples destinatarios , que recomendaría más realmente guardando la contraseña. Esto le permitirá cifrar datos en una clave de servidor además de una clave específica del usuario. Tenga en cuenta que sería muy irresponsable no anunciar que está haciendo esto a sus usuarios. Incluso podría ser ilegal.

Implementar esto es tan simple como especificar más de un destinatario en GPG o cualquier implementación que uses. Por ejemplo:

gpg --encrypt --recipient [email protected] \
              --recipient [email protected] message.eml

Dependiendo de su uso previsto, es probable que esto requiera almacenar la clave PGP privada del servidor sin una contraseña, lo cual es un problema en sí mismo. Si es posible, intente usar un sistema basado en hardware como una tarjeta OpenPGP o al menos solicite a un humano que desbloquee la clave en cada inicio (con conmutación por error a su código que acepte que la clave privada del servidor no siempre se cargue).

Nuevamente, esta es una puerta trasera y no se recomienda ya que todavía está sujeta a citaciones y piratas informáticos (aunque una tarjeta OpenGPG o una llave de hardware similar deben evitar los ataques remotos).

Sería sumamente preferible encontrar alguna otra solución para su problema. Ya que no ha explicado lo que realmente está tratando de hacer, esta comunidad no podrá ayudar en ese sentido.

score 0 · Answer 2

Si el servidor está realizando el cifrado y el descifrado, entonces ha creado una " promesa de no echar un vistazo " . Una vez que su solicitud haya sido comprometida, aunque sea por medios legales o técnicos, esta promesa quedará sin efecto. Todas las soluciones sugeridas en la publicación anterior se incluyen en esta categoría.

Para que los secretos de un usuario permanezcan en secreto, los secretos solo deben existir en la máquina del cliente. End-To-End de Google está intentando hacer esto en el navegador mediante un complemento de JavaScript. Este sistema funciona según lo previsto, en el sentido de que Google es solo uno que "promete no mirar". Google controla todas las actualizaciones, por lo que se les permite usar Backdoor Chrome o End-To-End para comprometer los secretos en el cliente.