¿Cómo debería abordar éticamente el almacenamiento de contraseña de usuario para la recuperación posterior de texto sin formato?

A medida que continúo construyendo más y más sitios web y aplicaciones web, a menudo se me pide que almacene las contraseñas de los usuarios de manera que puedan recuperarse si el usuario tiene un problema (ya sea para enviar por correo electrónico un enlace de contraseña olvidado, guíelo a través del teléfono, etc.) Cuando puedo, lucho amargamente contra esta práctica y hago mucha programación 'extra' para hacer posible el restablecimiento 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 sé que si mi base de datos se piratea el culpable no tardaría mucho en descifrar las contraseñas, por lo que me siento incómodo.

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

Moral y éticamente me siento responsable de proteger lo que puede ser, para algunos usuarios, su medio de vida, incluso si lo tratan con mucho menos respeto. Estoy seguro de que hay muchas vías para abordar y argumentos para formular salsas y diferentes opciones de codificación, pero ¿hay una única 'mejor práctica' cuando tiene que almacenarlas? 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 quiera 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 usted adopta este enfoque.

En una nota a continuación, señalé que los sitios web orientados principalmente a personas mayores, con problemas mentales o muy jóvenes pueden ser confusos para las personas cuando se les pide que realicen una rutina segura de recuperación de contraseña. Aunque podemos encontrarlo simple y mundano en esos casos, algunos usuarios necesitan la ayuda adicional de tener un servicio técnico que los ayude a ingresar al sistema o que se les envíe por correo electrónico / se les muestre directamente.

En tales sistemas, la tasa de deserción de estos datos demográficos podría obstaculizar la aplicación si los usuarios no recibieran este nivel de asistencia de acceso, por lo tanto, responda teniendo en cuenta dicha configuración.

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 plano o contraseñas recuperables), pero también hace posible que la base de usuarios que especifiqué inicie sesión en un sistema sin los inconvenientes principales 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!

Además, gracias a todos en la comunidad de Stack que votaron por esta pregunta y / o la marcaron como favorita. Tomo 100 votos como un cumplido y espero que esta discusión haya ayudado a alguien más con la misma preocupación que yo.

¿Qué tal tomar otro enfoque o ángulo en este problema? Pregunte por qué se requiere que la contraseña esté en texto sin formato: si es para que el usuario pueda recuperar la contraseña, entonces, estrictamente hablando, realmente no necesita recuperar la contraseña que estableció (de todos modos, no recuerda cuál es). 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ña utilizados hoy en día es que las contraseñas generadas producidas en una operación de restablecimiento generalmente son un montón de caracteres aleatorios, por lo que es difícil para el usuario simplemente escribir correctamente a menos que copien pegar. Eso puede ser un problema para los usuarios de computadoras menos inteligentes.

Una forma de evitar ese problema es proporcionar contraseñas generadas automáticamente que sean texto de lenguaje más o menos 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 debe tener solo 8 (o 10 o 12) caracteres. Obtenga una frase de contraseña autogenerada de alta entropía al unir varias palabras aleatorias (deje un espacio entre ellas, de modo que puedan ser reconocibles y escribibles por cualquiera que pueda leer). Seis palabras aleatorias de longitud variable son probablemente más fáciles de escribir correctamente y con 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ían una entropía de 61.7 bits. Usando un diccionario de 7776 palabras (como Diceware usa) que podría seleccionarse aleatoriamente para una frase de contraseña de seis palabras, la frase de contraseña tendría una entropía de 77.4 bits. Ver elPreguntas frecuentes sobre Diceware para más información.

• una frase de contraseña con unos 77 bits de entropía: "admitir prosa flare table flair agudo"

• 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 tampoco, por lo 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 (lo 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 se violara el 80% de las contraseñas que uso en varios sitios web: todo lo que podría suceder es que alguien envíe spam o publique bajo mi nombre por un tiempo. Eso no sería genial, pero no es como si entraran a mi cuenta bancaria. Sin embargo, dado el hecho de que muchas personas usan la misma contraseña para sus sitios de foros web como lo hacen para sus cuentas bancarias (y probablemente bases de datos de seguridad nacional), creo que sería mejor manejar incluso esas contraseñas de "bajo valor" como no -recuperable.

Imagine que alguien ha encargado la construcción de un gran edificio, un bar, digamos, y se desarrolla la siguiente conversación:

Arquitecto: Para un edificio de este tamaño y capacidad, necesitará salidas de emergencia aquí, aquí y aquí.
Cliente: No, eso es demasiado complicado y costoso de mantener, no quiero puertas laterales o 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. Solo haz lo que te pedí.

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

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

Arquitecto: Este edificio no se puede construir sin salidas de emergencia. Puede acudir a cualquier otro profesional con licencia y él le 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 las personas a menudo parecen 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 entregan requisitos de basura (o directamente peligrosos), simplemente se negarán. Saben que no es una excusa para decir, "bueno, hice lo mejor 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 son o no parte de una empresa que cotiza en bolsa, pero el almacenamiento de contraseñas en cualquier forma recuperable podría hacer que falle varios tipos diferentes de auditorías de seguridad. El problema no es cuán difícil 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 necesita protegerse es de algún empleado descontento que se va con todas las contraseñas y las vende al mejor postor. El uso de 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 ese es un grave riesgo de seguridad.

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

Puede cifrar la contraseña + una sal con una clave pública. Para los inicios de sesión, simplemente verifique 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 descifrarla de forma manual o semiautomática con la clave privada. La clave privada se puede almacenar en otro lugar y además se puede cifrar simétricamente (lo que necesitará una interacción humana para descifrar la contraseña).

Creo que esto es 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 en texto sin formato
• Las contraseñas se pueden recuperar en texto plano, pero solo con una clave privada, que se puede almacenar fuera del sistema (en una caja fuerte del banco, si lo desea).

No te rindas El arma que puede usar para convencer a sus clientes es la no repudiabilidad. Si puede reconstruir las contraseñas de los usuarios a través de cualquier mecanismo, le ha dado a sus clientes un mecanismo legal de no repudio y pueden repudiar cualquier transacción que dependa de esa contraseña, porque no hay forma de que el proveedor pueda probar que no reconstruyeron la contraseña y pasar la transacción a través de ellos mismos. Si las contraseñas se almacenan correctamente como resúmenes en lugar de texto cifrado, esto es imposible, por lo tanto, el cliente final ejecutó la transacción él 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 los que eso equivaldría a cientos de millones de dólares. No es algo que quieras equivocarte.

No puede almacenar éticamente contraseñas para su posterior recuperación de texto sin formato. Es tan simple como eso. Incluso Jon Skeet no puede almacenar éticamente las contraseñas para su posterior recuperación de texto sin formato. Si sus usuarios pueden recuperar las contraseñas en texto plano de una forma u otra, entonces también puede hacerlo un hacker que encuentre 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 contraseñas de manera 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 apropiadas para mantener la seguridad de los datos personales, teniendo en cuenta, entre otras cosas, la daño que podría causar si se comprometieran los datos, lo que podría ser considerable para los usuarios que comparten contraseñas entre sitios. Si todavía tienen problemas para asimilar el hecho de que es un problema, indíqueles algunos ejemplos del mundo real, como este .

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

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

• http://jamesmckay.net/2009/09/if-you-are-saving-passwords-in-clear-text-you-are-probably-breaking-the-law/
• http://jamesmckay.net/2008/06/easy-login-recovery-without-compromising-security/

Actualización: ahora estamos comenzando a ver demandas y enjuiciamientos contra empresas que no pueden proteger las contraseñas de sus usuarios correctamente. Ejemplo: LinkedIn golpeó con una demanda colectiva de $ 5 millones ; Sony multó con £ 250,000 por el hack de datos de PlayStation . Si no recuerdo mal, LinkedIn en realidad estaba encriptando las contraseñas de sus usuarios, pero el cifrado que estaba usando era demasiado débil para ser efectivo.

Después de leer esta parte:

En una nota a continuación, señalé que los sitios web orientados principalmente a personas mayores, con problemas mentales o muy jóvenes pueden ser confusos para las personas cuando se les pide que realicen una rutina segura de recuperación de contraseña. Aunque podemos encontrarlo simple y mundano en esos casos, algunos usuarios necesitan la ayuda adicional de tener un servicio técnico que los ayude a ingresar al sistema o que se les envíe por correo electrónico / se les muestre directamente.

En tales sistemas, la tasa de deserción de estos datos demográficos podría obstaculizar la aplicación si los usuarios no recibieran este nivel de asistencia de acceso, por lo tanto, responda teniendo en cuenta dicha configuración.

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

Luego, el sistema se configura para saber cuándo se ha restablecido la contraseña y muestra el mensaje "desea conservar la nueva contraseña o elegir una nueva".

¿Cómo es esto peor para los menos alfabetizados en PC que recibir su contraseña anterior? Y aunque la persona de servicio al cliente puede hacer travesuras, la base de datos en sí es mucho más segura en caso de violación.

Comenta qué hay de malo en mi sugerencia y te sugeriré una solución que realmente haga lo que inicialmente quisiste.

Michael Brooks ha sido bastante expresivo sobre 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:

1. Cifre la contraseña con la clave pública de otra persona, alguna autoridad externa. De esa forma no puede reconstruirlo personalmente, y el usuario tendrá que acudir a esa autoridad externa y solicitar que se recupere su contraseña.
2. Cifre la contraseña con una clave generada a partir de una segunda frase de contraseña. Haga este cifrado en el lado del cliente y nunca lo transmita de forma clara al servidor. Luego, para recuperar, realice el descifrado del lado del cliente nuevamente al volver a generar la clave a partir de su entrada. Es cierto que este enfoque es básicamente usar una segunda contraseña, pero siempre puedes decirles que lo escriban o usar el viejo enfoque de preguntas de seguridad.

Creo que 1. es la mejor opción, porque le permite designar a alguien dentro de la empresa del cliente para que mantenga la clave privada. Asegúrese de que generen la clave ellos mismos y la almacenen con instrucciones en una caja fuerte, etc. Incluso puede agregar seguridad eligiendo encriptar y proporcionar ciertos caracteres de la contraseña al tercero interno para que tengan que descifrar la contraseña para adivinar eso. Al proporcionar estos caracteres al usuario, ¡probablemente recordarán lo que era!

Se ha discutido mucho 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. Ellos reciben más beneficios de un enlace de restablecimiento de contraseña de un solo uso, que se espera pueda permitirles elegir una contraseña que le recuerde.
• ¿Se beneficia el usuario de mostrar su contraseña en la pantalla? No, por la misma razón que arriba; deberían elegir una nueva contraseña.
• ¿Se beneficia el usuario de que una persona de soporte le diga 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 declarando sinceramente a sus clientes que la compañía no obtiene beneficios y solo responsabilidades al almacenar contraseñas recuperables .

Al leer entre líneas de este tipo de solicitudes, verá que sus clientes probablemente no entiendan o realmente no se preocupen 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. Entonces, además de decirles cómo en realidad no quieren contraseñas recuperables, debe ofrecerles formas 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:

• Permita que el usuario use 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 permita que un tercero pague los costos del olvido del usuario.
• Facilite 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 carta ". 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 más flexibles, es más probable que los usuarios usen una contraseña que no olvidarán.
• No caduque las contraseñas.
• Permitir al usuario reutilizar una contraseña anterior.
• Permita que el usuario elija su propia pregunta de restablecimiento de contraseña.

Pero si usted, 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 comprometer potencialmente sus otras cuentas en línea dándoles una contraseña no sistema de autenticació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 ejercida, este sería un último recurso, pero seguramente hay muchas alternativas creativas a las contraseñas:

• Deje 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 breve que solo ellos conozcan, nunca cambiará, siempre recordarán y no les importa que otras personas se enteren.
• Haga que el usuario ingrese un nombre de usuario y luego dibuje una forma fácil de recordar con suficientes permutaciones para protegerse contra las conjeturas (vea esta ingeniosa foto de cómo el G1 hace esto para desbloquear el teléfono).
• Para el sitio web de un niño, podrías 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. Luego se les puede solicitar que ingresen el nombre secreto de la criatura para iniciar sesión.

De acuerdo con el comentario que hice sobre la pregunta:
un punto importante ha sido muy ignorado por casi todos ... Mi reacción inicial fue muy similar a @Michael Brooks, hasta que me di cuenta, como @stefanw, de que el problema aquí es requisitos rotos , pero estos son lo que son.
Pero entonces, ¡se me ocurrió que ese podría no ser el caso! El punto que falta aquí es el valor tácito de los activos de la aplicación. Simplemente hablando, para un sistema de bajo valor, un mecanismo de autenticación completamente seguro, con todo el proceso involucrado, sería excesivo, y el error elección de seguridad .
Obviamente, para un banco, las "mejores prácticas" son imprescindibles, y no hay forma 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 se encuentra en encontrar compensaciones apropiadas, 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 SOLO SI el sistema tiene un valor apropiadamente bajo sin un activo "costoso" (la identidad en sí, incluida), Y hay requisitos comerciales válidos que hacen el proceso adecuado imposible (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.
Me estoy deteniendo antes de decir que no se moleste en absoluto con el cifrado, porque es muy simple / barato de implementar (incluso considerando una administración de claves aceptable), y proporciona ALGUNA protección (más que el costo de implementarlo). Además, vale la pena ver cómo proporcionar al usuario la contraseña original, ya sea por correo electrónico, mostrarla 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.

Dado que hay una discusión animada, en realidad VARIAS discusiones animadas, en las diferentes publicaciones y en los hilos de comentarios separados, agregaré algunas aclaraciones y responderé a algunos de los muy buenos puntos que se han planteado aquí.

Para comenzar, creo que está claro para todos aquí 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 se discute en absoluto ...
Además, enfatizaré que en muchas situaciones, más que nada, es realmente incorrecto, incluso asqueroso, desagradable y feo .

Sin embargo, el quid de la cuestión gira en torno al principio : ¿existe alguna situación en la que no sea necesario prohibir esto? De ser así, cómo hacerlo de la manera más correcta y apropiada para la situación .

Ahora, como @Thomas, @sfussenegger y algunos otros mencionaron, 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 comprender qué está en juego, cuánto vale la pena proteger y qué otras mitigaciones están en juego para proporcionar 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 seguridad 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 punto, se hace cargo de un análisis de riesgo reflexivo.

Ya sabes, es divertido: 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 en decir el dogma "Best Practice" (o CWE) SIN ese análisis de riesgos tan importante .
"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 se defiende. Más seguridad no necesariamente equivale a una buena seguridad".
El análisis de riesgos y los verdaderos fanáticos de la seguridad señalarían 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 señalar 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ían arrojar dogmas y CWE sin siquiera comprender cómo realizar un análisis de riesgos, no son más que trucos de seguridad, y su experiencia no vale el papel higiénico en el que lo imprimieron.

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

Pero antes de hablar sobre las compensaciones apropiadas para 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 tenemos la hipótesis, ya que la pregunta es qué hipotética situación podría haber ...)
Supongamos un sistema de BAJO VALOR, pero no tan trivial como el acceso público: el propietario del sistema quiere evitar la suplantación casual, pero la "alta" seguridad no es tan importante como la facilidad de uso. (Sí, es una compensación legítima ACEPTAR el riesgo de que cualquier script-kiddie competente pueda hackear el sitio ... Espera, ¿APT no está en boga ahora ...?)
Solo por ejemplo, digamos que estoy organizando un sitio simple para una gran reunión familiar, permitiendo que todos piensen en dónde queremos ir en nuestro viaje de campamento este año. Estoy menos preocupado por algún pirata informático anónimo, o incluso por el primo Fred apretando repetidas sugerencias para regresar al lago Wantanamanabikiliki, ya que estoy preocupado por que tía Erma no pueda iniciar sesión cuando lo necesite. Ahora, tía Erma, como física nuclear, no es muy buena para recordar contraseñas, ni siquiera para usar computadoras ... Así que quiero eliminar toda la fricción posible 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 vendrá y qué quieren.

De todas formas.
Entonces, ¿cuáles son nuestros principales riesgos aquí, si encriptamos simétricamente las contraseñas, en lugar de usar un hash unidireccional?

• Hacerse pasar por usuarios? No, ya he aceptado ese riesgo, no es interesante.
• Administrador malvado? Bueno, tal vez ... Pero de nuevo, 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 dañó, su juego termina de todos modos.
• 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 es la identidad real la que se comparte, sino la prueba o la credencial de autenticación. De acuerdo, dado que una contraseña compartida me permitirá ingresar a otro sistema (por ejemplo, mi cuenta bancaria o gmail), esta es efectivamente la misma identidad, por lo que es solo semántica ... Excepto que no lo es . La identidad se administra por separado por cada sistema, en este escenario (aunque puede haber sistemas de identificación de terceros, como OAuth, aún así, se separa de la identidad en este sistema, más sobre esto más adelante).
  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 hacker de mi sitio tendremos acceso a las contraseñas de tía Erma para El sitio de misiles nucleares.

Hmmm

¿Te parece algo extraño?

Debería.

Comencemos con el hecho de que proteger el sistema de misiles nucleares no es mi responsabilidad , solo estoy construyendo un sitio de salida familiar para mi familia. Entonces, ¿de quién es la responsabilidad? Umm ... ¿Qué tal el sistema de misiles nucleares? Duh
Segundo, 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é molestaría en hackear su sitio? ¿O luchando con su cifrado simétrico? Goshdarnitall, puedo crear mi propio sitio web simple , hacer que los usuarios se registren para recibir NOTICIAS MUY IMPORTANTES acerca de lo que quieran ... Puffo Presto, "robé" sus contraseñas.

Sí, la educación del usuario siempre regresa para mordernos en el hienie, ¿no?
Y no hay nada que puedas hacer al respecto ... Incluso si FUERAS descifrando sus contraseñas en tu sitio, y haces todo lo que la TSA pueda pensar, agregaste protección a su contraseña NO UNO MISMO , si van a mantener pegando promiscuamente sus contraseñas en cada sitio en el que se encuentran. No te molestes en intentarlo.

Dicho de otra manera, no eres dueño de sus contraseñas , así que deja de intentar actuar como lo haces.

Entonces, mis estimados expertos en seguridad, como solía preguntar una anciana por Wendy's, "¿DÓNDE está el riesgo?"

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

• CWE no es una ley o reglamento, ni siquiera un estándar. Es una colección de debilidades comunes , es decir, el inverso de las "Mejores prácticas".
• El tema 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 tanto para estos sistemas de bajo valor como para 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 se parece mucho a los servidores del blog de tu gato, pero tampoco superan a algunos de los bancos más seguros.
• El conocimiento dividido, o el control dual, de las claves de cifrado NO suceden solo en el ejército, de hecho, PCI-DSS ahora requiere esto básicamente de 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 las respuestas como esas, las que hacen que la profesión de seguridad se vea aún peor. Una vez más, el análisis de riesgos centrado en el negocio es lo que se requiere, de lo contrario te volverás inútil. Además de estar equivocado.
• Supongo que esta es la razón por la cual no es una buena idea simplemente tomar un desarrollador regular y dejar caer más responsabilidades de seguridad sobre él, sin capacitación para pensar de manera diferente y buscar las compensaciones correctas. Sin ofender, para aquellos de ustedes aquí, estoy a favor, pero se necesita más capacitación.

Uf. Qué publicación tan larga ...
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. Haga un berrinche, si es necesario.
• Explíquele el RIESGO EMPRESARIAL. Los detalles son buenos, las cifras son mejores, una demostración en vivo suele ser la mejor.
• SI TODAVÍA insiste Y presenta razones comerciales válidas, es hora de que usted haga una llamada de juicio:
  ¿Es este sitio bajo o sin valor? ¿Es realmente un caso de negocios válido? ¿Es lo suficientemente bueno para ti? ¿No hay otros riesgos que pueda considerar que superen las razones comerciales válidas? (Y, por supuesto, el cliente NO es un sitio malicioso, pero eso es duh).
  Si es así, solo adelante. No vale la pena el esfuerzo, la fricción y el uso perdido (en esta situación hipotética) para establecer el proceso necesario. Cualquier otra decisión (nuevamente, en esta situación) es una mala compensación.

Entonces, en resumen, y una respuesta real: cifrarlo con un algoritmo simétrico simple, proteger la clave de cifrado con ACL fuertes y preferiblemente DPAPI o similares, documentarla y hacer que el cliente (alguien lo suficientemente alto como para tomar esa decisión) firme eso.

¿Qué tal una casa a mitad de camino?

Almacene las contraseñas con un cifrado seguro y no habilite los reinicios.

En lugar de restablecer las contraseñas, permita el envío de una contraseña de un solo uso (que debe cambiarse tan pronto como ocurra el primer inicio de sesión). Deje que el usuario cambie a la contraseña que desee (la anterior, si así lo desea).

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

La única forma de permitir que un usuario recupere su contraseña original es cifrarla con la clave pública del usuario. Solo ese usuario puede descifrar su contraseña.

Entonces los pasos serían:

1. El usuario se registra en su sitio (a través de SSL, por supuesto) sin establecer aún una contraseña. Inicie sesión automáticamente o proporcione una contraseña temporal.
2. Usted ofrece almacenar su clave PGP pública para recuperar futuras contraseñas.
3. Suben su clave pública de PGP.
4. Les pides que establezcan una nueva contraseña.
5. Ellos envían su contraseña.
6. Hash hash la contraseña utilizando el mejor algoritmo de hash de contraseña disponible (por ejemplo, bcrypt). Use esto al validar el próximo inicio de sesión.
7. Encripta la contraseña con la clave pública y la almacena por separado.

En caso de que el usuario solicite su contraseña, debe responder con la contraseña cifrada (no cifrada). Si el usuario no desea poder recuperar su contraseña en el futuro (solo podrá restablecerla a una generada por el servicio), se pueden omitir los pasos 3 y 7.

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

Tengo el mismo problema. Y de la misma manera, siempre pienso que alguien hackea mi sistema, no se trata de "si" sino de "cuándo".

Entonces, cuando debo hacer un sitio web que necesita almacenar 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 .
• arg de datos :
  • la información confidencial (por ejemplo, la contraseña del usuario)
  • serializar si es necesario, por ejemplo, si la información es una matriz de datos como información sensible múltiple
• contraseña arg : use una información que solo el usuario conozca como:
  • la placa de 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 sms en el 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 recuperar estos datos, simplemente use la función "openssl_decrypt ()" y solicite al usuario la respuesta. Por ejemplo: "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 celular 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 de conocer para alguien no familiar.

PD 2 : para obtener información de la tarjeta de crédito, como "compra con un clic", lo que hago es usar la contraseña de inicio de sesión. Esta contraseña está cifrada en la base de datos (sha1, md5, etc.), pero al iniciar sesión almaceno la contraseña de texto sin formato en la 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, destruida al final de la sección. Cuando el usuario hace clic en el botón "compra con un clic", el sistema usa esta contraseña. Si el usuario inició sesión con un servicio como Facebook, Twitter, etc., solicito nuevamente la contraseña en el momento de la compra (ok, no es un "clic" completo) o luego uso algunos datos del servicio que el usuario usó para iniciar sesión (como la identificación de Facebook).

Asegurar credenciales no es una operación binaria: seguro / no seguro. La seguridad tiene que ver con la evaluación de riesgos y se mide de 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 cifradas con requisitos de contraseña estrictos, muestras de ADN y escaneos de retina son más seguras pero a un costo de desarrollo y experiencia del usuario. Las contraseñas de texto sin formato son mucho menos seguras, pero su implementación es más barata (pero debe evitarse). Al final del día, se reduce a un análisis de costo / beneficio de una violación. Implementa la seguridad en función del valor de los datos que se protegen y su valor temporal.

¿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 brinda opciones a sus clientes y, cuando se trata de seguridad, expone las ventajas y los riesgos de cualquier implementación. Esto es doble si el cliente solicita algo que podría ponerlos en riesgo por no cumplir con los estándares de la industria. Si un cliente solicita específicamente un cifrado bidireccional, me aseguraría de que documente sus objeciones, pero eso no debería impedir que implemente de la mejor manera que sepa. Al final del día, es el dinero del cliente. Si,

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 claves privadas de certificados a cuentas administrativas y con contraseñas. Si está alojando en otras plataformas, necesitaría ver qué opciones tiene disponibles en esas. Como otros han sugerido, puede usar cifrado asimétrico.

No hay ninguna ley (ni la Ley de Protección de Datos en el Reino Unido) de la que tenga conocimiento que establezca específicamente que las contraseñas deben almacenarse utilizando hashes unidireccionales. El único requisito en cualquiera de estas leyes es simplemente que razonable se tomen medidas 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 dicha restricción.

Sin embargo, esto saca a la luz un aspecto más: la precedencia legal. Si la precedencia legal sugiere que debe usar hashes unidireccionales dada la industria en la que se está construyendo su sistema, entonces eso es completamente diferente. Esa es la munición que usa para convencer a su cliente. Salvo eso, la mejor sugerencia para proporcionar una evaluación de riesgo razonable, documentar sus objeciones e implementar el sistema de la manera más segura que pueda dar los requisitos del cliente.

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

Implemento sistemas de autenticación de múltiples factores para vivir, por lo que para mí es natural pensar que puede restablecer o reconstruir la contraseña, mientras que temporalmente utilizo 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 el intervalo de tiempo es corto 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 quejas de un enchufe comercial, lo que estoy diciendo 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.

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

Acabo de encontrar esta discusión interesante y acalorada. Sin embargo, 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 de que los usuarios son mayores o jóvenes no responde realmente a esa pregunta. Pero, ¿cómo se puede tomar una decisión comercial sin comprender adecuadamente la preocupación del cliente?

¿Ahora por qué es importante? 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 arriba.

Otra pregunta que he visto es:

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

Y aquí hay una posible respuesta. Si tu gato llamó "miaumiau" y usó su nombre como contraseña, pero olvidó que lo hiciste, ¿preferirías que se te recuerde lo que era o que te envíen algo como "# zy * RW (ew"?

¡Otra posible razón es que el usuario considera que es difícil encontrar una nueva contraseña! Por lo tanto, el envío de la contraseña anterior devuelve la ilusión de salvarla de ese doloroso trabajo nuevamente.

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

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

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

Sé que es inseguro, pero ¿qué me importa que alguien tenga 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 el problema del sitio, no el 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 ante el problema.

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.

Manejo de contraseñas perdidas / olvidadas:

Nadie debería poder recuperar contraseñas.

Si los usuarios olvidaron sus contraseñas, al menos deben conocer sus nombres de usuario o direcciones de correo electrónico. Previa solicitud, genere un GUID en la tabla 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 tener usuarios de ayuda de línea directa, agregue algunas funciones a su modelo de subvenciones y permita que la función de línea directa inicie sesión temporalmente como usuario identificado. Registre todos los inicios de sesión de línea directa. Por ejemplo, Bugzilla ofrece una función de suplantación a los administradores.

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

Si no puede simplemente rechazar el requisito de almacenar contraseñas recuperables, ¿qué tal esto como su contraargumento?

Podemos hacer un hash de contraseñas correctamente y crear un mecanismo de reinicio para los usuarios, o podemos eliminar toda la información de identificación personal del sistema. Puede usar una dirección de correo electrónico para configurar las preferencias del usuario, pero eso es todo. Use una cookie para extraer automáticamente las preferencias en futuras visitas y deseche 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 de servicio al cliente, tal vez pueda deshacerse de ella.

¿ Realmente necesitan los usuarios recuperar (por ejemplo, que se les diga) cuál fue la contraseña que olvidaron o simplemente necesitan poder ingresar 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 (lo que sea) a una nueva contraseña que la persona de soporte puede 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 restablecimientos deben registrarse en algún lugar y una buena práctica sería generar un correo electrónico al usuario diciéndole 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 administra el usuario y la otra es como una llave maestra / maestra 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 es necesario decir que el sistema también debe registrar todos los inicios de sesión con la clave maestra. Como medida adicional, siempre que se use la clave maestra, también podría validar las credenciales de las personas de soporte.

-EDIT- En respuesta a los comentarios sobre no tener una clave maestra: estoy de acuerdo en que es malo, así como creo que es malo permitir que cualquier persona que no sea el usuario tenga acceso a la cuenta del usuario. Si observa la pregunta, la premisa es que el cliente exigió un entorno de seguridad altamente comprometido.

Una llave maestra no necesita ser tan mala como parece. Solía ​​trabajar en una planta de defensa donde percibían la necesidad de que el operador de la computadora central tuviera "acceso especial" en ciertas ocasiones. Simplemente colocan la contraseña especial en un sobre sellado y la pegan al escritorio del operador. Para usar la contraseña (que el operador no sabía) tuvo que abrir el sobre. En cada cambio de turno, uno de los trabajos del supervisor de turno consistía en ver si se había abierto el sobre y, de ser así, la contraseña fue cambiada (por otro departamento) y la nueva contraseña se colocó en un nuevo sobre y el proceso comenzó todo otra vez. Se interrogaría al operador por qué lo había abierto y el incidente se documentaría 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 todos los operadores tenían autorizaciones secretas del DOD y nunca tuvimos ningún abuso.

Debido a la revisión y supervisión, todos los operadores sabían que si usaban mal el privilegio de abrir el sobre, estarían sujetos a despido inmediato y posible enjuiciamiento penal.

Así que supongo que la verdadera respuesta es que si uno quiere hacer las cosas bien, contrata a personas en las que puede confiar, realiza verificaciones de antecedentes y ejerce la supervisión y la responsabilidad de la gestión adecuada.

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

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

Si nunca ve la contraseña de texto sin formato, no surge la cuestión de la recuperación.

Además, deduzco (de la web) que (supuestamente) algunos algoritmos como MD5 ya no se consideran seguros. No tengo forma de juzgar eso, pero es algo a considerar.

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 FTP, utilizando carpetas y archivos en lugar de tablas y filas.
conceda a los servidores web permisos de solo escritura si puede.

Almacene el cifrado no recuperable de la contraseña en la base de datos del sitio (llamémosle "pass-a") como hacen las personas normales :)
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 usar un cifrado bidireccional en la contraseña para dormir mejor por la noche.

ahora para que alguien obtenga la contraseña y su contexto (id del sitio + id del usuario + "pass-a"), tiene que:

1. piratee la base de datos del sitio web para obtener un par o pares ("pass-a", id de usuario).
2. obtener la identificación del sitio web de algún archivo de configuración
3. encuentre y piratee las contraseñas remotas DB.

puede controlar la accesibilidad del servicio de recuperación de contraseña (exponerlo solo como un servicio web seguro, permitir solo cierta cantidad de recuperaciones de contraseñas por día, hacerlo manualmente, etc.) e incluso cobrar 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 cumple muchas funciones y puede protegerse mejor (puede personalizar los permisos, procesos y servicios de manera estricta).

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

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

1. Una vez que un usuario está registrado, tiene acceso completo (como un sitio web normal). El registro debe incluir un correo electrónico.
2. 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 un botón especial " enviarme un correo electrónico para obtener permiso ", justo al lado del botón " enviar ".
3. La solicitud se envía al correo electrónico con un hipervínculo preguntando 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 .
4. Luego, el usuario hace clic en "Sí" y confirma que se deben mostrar los datos, o se debe realizar la acción, revelar los datos, 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 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 externo. Esto funcionaría mejor en casos con usuarios de edad avanzada, con problemas mentales, muy jóvenes o confundidos. Por supuesto, esto requiere un administrador de confianza para que estas personas respalden sus acciones.

Salt-and-hash la contraseña del usuario como de costumbre. Al iniciar sesión en el usuario, permita tanto la contraseña del usuario (después de la salazón / hash), pero también permita que lo que literalmente ingresó el usuario coincida también.

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

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