security - online - ¿Cómo debería acercarme éticamente al almacenamiento de contraseñas de usuarios para la recuperación posterior de texto sin formato?

password hash salt (26)

¿Los usuarios realmente necesitan recuperar (p. Ej., Que se les diga) cuál fue la contraseña que olvidaron o simplemente necesitan poder acceder al sistema? Si lo que realmente quieren es una contraseña para iniciar sesión, ¿por qué no tener una rutina que simplemente cambie la contraseña anterior (sea la que sea) a una nueva contraseña que la persona de apoyo pueda darle a la persona que perdió su contraseña?

He trabajado con sistemas que hacen exactamente esto. La persona de soporte no tiene forma de saber cuál es la contraseña actual, pero puede restablecerla a un nuevo valor. Por supuesto, todos estos reinicios deben registrarse en algún lugar y una buena práctica sería generar un correo electrónico para el usuario que le indique que la contraseña se ha restablecido.

Otra posibilidad es tener dos contraseñas simultáneas que permitan el acceso a una cuenta. Una es la contraseña "normal" que el usuario administra y la otra es como una llave maestra / esqueleto que solo conoce el personal de soporte y es la misma para todos los usuarios. De esa manera, cuando un usuario tiene un problema, la persona de soporte puede iniciar sesión en la cuenta con la clave maestra y ayudar al usuario a cambiar su contraseña a lo que sea. No hace falta decir que todos los inicios de sesión con la clave maestra también deben ser registrados por el sistema. Como medida adicional, siempre que se use la clave maestra, también podría validar las credenciales de las personas de apoyo.

-EDIT- En respuesta a los comentarios acerca de no tener una clave maestra: Estoy de acuerdo en que es malo, ya que creo que es malo permitir que alguien que no sea el usuario tenga acceso a la cuenta del usuario. Si observa la pregunta, toda la premisa es que el cliente exigió un entorno de seguridad altamente comprometido.

Una clave maestra no tiene por qué ser tan mala como parece a primera vista. Solía trabajar en una planta de defensa donde percibían la necesidad de que el operador de computadora central tuviera "acceso especial" en ciertas ocasiones. Simplemente colocaron la contraseña especial en un sobre sellado y la pegaron al escritorio del operador. Para usar la contraseña (que el operador no sabía) tenía que abrir el sobre. En cada cambio de turno, uno de los trabajos del supervisor de turno consistía en ver si el sobre se había abierto y, en ese caso, si la contraseña había sido cambiada (por otro departamento) y si la nueva contraseña se había colocado en un nuevo sobre y se había iniciado el proceso otra vez. Se preguntaría al operador por qué lo había abierto y se documentaría el incidente para el registro.

Si bien este no es un procedimiento que diseñaría, funcionó y proporcionó una excelente responsabilidad. Todo fue registrado y revisado, además de que todos los operadores tenían autorizaciones secretas del DOD y nunca tuvimos abusos.

Debido a la revisión y la supervisión, todos los operadores sabían que si abusaban del privilegio de abrir el sobre, estaban sujetos a despido inmediato y un posible enjuiciamiento criminal.

Entonces, supongo que la respuesta real es que si uno quiere hacer las cosas bien, contrata a personas en las que puede confiar, verifique los antecedentes y ejerza la supervisión y la responsabilidad adecuadas de la administración.

Pero, de nuevo, si el cliente de este pobre hombre tuviera una buena administración, en primer lugar no habrían pedido tal solución de seguridad comprimida, ¿verdad?

A medida que continúo construyendo más y más sitios web y aplicaciones web, a menudo me piden que guarde las contraseñas de los usuarios de manera que puedan recuperarse si / cuando el usuario tiene un problema (ya sea para enviar por correo electrónico un enlace de contraseña olvidado, guiarlo a través del teléfono, etc.) Cuando puedo luchar amargamente contra esta práctica y hago mucha programación ''extra'' para hacer posibles los restablecimientos de contraseñas y la asistencia administrativa sin almacenar su contraseña real.

Cuando no puedo combatirlo (o no puedo ganar), siempre codifico la contraseña de alguna manera para que, al menos, no se almacene como texto sin formato en la base de datos, aunque soy consciente de que si mi base de datos se hackea El culpable no tardaría mucho en descifrar las contraseñas, así que eso me hace sentir incómodo.

En un mundo perfecto, las personas actualizarían las contraseñas con frecuencia y no las duplicarían en muchos sitios diferentes; desafortunadamente, conozco MUCHAS personas que tienen la misma contraseña de trabajo / hogar / correo electrónico / banco, e incluso me las dieron libremente cuando necesitan asistencia. No quiero ser el responsable de su desaparición financiera si mis procedimientos de seguridad de base de datos fallan por alguna razón.

Moralmente y éticamente, me siento responsable de proteger lo que puede ser, para algunos usuarios, su sustento, incluso si lo tratan con mucho menos respeto. Estoy seguro de que hay muchos caminos para acercarse y argumentos para plantear hashes y diferentes opciones de codificación, pero ¿hay una única "mejor práctica" cuando tiene que almacenarlos? En casi todos los casos, estoy usando PHP y MySQL si eso hace alguna diferencia en la forma en que debo manejar los detalles.

Información adicional para Bounty

Quiero aclarar que sé que esto no es algo que deba hacer y que, en la mayoría de los casos, lo mejor es negarse a hacerlo. Sin embargo, no estoy buscando una conferencia sobre los méritos de adoptar este enfoque, estoy buscando los mejores pasos a seguir si lo hace.

En una nota a continuación, señalé que los sitios web orientados en gran medida hacia las personas mayores, con problemas mentales o muy jóvenes pueden llegar a ser confusos para las personas cuando se les pide que realicen una rutina de recuperación de contraseña segura. Aunque es posible que nos resulte sencillo y mundano, en esos casos, algunos usuarios necesitan la ayuda adicional de contar con un técnico de servicio que los ayude a ingresar al sistema o que se los envíen por correo electrónico o se los muestren directamente.

En tales sistemas, la tasa de desgaste de estos datos demográficos podría entorpecer la aplicación si los usuarios no recibieran este nivel de asistencia de acceso, así que responda con esta configuración en mente.

Gracias a todos

Esta ha sido una pregunta divertida con mucho debate y la he disfrutado. Al final, seleccioné una respuesta que conserva la seguridad de la contraseña (no tendré que guardar texto sin formato ni contraseñas recuperables), pero también hace posible que la base de usuarios que especifiqué para iniciar sesión en un sistema sin los principales inconvenientes que he encontrado. recuperación de contraseña normal.

Como siempre, hubo alrededor de 5 respuestas que me gustaría haber marcado como correctas por diferentes razones, pero tuve que elegir la mejor: el resto obtuvo un +1. ¡Gracias a todos!

También, gracias a todos en la comunidad de Stack que votaron por esta pregunta y / o la marcaron como favorita. Tomo 100 votos a favor como un cumplido y espero que esta discusión haya ayudado a otra persona con la misma preocupación que tuve.

¿Qué hay de enviar por correo electrónico la contraseña de texto simple al registrarse, antes de que se cifre y se pierda? He visto que muchos sitios web lo hacen, y obtener esa contraseña del correo electrónico del usuario es más seguro que dejarlo en su servidor / comp.

¿Qué hay de tomar otro enfoque o ángulo en este problema? Pregunte por qué se requiere que la contraseña esté en texto simple: si es para que el usuario pueda recuperar la contraseña, entonces estrictamente hablando, no necesita recuperar la contraseña que estableció (de todos modos no recuerdan de qué se trata), Necesitan poder darles una contraseña que puedan usar .

Piénselo: si el usuario necesita recuperar la contraseña, es porque la ha olvidado. En cuyo caso una nueva contraseña es tan buena como la anterior. Pero, uno de los inconvenientes de los mecanismos comunes de restablecimiento de contraseñas que se usan hoy en día es que las contraseñas generadas en una operación de restablecimiento son generalmente un conjunto de caracteres aleatorios, por lo que es difícil para el usuario simplemente escribir correctamente a menos que copien-n- pegar. Eso puede ser un problema para los usuarios de computadoras menos inteligentes.

Una forma de solucionar este problema es proporcionar contraseñas generadas automáticamente que sean más o menos texto en lenguaje natural. Si bien las cadenas de lenguaje natural pueden no tener la entropía que tiene una cadena de caracteres aleatorios de la misma longitud, no hay nada que diga que su contraseña generada automáticamente solo debe tener 8 (o 10 o 12) caracteres. Obtenga una frase de contraseña autogenerada de alta entropía uniendo varias palabras aleatorias (deje un espacio entre ellas, para que todos puedan leerlas). Es probable que seis palabras aleatorias de longitud variable sean más fáciles de escribir correctamente y con más confianza que 10 caracteres aleatorios, y también pueden tener una entropía más alta. Por ejemplo, la entropía de una contraseña de 10 caracteres extraída al azar de mayúsculas, minúsculas, dígitos y 10 símbolos de puntuación (para un total de 72 símbolos válidos) tendría una entropía de 61,7 bits. Usando un diccionario de 7776 palabras (como utiliza Diceware) que podría seleccionarse al azar para una frase de contraseña de seis palabras, la frase de contraseña tendría una entropía de 77,4 bits. Consulte las preguntas frecuentes de Diceware para obtener más información.

una frase de contraseña con aproximadamente 77 bits de entropía: "admita el estilo agudo de la tabla de destellos de prosa"
una contraseña con aproximadamente 74 bits de entropía: "K: & $ R ^ tt ~ qkD"

Sé que preferiría escribir la frase, y con copiar y pegar, la frase no es menos fácil de usar que la contraseña, así que no hay pérdida allí. Por supuesto, si su sitio web (o lo que sea el activo protegido) no necesita 77 bits de entropía para una frase de contraseña generada automáticamente, genere menos palabras (que estoy seguro de que sus usuarios apreciarían).

Entiendo los argumentos de que hay activos protegidos por contraseña que realmente no tienen un alto nivel de valor, por lo que la violación de una contraseña podría no ser el fin del mundo. Por ejemplo, probablemente no me importaría si el 80% de las contraseñas que utilizo en varios sitios web fueron violadas: todo lo que podría suceder es que alguien envíe correos electrónicos no deseados o publique bajo mi nombre por un tiempo. Eso no sería genial, pero no es como si estuvieran ingresando en mi cuenta bancaria. Sin embargo, dado que muchas personas usan la misma contraseña para los sitios de sus foros web que para sus cuentas bancarias (y probablemente para las bases de datos de seguridad nacional), creo que sería mejor manejar incluso las contraseñas de "bajo valor" como no -recuperable.

¿Qué tal una media casa?

Almacene las contraseñas con un cifrado fuerte y no habilite los restablecimientos.

En lugar de restablecer las contraseñas, permita el envío de una contraseña única (que debe cambiarse tan pronto como se produzca el primer inicio de sesión). Deje que el usuario cambie a la contraseña que desee (la anterior, si así lo desean).

Puede "vender" esto como un mecanismo seguro para restablecer las contraseñas.

Acabo de encontrar esta discusión interesante y acalorada. Lo que más me sorprendió fue la poca atención que se prestó a la siguiente pregunta básica:

Q1. ¿Cuáles son las razones reales por las que el usuario insiste en tener acceso a la contraseña almacenada de texto sin formato? ¿Por qué tiene tanto valor?

La información que los usuarios son mayores o jóvenes realmente no responde a esa pregunta. Pero, ¿cómo se puede tomar una decisión comercial sin comprender adecuadamente la preocupación del cliente?

Ahora por qué importa? Porque si la causa real de la solicitud de los clientes es el sistema que es dolorosamente difícil de usar, ¿tal vez abordar la causa exacta resolvería el problema real?

Como no tengo esta información y no puedo hablar con esos clientes, solo puedo adivinar: se trata de usabilidad, ver más arriba.

Otra pregunta que he visto formulada:

Q2. Si el usuario no recuerda la contraseña en primer lugar, ¿por qué es importante la contraseña anterior?

Y aquí es posible respuesta. Si tiene un gato llamado "miaumiau" y usó su nombre como contraseña pero olvidó que lo hizo, ¿preferiría que le recordaran qué era o que le enviaran algo así como "# zy * RW (ew"?

¡Otra posible razón es que el usuario considera que es un trabajo difícil crear una nueva contraseña! Por lo tanto, tener la contraseña antigua devuelta le da la ilusión de salvarla de ese doloroso trabajo nuevamente.

Solo estoy tratando de entender la razón. Pero cualquiera que sea la razón, es la razón y no la causa que debe abordarse.

Como usuario, quiero cosas simples! ¡No quiero trabajar duro!

Si me conecto a un sitio de noticias para leer los periódicos, quiero escribir 1111 como contraseña y terminar.

Sé que es inseguro, pero ¿qué me importa si alguien tiene acceso a mi "cuenta"? Sí, él también puede leer las noticias!

¿El sitio almacena mi información "privada"? ¿Las noticias que leí hoy? Entonces es problema del sitio, no mío! ¿El sitio muestra información privada al usuario autenticado? Entonces no lo muestres en primer lugar!

Esto es solo para demostrar la actitud del usuario hacia el problema.

Entonces, para resumir, no creo que sea un problema de cómo almacenar de forma "segura" las contraseñas de texto sin formato (que sabemos que es imposible), sino cómo abordar la preocupación real de los clientes.

Asegurar las credenciales no es una operación binaria: segura / no segura. La seguridad tiene que ver con la evaluación de riesgos y se mide en forma continua. Los fanáticos de la seguridad odian pensar de esta manera, pero la fea verdad es que nada es perfectamente seguro. Las contraseñas encriptadas con requisitos de contraseña estrictos, muestras de ADN y exploraciones de retina son más seguras pero a un costo de desarrollo y experiencia para el usuario. Las contraseñas de texto simple son mucho menos seguras, pero su implementación es más económica (pero debe evitarse). Al final del día, se trata de un análisis de costo / beneficio de un incumplimiento. Usted implementa la seguridad basada en el valor de los datos que se están asegurando y su valor en el tiempo.

¿Cuál es el costo de que la contraseña de alguien salga a la naturaleza? ¿Cuál es el costo de la suplantación en el sistema dado? Para las computadoras del FBI, el costo podría ser enorme. Para el sitio web único de cinco páginas de Bob, el costo podría ser insignificante. Un profesional ofrece opciones a sus clientes y, cuando se trata de seguridad, establece las ventajas y los riesgos de cualquier implementación. Esto es doblemente así si el cliente solicita algo que podría ponerlos en riesgo por no prestar atención a los estándares de la industria. Si un cliente solicita específicamente un cifrado bidireccional, me aseguraría de documentar sus objeciones, pero eso no debería impedirle implementar de la mejor manera que sabe. Al final del día, es el dinero del cliente. Sí, debes presionar para usar hashes de una sola vía, pero decir que es absolutamente la única opción y que cualquier otra cosa que no sea ética es un completo disparate.

Si está almacenando contraseñas con cifrado bidireccional, la seguridad se reduce a la administración de claves. Windows proporciona mecanismos para restringir el acceso a certificados de claves privadas a cuentas administrativas y con contraseñas. Si está alojando en otra plataforma, debería ver qué opciones tiene disponibles en ellas. Como otros han sugerido, puede utilizar el cifrado asimétrico.

No hay ninguna ley (ni la Ley de Protección de Datos en el Reino Unido) de la cual yo sepa que específicamente las contraseñas deben almacenarse utilizando hashes de una sola vía. El único requisito en cualquiera de estas leyes es simplemente que se tomen medidas razonables para la seguridad. Si el acceso a la base de datos está restringido, incluso las contraseñas de texto sin formato pueden calificar legalmente bajo tal restricción.

Sin embargo, esto trae a la luz un aspecto más: la precedencia legal. Si la precedencia legal sugiere que debe usar hashes de una sola vía, dado que la industria en la que se está construyendo su sistema, eso es completamente diferente. Esa es la munición que utiliza para convencer a su cliente. De no ser así, la mejor sugerencia es proporcionar una evaluación de riesgo razonable, documentar sus objeciones e implementar el sistema de la manera más segura que pueda, teniendo en cuenta los requisitos del cliente.

Creo que la verdadera pregunta que debería hacerse es: ''¿Cómo puedo ser mejor para convencer a la gente?''

De acuerdo con el comentario que hice sobre la pregunta:
Un punto importante ha sido muy pasado por alto por casi todos ... Mi reacción inicial fue muy similar a @Michael Brooks, hasta que me di cuenta, como @stefanw, que el problema aquí son los requisitos rotos, pero estos son lo que son.
Pero entonces, ¡se me ocurrió que tal vez ni siquiera fuera el caso! El punto que falta aquí es el valor tácito de los activos de la aplicación. En pocas palabras, para un sistema de bajo valor, un mecanismo de autenticación completamente seguro, con todo el proceso involucrado, sería una exageración y una elección de seguridad incorrecta .
Obviamente, para un banco, las "mejores prácticas" son una necesidad, y no hay manera de violar éticamente CWE-257. Pero es fácil pensar en sistemas de bajo valor donde simplemente no vale la pena (pero aún se requiere una contraseña simple).

Es importante recordar que la verdadera experiencia en seguridad consiste en encontrar compensaciones adecuadas, NO en difundir dogmáticamente las "Mejores Prácticas" que cualquiera puede leer en línea.

Como tal, sugiero otra solución:
Dependiendo del valor del sistema, y SOLAMENTE SI el sistema tiene un valor bajo adecuado sin un activo "costoso" (la identidad en sí, incluida), Y hay requisitos comerciales válidos que hacen imposible el proceso adecuado (o lo suficientemente difícil / costoso) , Y el cliente se da cuenta de todas las advertencias ...
Entonces podría ser apropiado simplemente permitir el cifrado reversible, sin aros especiales para saltar.
No paro de decir que no me moleste en absoluto con el cifrado, porque es muy simple / barato de implementar (incluso considerando la administración de claves pasables) y SÍ proporciona protección ALGUNA (más que el costo de implementación). Además, vale la pena ver cómo proporcionar al usuario la contraseña original, ya sea por correo electrónico, en la pantalla, etc.
Dado que aquí se supone que el valor de la contraseña robada (incluso en conjunto) es bastante bajo, cualquiera de estas soluciones puede ser válida.

Ya que se está llevando a cabo una animada discusión, en realidad VARIAS discusiones animadas, en las diferentes publicaciones y en los hilos de comentarios por separado, agregaré algunas aclaraciones y responderé a algunos de los muy buenos puntos que se han mencionado en otra parte aquí.

Para empezar, creo que está claro para todos los presentes que permitir que se recupere la contraseña original del usuario, es una mala práctica y, en general, no es una buena idea. Eso no está en absoluto en disputa ...
Además, enfatizaré que en muchas, no en la mayoría de las situaciones, es realmente incorrecto, incluso asqueroso, desagradable Y feo .

Sin embargo, el quid de la cuestión está en torno al principio : ¿Existe alguna situación en la que no sea necesario prohibirlo? En caso afirmativo, cómo hacerlo de la manera más adecuada y apropiada para la situación .

Ahora, como mencionaron @Thomas, @sfussenegger y algunos otros, la única forma adecuada de responder a esa pregunta es hacer un análisis de riesgo exhaustivo de cualquier situación dada (o hipotética), para entender qué está en juego, cuánto vale proteger. , y qué otras mitigaciones están en juego para pagar esa protección.
No, NO es una palabra de moda, esta es una de las herramientas básicas y más importantes para un profesional de la seguridad en tiempo real. Las mejores prácticas son buenas hasta cierto punto (generalmente como pautas para los inexpertos y los piratas informáticos), después de ese momento se realiza un análisis cuidadoso del riesgo.

Ya sabes, es gracioso: siempre me consideré uno de los fanáticos de la seguridad, y de alguna manera estoy en el lado opuesto de los llamados "Expertos en Seguridad" ... Bueno, la verdad es que, porque soy un fanático, y un verdadero experto en seguridad de la vida real: no creo que se derive el dogma de "Mejores Prácticas" (o CWE, por sus siglas en inglés) SIN ese tan importante análisis de riesgo .
"Tenga cuidado con el fanático de la seguridad que se apresura a aplicar todo en su cinturón de herramientas sin saber cuál es el problema real contra el que están defendiendo. Más seguridad no necesariamente equivale a una buena seguridad".
El análisis de riesgo, y los verdaderos fanáticos de la seguridad, apuntarían a una compensación más inteligente, basada en el valor / riesgo, basada en el riesgo, la pérdida potencial, las posibles amenazas, las mitigaciones complementarias, etc. Cualquier "experto en seguridad" que no pueda apuntar a un análisis de riesgo sólido como el La base de sus recomendaciones, o el apoyo a las compensaciones lógicas, pero en su lugar preferiría escatimar dogma y CWE sin siquiera comprender cómo realizar un análisis de riesgo, no son más que trucos de seguridad, y su pericia no vale la pena en el papel higiénico en el que lo imprimieron.

De hecho, así es como conseguimos la ridiculez que es la seguridad del aeropuerto.

Pero antes de hablar sobre las compensaciones apropiadas que se deben hacer en ESTA SITUACIÓN, echemos un vistazo a los riesgos aparentes (aparente, porque no tenemos toda la información de fondo sobre esta situación, todos estamos planteando hipótesis, ya que la pregunta es qué hipotética situación podría haber ...)
Asumamos un sistema de BAJO VALOR, pero no tan importante como su acceso público: el propietario del sistema desea evitar la suplantación casual, pero la seguridad "alta" no es tan importante como la facilidad de uso. (Sí, es una compensación legítima para ACEPTAR el riesgo de que cualquier script-kiddie competente pueda piratear el sitio ... Espera, ¿no está APT en boga ahora ...?)
Solo por ejemplo, digamos que estoy organizando un sitio sencillo para una gran reunión familiar, permitiendo a todos hacer una lluvia de ideas sobre a dónde queremos ir en nuestro viaje de campamento este año. Me preocupa menos que un pirata informático anónimo, o incluso el primo Fred, sugiera repetidas sugerencias para volver al lago Wantanamanabikiliki, ya que me refiero a que la tía Erma no puede iniciar sesión cuando lo necesita. Ahora, la tía Erma, siendo física nuclear, no es muy buena para recordar contraseñas, o incluso para usar computadoras ... Así que quiero eliminar todas las fricciones posibles para ella. Una vez más, NO estoy preocupado por los hacks, simplemente no quiero errores tontos de inicio de sesión incorrecto; quiero saber quién viene y qué quieren.

De todas formas.
¿Cuáles son nuestros principales riesgos aquí, si ciframos de forma simétrica las contraseñas, en lugar de utilizar un hash de una sola vía?

¿Hacerse pasar por usuarios? No, ya he aceptado ese riesgo, no es interesante.
Administrador del mal? Bueno, quizás ... Pero una vez más, no me importa si alguien puede hacerse pasar por otro usuario, INTERNO o no ... y, de todos modos, un administrador malintencionado obtendrá su contraseña sin importar qué . Si su administrador se ha echado a perder, el juego ya terminó.
Otro problema que se ha planteado es que la identidad se comparte entre varios sistemas. Ah! Este es un riesgo muy interesante, que requiere una mirada más cercana.
Permítanme comenzar afirmando que no se comparte la identidad real, sino la prueba o la credencial de autenticación. De acuerdo, ya que una contraseña compartida me permitirá ingresar a otro sistema (por ejemplo, mi cuenta bancaria o gmail), esta es efectivamente la misma identidad, así que es solo semántica ... Excepto que no lo es . La identidad es administrada por separado por cada sistema, en este escenario (aunque podría haber sistemas de identificación de terceros, como OAuth, aún así, está separado de la identidad en este sistema, más adelante veremos esto).
Como tal, el punto central de riesgo aquí es que el usuario ingresará voluntariamente su (misma) contraseña en varios sistemas diferentes, y ahora, yo (el administrador) o cualquier otro pirata informático de mi sitio tendré acceso a las contraseñas de la tía Erma para El sitio del misil nuclear.

Hmmm

¿Hay algo aquí que te parezca?

Debería.

Comencemos con el hecho de que la protección del sistema de misiles nucleares no es mi responsabilidad , solo estoy construyendo un sitio de salida de la familia Frakkin (para MI familia). Entonces, ¿de quién es la responsabilidad? Umm ... ¿Qué tal el sistema de misiles nucleares? Duh
En segundo lugar, si quisiera robar la contraseña de alguien (alguien que se sabe que usa repetidamente la misma contraseña entre sitios seguros y no tan seguros), ¿por qué me molestaría en piratear su sitio? ¿O luchando con tu cifrado simétrico? Goshdarnitall, solo puedo crear mi propio sitio web , hacer que los usuarios se registren para recibir NOTICIAS MUY IMPORTANTES sobre lo que quieran ... Puffo Presto, "robé" sus contraseñas.

Sí, la educación del usuario siempre vuelve a mordernos en la comunidad, ¿no es así?
Y no hay nada que puedas hacer al respecto ... Incluso si FUERAS a codificar sus contraseñas en tu sitio, y hacer todo lo que la TSA pueda imaginar, agregaste protección a su contraseña NO UN BLANCO , si van a seguir pegando de forma promiscua sus contraseñas en cada sitio al que se topan. No te molestes en intentarlo.

Dicho de otra manera, usted no posee sus contraseñas , así que deje de tratar de actuar como lo hace usted.

Entonces, mis Estimados Expertos en Seguridad, como una anciana solía preguntar por Wendy''s, "¿Dónde está el riesgo?"

Otros pocos puntos, en respuesta a algunas cuestiones planteadas anteriormente:

CWE no es una ley, un reglamento, ni siquiera una norma. Es una colección de debilidades comunes , es decir, la inversa de "Mejores Prácticas".
El problema de la identidad compartida es un problema real, pero mal entendido (o tergiversado) por los detractores aquí. Se trata de compartir la identidad en sí misma (!), NO de descifrar las contraseñas en sistemas de bajo valor. Si está compartiendo una contraseña entre un sistema de bajo valor y uno de alto valor, ¡el problema ya está ahí!
Por cierto, el punto anterior en realidad apuntaría CONTRA el uso de OAuth y similares para estos sistemas de bajo valor y los sistemas bancarios de alto valor.
Sé que fue solo un ejemplo, pero (lamentablemente) los sistemas del FBI no son realmente los más seguros. No como los servidores del blog de tu gato, pero tampoco superan a algunos de los bancos más seguros.
El conocimiento dividido, o el control doble, de las claves de cifrado NO se producen solo en el ejército, de hecho, PCI-DSS ahora requiere esto de prácticamente todos los comerciantes, por lo que ya no está tan lejos (SI el valor lo justifica).
Para todos aquellos que se quejan de que preguntas como estas son las que hacen que la profesión de desarrollador se vea tan mal: son respuestas como esas, que hacen que la profesión de seguridad se vea aún peor. Una vez más, lo que se requiere es un análisis de riesgo centrado en el negocio, de lo contrario, se volverá inútil. Además de estar equivocado.
Supongo que esta es la razón por la que no es una buena idea tomar un desarrollador regular y dejarle más responsabilidades de seguridad, sin capacitación para pensar de manera diferente y buscar las compensaciones correctas. Sin ofender, para aquellos de ustedes que están aquí, estoy totalmente a favor, pero se necesita más entrenamiento.

Uf. Que largo post ...
Pero para responder a tu pregunta original, @Shane:

Explique al cliente la forma correcta de hacer las cosas.
Si todavía insiste, explique un poco más, insista, discuta. Lanzar una rabieta, si es necesario.
Explícale el RIESGO DE NEGOCIO a él. Los detalles son buenos, las cifras son mejores, una demostración en vivo suele ser mejor.
SI AÚN insiste, Y presenta razones comerciales válidas, es hora de que realice un llamado de juicio:
¿Es este sitio de bajo a ningún valor? ¿Es realmente un caso de negocio válido? ¿Es lo suficientemente bueno para ti? ¿No hay otros riesgos que pueda considerar, que serían mayores que las razones comerciales válidas? (Y, por supuesto, el cliente NO es un sitio malicioso, pero eso es duh).
Si es así, sigue adelante. No vale la pena el esfuerzo, la fricción y la pérdida de uso (en esta situación hipotética) para implementar el proceso necesario. Cualquier otra decisión (de nuevo, en esta situación) es una mala compensación.

Entonces, el resultado final, y una respuesta real: cifrarlo con un algoritmo simétrico simple, proteger la clave de cifrado con ACL fuertes y preferiblemente DPAPI o similar, documentar y hacer que el cliente (alguien lo suficientemente avanzado para tomar esa decisión) firme eso.

Después de leer esta parte:

En una nota a continuación, señalé que los sitios web orientados en gran medida hacia las personas mayores, con problemas mentales o muy jóvenes pueden llegar a ser confusos para las personas cuando se les pide que realicen una rutina de recuperación de contraseña segura. Aunque es posible que nos resulte sencillo y mundano, en esos casos, algunos usuarios necesitan la ayuda adicional de contar con un técnico de servicio que los ayude a ingresar al sistema o que se los envíen por correo electrónico o se los muestren directamente.
En tales sistemas, la tasa de desgaste de estos datos demográficos podría entorpecer la aplicación si los usuarios no recibieran este nivel de asistencia de acceso, así que responda con esta configuración en mente.

Me pregunto si alguno de estos requisitos exige un sistema de contraseña recuperable. Por ejemplo: la tía Mabel llama y dice "Tu programa de Internet no funciona, no sé mi contraseña". "OK" dice que el dron de servicio al cliente "me permite verificar algunos detalles y luego le daré una nueva contraseña . La próxima vez que inicie sesión, le preguntará si desea conservar esa contraseña o cambiarla por algo que pueda recordar. más fácilmente."

Luego, el sistema está configurado para saber cuándo ha ocurrido un restablecimiento de la contraseña y mostrar un mensaje "le gustaría conservar la nueva contraseña o elegir una nueva".

¿Cómo es esto peor para los que tienen menos conocimientos de PC que cuando se les dice su contraseña anterior? Y mientras que la persona de servicio al cliente puede hacer daño, la base de datos en sí misma es mucho más segura en caso de que sea violada.

Comenta lo que está mal con mi sugerencia y sugeriré una solución que realmente haga lo que inicialmente quisiste.

Ha habido mucha discusión sobre las preocupaciones de seguridad para el usuario en respuesta a esta pregunta, pero me gustaría agregar una mención de los beneficios. Hasta ahora, no he visto un beneficio legítimo mencionado por tener una contraseña recuperable almacenada en el sistema. Considera esto:

¿Se beneficia el usuario de recibir su contraseña por correo electrónico? No. Reciben más beneficios de un enlace de restablecimiento de contraseña de un solo uso, que se espera que les permita elegir una contraseña que recordarán.
¿Se beneficia el usuario de tener su contraseña mostrada en la pantalla? No, por el mismo motivo que el anterior; Deben elegir una nueva contraseña.
¿Se beneficia el usuario de tener una persona de apoyo para decirle la contraseña al usuario? No; de nuevo, si la persona de soporte considera que la solicitud del usuario de su contraseña está debidamente autenticada, es más beneficioso para el usuario recibir una nueva contraseña y la oportunidad de cambiarla. Además, la asistencia telefónica es más costosa que el restablecimiento automático de contraseñas, por lo que la empresa tampoco se beneficia.

Parece que los únicos que pueden beneficiarse de las contraseñas recuperables son aquellos con intenciones maliciosas o partidarios de API deficientes que requieren el intercambio de contraseñas de terceros (¡por favor, no use dichas API nunca!). Quizás pueda ganar su argumento afirmando con sinceridad a sus clientes que la empresa no obtiene beneficios y solo responsabilidades al almacenar contraseñas recuperables .

Leyendo entre las líneas de este tipo de solicitudes, verá que sus clientes probablemente no entienden o incluso se preocupan en absoluto sobre cómo se administran las contraseñas. Lo que realmente quieren es un sistema de autenticación que no sea tan difícil para sus usuarios. Por lo tanto, además de decirles que en realidad no desean contraseñas recuperables, debe ofrecerles maneras de hacer que el proceso de autenticación sea menos doloroso, especialmente si no necesita los altos niveles de seguridad de, por ejemplo, un banco:

Permitir al usuario utilizar su dirección de correo electrónico para su nombre de usuario. He visto innumerables casos en los que el usuario olvida su nombre de usuario, pero pocos olvidan su dirección de correo electrónico.
Ofrezca OpenID y deje que un tercero pague los costos del olvido del usuario.
Facilitar las restricciones de contraseña. Estoy seguro de que todos hemos estado increíblemente molestos cuando algún sitio web no permite su contraseña preferida debido a requisitos inútiles como "no puede usar caracteres especiales" o "su contraseña es demasiado larga" o "su contraseña debe comenzar con una letra ". Además, si la facilidad de uso es una preocupación mayor que la seguridad de la contraseña, puede aflojar incluso los requisitos no estúpidos al permitir contraseñas más cortas o no requerir una combinación de clases de caracteres. Con restricciones aflojadas, es más probable que los usuarios usen una contraseña que no olvidarán.
No caduquen las contraseñas.
Permitir al usuario reutilizar una contraseña antigua.
Permitir al usuario elegir su propia pregunta de restablecimiento de contraseña.

Pero si, por alguna razón (y por favor díganos la razón) realmente, realmente, realmente necesita poder tener una contraseña recuperable, podría proteger al usuario de poner en peligro sus otras cuentas en línea dándoles una contraseña sin contraseña. sistema de autentificación basado. Debido a que las personas ya están familiarizadas con los sistemas de nombre de usuario / contraseña y son una solución bien ejercitada, este sería un último recurso, pero seguramente hay muchas alternativas creativas a las contraseñas:

Permita que el usuario elija un pin numérico, preferiblemente no de 4 dígitos, y preferiblemente solo si los intentos de fuerza bruta están protegidos.
Haga que el usuario elija una pregunta con una respuesta corta a la que solo ellos conocen la respuesta, que nunca cambiará, que siempre recordarán y que no les importa que otras personas lo descubran.
Haga que el usuario ingrese un nombre de usuario y luego dibuje una forma fácil de recordar con las permutaciones suficientes para protegerse contra las suposiciones (vea esta ingeniosa foto de cómo G1 hace esto para desbloquear el teléfono).
Para el sitio web de un niño, puede generar automáticamente una criatura difusa basada en el nombre de usuario (algo así como un identicon) y pedirle al usuario que le dé un nombre secreto a la criatura. Se les puede pedir que ingresen el nombre secreto de la criatura para iniciar sesión.

Haga que la respuesta a la pregunta de seguridad del usuario forme parte de la clave de cifrado, y no almacene la respuesta de la pregunta de seguridad como texto simple (hash que en su lugar)

Imagine que alguien ha encargado que se construya un gran edificio, digamos, un bar, y que tenga lugar la siguiente conversación:

Arquitecto: Para un edificio de este tamaño y capacidad, necesitará salidas de incendios aquí, aquí y aquí.
Cliente: No, eso es demasiado complicado y costoso de mantener, no quiero puertas laterales ni puertas traseras.
Arquitecto: Señor, las salidas de emergencia no son opcionales, se requieren según el código de incendios de la ciudad.
Cliente: No te pago por discutir. Sólo haz lo que te pedí.

¿Luego el arquitecto pregunta cómo construir éticamente este edificio sin salidas de emergencia?

En la industria de la construcción y la ingeniería, la conversación es más probable que termine así:

Arquitecto: Este edificio no puede construirse sin salidas de incendio. Puedes acudir a cualquier otro profesional con licencia y él te dirá lo mismo. Me voy ahora; Llámame cuando estés listo para cooperar.

La programación de computadoras puede no ser una profesión con licencia , pero la gente a menudo parece preguntarse por qué nuestra profesión no recibe el mismo respeto que un ingeniero civil o mecánico, bueno, no busque más. Esas profesiones, cuando se les entregan requisitos de basura (o simplemente peligrosos), simplemente se rechazarán. Saben que no es una excusa para decir, "bueno, hice todo lo que pude, pero él insistió, y tengo que hacer lo que dice". Podrían perder su licencia por esa excusa.

No sé si usted o sus clientes forman parte de una empresa que cotiza en bolsa, pero el almacenamiento de contraseñas en cualquier forma recuperable causaría la falla de varios tipos diferentes de auditorías de seguridad. El problema no es lo difícil que sería para algunos "hackers" que obtuvieron acceso a su base de datos para recuperar las contraseñas. La gran mayoría de las amenazas de seguridad son internas. De lo que debe protegerse es contra un empleado descontento que se va con todas las contraseñas y las vende al mejor postor. El uso del cifrado asimétrico y el almacenamiento de la clave privada en una base de datos separada no hace absolutamente nada para evitar este escenario; Siempre habrá alguien con acceso a la base de datos privada, y eso es un grave riesgo para la seguridad.

No existe una forma ética o responsable de almacenar contraseñas de forma recuperable. Período.

La única forma de permitir que un usuario recupere su contraseña original, es cifrarla con su propia clave pública. Sólo ese usuario puede descifrar su contraseña.

Así que los pasos serían:

El usuario se registra en su sitio (a través de SSL, por supuesto) sin establecer una contraseña. Inicia sesión automáticamente o proporciona una contraseña temporal.
Usted ofrece almacenar su clave PGP pública para la futura recuperación de contraseña.
Suben su clave pública de PGP.
Les pides que establezcan una nueva contraseña.
Ellos envían su contraseña.
Hashea la contraseña utilizando el mejor algoritmo de hashing de contraseña disponible (por ejemplo, bcrypt). Use esto cuando valide el siguiente inicio de sesión.
Cifras la contraseña con la clave pública y la guardas por separado.

En caso de que el usuario le pida su contraseña, usted responde con la contraseña cifrada (no hash). Si el usuario no desea poder recuperar su contraseña en el futuro (solo podría restablecerla a una generada por el servicio), los pasos 3 y 7 se pueden omitir.

Lo sentimos, pero mientras tengas alguna forma de descifrar su contraseña, no hay forma de que sea segura. Lucha amargamente, y si pierdes, CYA.

Manejo de contraseñas perdidas / olvidadas:

Nadie debería poder recuperar contraseñas.

Si los usuarios olvidaron sus contraseñas, al menos deben saber sus nombres de usuario o direcciones de correo electrónico. Cuando lo solicite, genere un GUID en la tabla de Usuarios y envíe un correo electrónico que contenga un enlace que contenga el GUID como parámetro a la dirección de correo electrónico del usuario.

La página detrás del enlace verifica que el parámetro guid realmente existe (probablemente con alguna lógica de tiempo de espera) y le pide al usuario una nueva contraseña.

Si necesita que los usuarios de la línea directa lo ayuden, agregue algunas funciones a su modelo de subvenciones y permita que la línea directa ingrese temporalmente como usuario identificado. Registre todos estos inicios de sesión de línea directa. Por ejemplo, Bugzilla ofrece esta función de suplantación de identidad a los administradores.

Michael Brooks ha hablado bastante acerca de CWE-257: el hecho de que sea cual sea el método que utilice, usted (el administrador) aún puede recuperar la contraseña. Entonces, ¿qué hay de estas opciones:

Cifre la contraseña con la clave pública de otra persona, alguna autoridad externa. De esa manera, no podrá reconstruirlo personalmente, y el usuario tendrá que acudir a esa autoridad externa y solicitar que se recupere su contraseña.
Cifre la contraseña utilizando una clave generada a partir de una segunda frase de contraseña. Realice este cifrado del lado del cliente y nunca lo transmita de forma clara al servidor. Luego, para recuperar, vuelva a descifrar el lado del cliente volviendo a generar la clave desde su entrada. Es cierto que este enfoque consiste básicamente en utilizar una segunda contraseña, pero siempre puede pedirles que lo escriban o que utilicen el antiguo enfoque de preguntas de seguridad.

Creo que 1. es la mejor opción, ya que le permite designar a alguien dentro de la empresa del cliente para que tenga la clave privada. Asegúrese de que ellos mismos generen la clave, y guárdela con las instrucciones en una caja fuerte, etc. Incluso podría agregar seguridad al elegir solo cifrar y suministrar ciertos caracteres de la contraseña al tercero interno para que tengan que descifrar la contraseña para adivinar eso. Proporcionando estos caracteres al usuario, ¡probablemente recordarán lo que era!

No se pueden almacenar contraseñas éticamente para la recuperación posterior de texto sin formato. Es tan simple como eso. Incluso Jon Skeet no puede almacenar contraseñas éticamente para su posterior recuperación de texto simple. Si sus usuarios pueden recuperar contraseñas en texto sin formato de alguna manera u otra, entonces también lo puede hacer un pirata informático que encuentra una vulnerabilidad de seguridad en su código. Y esa no es solo la contraseña de un usuario comprometida, sino todas ellas.

Si sus clientes tienen un problema con eso, dígales que almacenar las contraseñas de forma recuperable es ilegal. En cualquier caso, en el Reino Unido, la Ley de protección de datos de 1998 (en particular, el Anexo 1, Parte II, Párrafo 9) requiere que los controladores de datos utilicen las medidas técnicas adecuadas para mantener seguros los datos personales, teniendo en cuenta, entre otras cosas, el daño que podría causarse si los datos estuvieran comprometidos, lo que podría ser considerable para los usuarios que comparten contraseñas entre sitios. Si aún tienen problemas para asimilar el hecho de que es un problema, apúntelos a algunos ejemplos del mundo real, como este .

La forma más sencilla de permitir a los usuarios recuperar un inicio de sesión es enviarles por correo electrónico un enlace de una sola vez que los inicia de forma automática y los lleva directamente a una página donde pueden elegir una nueva contraseña. Crea un prototipo y muéstralo en acción a ellos.

Aquí hay un par de publicaciones del blog que escribí sobre el tema:

Actualización: ahora estamos empezando a ver juicios y juicios contra compañías que no logran asegurar las contraseñas de sus usuarios correctamente. Ejemplo: LinkedIn abofeteó con $ 5 millones demanda colectiva ; Sony multó con £ 250,000 por piratear datos de PlayStation . Si recuerdo correctamente, LinkedIn estaba realmente cifrando las contraseñas de sus usuarios, pero el cifrado que estaba usando era demasiado débil para ser efectivo.

No te rindas El arma que puedes usar para convencer a tus clientes es que no es repudiable. Si puede reconstruir las contraseñas de los usuarios a través de cualquier mecanismo, le ha otorgado a sus clientes un mecanismo legal de no repudio y ellos pueden repudiar cualquier transacción que dependa de esa contraseña, porque no hay forma de que el proveedor pueda probar que no reconstruyó la contraseña. y poner la transacción a través de ellos mismos. Si las contraseñas se almacenan correctamente como compendios en lugar de texto cifrado, esto es imposible, ya sea que el cliente final ejecutó la transacción por sí mismo o incumplió su deber de cuidado con la contraseña. En cualquier caso, eso deja la responsabilidad directamente con él. He trabajado en casos en que eso equivaldría a cientos de millones de dólares. No es algo que quieras equivocarte.

Otra opción que quizás no hayas considerado es permitir acciones por correo electrónico. Es un poco engorroso, pero implementé esto para un cliente que necesitaba a los usuarios "fuera" de su sistema para ver (solo lectura) ciertas partes del sistema. Por ejemplo:

Una vez que un usuario está registrado, tiene acceso completo (como un sitio web normal). La inscripción debe incluir un correo electrónico.
Si se necesitan datos o una acción y el usuario no recuerda su contraseña, aún puede realizar la acción haciendo clic en el botón especial " Enviarme un correo electrónico para solicitar permiso ", justo al lado del botón " Enviar ".
Luego, la solicitud se envía al correo electrónico con un hipervínculo que pregunta si desean que se realice la acción. Esto es similar a un enlace de correo electrónico de restablecimiento de contraseña, pero en lugar de restablecer la contraseña, realiza la acción de una sola vez .
Luego, el usuario hace clic en "Sí" y confirma que los datos deben mostrarse, o la acción debe realizarse, los datos revelados, etc.

Como mencionó en los comentarios, esto no funcionará si el correo electrónico se ve comprometido, pero aborda el comentario de @joachim acerca de no querer restablecer la contraseña. Eventualmente, tendrían que usar el restablecimiento de la contraseña, pero podrían hacerlo en un momento más conveniente, o con la ayuda de un administrador o amigo, según sea necesario.

Un giro a esta solución sería enviar la solicitud de acción a un administrador de confianza de terceros. Esto funcionaría mejor en casos con usuarios mayores, con problemas mentales, muy jóvenes o confundidos. Por supuesto, esto requiere un administrador confiable para que estas personas apoyen sus acciones.

Podrías encriptar la contraseña + un salt con una clave pública. Para los inicios de sesión, simplemente compruebe si el valor almacenado es igual al valor calculado a partir de la entrada del usuario + sal. Si llega un momento en que la contraseña debe restaurarse en texto sin formato, puede descifrar de forma manual o semiautomática con la clave privada. La clave privada puede almacenarse en otro lugar y, además, puede cifrarse simétricamente (lo que requerirá una interacción humana para descifrar la contraseña).

Creo que esto es realmente similar a la forma en que funciona el Agente de recuperación de Windows .

Las contraseñas se almacenan encriptadas.
Las personas pueden iniciar sesión sin descifrar a texto sin formato
Las contraseñas se pueden recuperar a texto sin formato, pero solo con una clave privada, que se puede almacenar fuera del sistema (en una caja fuerte del banco, si lo desea).

Por lo poco que entiendo sobre este tema, creo que si está creando un sitio web con un inicio de sesión / contraseña, entonces ni siquiera debería ver la contraseña de texto simple en su servidor. La contraseña debe estar con hash, y probablemente con sal, antes de que salga del cliente.

Si nunca ve la contraseña de texto simple, entonces no surge la pregunta de recuperación.

Además, recojo (de la web) que (supuestamente) algunos algoritmos como MD5 ya no se consideran seguros. No tengo forma de juzgar eso por mí mismo, pero es algo a tener en cuenta.

Sal y hash la contraseña del usuario como de costumbre. Cuando inicie sesión en el usuario, permita tanto la contraseña del usuario (después de utilizar sal / hashing), pero también permita que el usuario que ingresa literalmente también coincida.

Esto le permite al usuario ingresar su contraseña secreta, pero también le permite ingresar la versión con sal / hash de su contraseña, que es lo que alguien leería de la base de datos.

Básicamente, haga que la contraseña con sal / hash sea también una contraseña de "texto simple".

Si no puede simplemente rechazar el requisito de almacenar contraseñas recuperables, ¿qué le parece esto como su contra argumento?

Podemos ya sea hash correctamente las contraseñas y construir un mecanismo de restablecimiento para los usuarios, o podemos eliminar toda la información de identificación personal del sistema. Puedes usar una dirección de correo electrónico para configurar las preferencias del usuario, pero eso es todo. Utilice una cookie para extraer automáticamente las preferencias en futuras visitas y desechar los datos después de un período razonable.

La única opción que a menudo se pasa por alto con la política de contraseña es si realmente se necesita una contraseña. Si lo único que hace su política de contraseña es causar llamadas al servicio al cliente, tal vez pueda deshacerse de ella.

Tengo el mismo problema. Y de la misma manera, siempre pienso que alguien hackea mi sistema, no es una cuestión de "si" sino de "cuándo".

Entonces, cuando debo hacer un sitio web que necesite almacenar una información confidencial recuperable, como una tarjeta de crédito o una contraseña, lo que hago es:

cifrar con: openssl_encrypt (cadena $ datos, cadena $ método, cadena $ contraseña)
- Manual de PHP .
datos arg :
- la información sensible (por ejemplo, la contraseña del usuario)
- serialice si es necesario, por ejemplo, si la información es una matriz de datos como información múltiple sensible
contraseña arg : use una información que solo el usuario conozca como:
- la matrícula del usuario
- Número de seguridad social
- número de teléfono del usuario
- el nombre de la madre del usuario
- una cadena aleatoria enviada por correo electrónico y / o por SMS al momento del registro
método arg :
- Elija un método de cifrado, como "aes-256-cbc"
NUNCA almacene la información utilizada en el argumento de "contraseña" en la base de datos (o en cualquier lugar del sistema)

Cuando sea necesario para recuperar estos datos, simplemente use la función "openssl_decrypt ()" y solicite la respuesta al usuario. Ej .: "Para recibir su contraseña, responda la pregunta: ¿Cuál es su número de teléfono celular?"

PS 1 : nunca use como contraseña los datos almacenados en la base de datos. Si necesita almacenar el número de teléfono móvil del usuario, nunca use esta información para codificar los datos. Siempre use una información que solo el usuario conozca o que sea difícil para alguien que no es familiar.

PS 2 : para información de tarjeta de crédito, como "comprar con un clic", lo que hago es usar la contraseña de inicio de sesión. Esta contraseña está en la base de datos (sha1, md5, etc.), pero en el momento del inicio de sesión almaceno la contraseña de texto sin formato en una sesión o en una cookie segura no persistente (es decir, en la memoria). Esta contraseña simple nunca permanece en la base de datos, de hecho siempre permanece en la memoria, se destruye al final de la sección. Cuando el usuario hace clic en el botón "comprar con un solo clic", el sistema usa esta contraseña. Si el usuario inició sesión con un servicio como Facebook, Twitter, etc., le pido la contraseña nuevamente en el momento de la compra (está bien, no es un "clic") o luego uso algunos datos del servicio que el usuario usó para iniciar sesión. (como el id de facebook).

abra una base de datos en un servidor independiente y proporcione una conexión remota encriptada a cada servidor web que requiera esta función.
no tiene que ser una base de datos relacional, puede ser un sistema de archivos con acceso a FTP, utilizando carpetas y archivos en lugar de tablas y filas.
dar a los servidores web permisos de solo escritura si es posible.

Almacene el cifrado no recuperable de la contraseña en la base de datos del sitio (llamémoslo "pass-a") como lo hace la gente normal :)
en cada nuevo usuario (o cambio de contraseña) almacene una copia simple de la contraseña en la base de datos remota. use la identificación del servidor, la identificación del usuario y "pass-a" como clave compuesta para esta contraseña. Incluso puede utilizar un cifrado bidireccional en la contraseña para dormir mejor por la noche.

ahora para que alguien pueda obtener tanto la contraseña como su contexto (id de sitio + id de usuario + "pass-a"), tiene que:

hackear la base de datos del sitio web para obtener un par o pares ("pass-a", id de usuario).
obtener la identificación del sitio web de algún archivo de configuración
encontrar y hackear la contraseña remota DB.

puede controlar la accesibilidad del servicio de recuperación de contraseñas (expóngalo solo como un servicio web seguro, permita solo una cantidad determinada de recuperaciones de contraseñas por día, hágalo manualmente, etc.) e incluso cargue un extra por este "acuerdo de seguridad especial".
El servidor de base de datos de recuperación de contraseñas está bastante oculto, ya que no tiene muchas funciones y se puede proteger mejor (se pueden personalizar los permisos, los procesos y los servicios).

Con todo, haces el trabajo más difícil para el hacker. la posibilidad de una brecha de seguridad en cualquier servidor individual sigue siendo la misma, pero será difícil reunir datos significativos (una combinación de cuenta y contraseña).

Implemento sistemas de autenticación de múltiples factores para la vida, por lo que para mí es natural pensar que puede restablecer o reconstruir la contraseña, mientras usa temporalmente un factor menos para autenticar al usuario solo para el flujo de trabajo de restablecimiento / recreación. En particular, el uso de OTP (contraseñas de un solo uso) como algunos de los factores adicionales, mitiga gran parte del riesgo si la ventana de tiempo es corta para el flujo de trabajo sugerido. Hemos implementado generadores de software OTP para teléfonos inteligentes (que la mayoría de los usuarios ya llevan consigo todo el día) con gran éxito. Antes de que aparezcan las quejas de un conector comercial, lo que digo es que podemos reducir los riesgos inherentes de mantener las contraseñas fácilmente recuperables o restablecibles cuando no son el único factor utilizado para autenticar a un usuario. Admito que para la reutilización de la contraseña entre los escenarios de los sitios, la situación aún no es buena, ya que el usuario insistirá en tener la contraseña original porque también desea abrir los otros sitios, pero puede intentar entregar la contraseña reconstruida en La forma más segura posible (htpps y apariencia discreta en el html).