¿Cómo debería acercarme éticamente al almacenamiento de contraseñas del usuario para una posterior recuperación de texto sin formato?

A medida que sigo construyendo más y más sitios web y aplicaciones web, a menudo me piden que almacene las contraseñas de los usuarios de forma que puedan recuperarse si / cuando el usuario tiene un problema (ya sea para enviar un enlace de contraseña olvidado, guiarlos a través del teléfono, etc.) Cuando puedo, lucho contra esta práctica y hago una gran cantidad de progtwigción ‘extra’ para restablecer contraseñas y asistencia administrativa sin almacenar su contraseña actual.

Cuando no puedo luchar contra eso (o no puedo ganar), siempre codigo la contraseña de alguna manera para que, al menos, no se almacene como texto claro en la base de datos, aunque soy consciente de que si mi base de datos es pirateada no le tomaría mucho al culpable descifrar las contraseñas, así que eso me incomoda.

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

De manera moral y ética, me siento responsable de proteger lo que puede ser, para algunos usuarios, su sustento incluso si lo están tratando con mucho menos respeto. Estoy seguro de que hay muchas formas de acercarse y argumentar a favor de los algoritmos de salazón y las diferentes opciones de encoding, pero ¿hay una sola ‘mejor práctica’ cuando hay 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 quieras hacer y que en la mayoría de los casos es mejor rechazarlo. Sin embargo, no estoy buscando una conferencia sobre los méritos de tomar este enfoque. Estoy buscando los mejores pasos a seguir si se toma este enfoque.

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

En dichos sistemas, la tasa de abandono de estos datos demográficos podría obstaculizar la aplicación si los usuarios no tuvieran este nivel de asistencia de acceso, así que responda con esa 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 las contraseñas (no tendré que guardar el texto plano ni las contraseñas recuperables), pero también permite que la base de usuarios que especifiqué inicie sesión en un sistema sin los inconvenientes principales que he encontrado en recuperación de contraseña normal.

Como siempre hubo alrededor de 5 respuestas que me gustaría marcar como correctas por diferentes razones, pero tuve que elegir la mejor, el rest 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. Aprovecho los 100 votos al alza como un cumplido y espero que esta discusión haya ayudado a otra persona con la misma preocupación que yo.

¿Qué hay de tomar otro enfoque o ángulo en este problema? Pregunte por qué se requiere la contraseña en texto plano: si es para que el usuario pueda recuperar la contraseña, en realidad no es necesario que recupere la contraseña que establecieron (no recuerdan de todos modos qué es), usted necesita poder darles una contraseña que puedan usar .

Piénselo: si el usuario necesita recuperar la contraseña, es porque la ha olvidado. En ese caso, una nueva contraseña es tan buena como la anterior. Sin embargo, uno de los inconvenientes de los mecanismos comunes de restablecimiento de contraseñas utilizados en la actualidad es que las contraseñas generadas en una operación de reinicio generalmente son un grupo de caracteres aleatorios, por lo que es difícil que el usuario simplemente escriba correctamente a menos que copie-n- 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 son 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 la contraseña generada automáticamente debe tener solo 8 (o 10 o 12) caracteres. Obtenga una frase clave de auto-generación de alta entropía al juntar varias palabras aleatorias (deje un espacio entre ellas, de modo que sigan siendo reconocibles y escribibles por cualquiera que pueda leer). Seis palabras aleatorias de longitud variable probablemente sean 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 dibujada 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. Utilizando un diccionario de 7776 palabras (como utiliza Diceware) 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. Consulte las Preguntas frecuentes sobre Diceware para obtener más información.

  • una frase de contraseña con alrededor de 77 bits de entropía: “admite el estilo agudo de mesa de bengala de prosa”

  • una contraseña con alrededor de 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érdidas 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 que agradecerán sus usuarios).

Entiendo los argumentos de que hay activos protegidos con contraseña que realmente no tienen un alto nivel de valor, por lo que el incumplimiento 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 pasar es que alguien envíe correos electrónicos no deseados o publicaciones debajo de 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 sus sitios de foros web que para sus cuentas bancarias (y probablemente bases de datos de seguridad nacional), creo que sería mejor manejar incluso las contraseñas de ‘bajo valor’ como no -recuperable.

Imagine que alguien ha encargado la construcción de un gran edificio, un bar, digamos, y tiene 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 muy 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 para discutir. Solo haz lo que te pedí.

¿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 muy probable que la conversación termine así:

Arquitecto: este edificio no se puede construir sin salidas de emergencia. Puede ir a cualquier otro profesional con licencia y él le dirá lo mismo. Me voy ahora; llámame cuando estés listo para cooperar.

La progtwigción de computadoras puede no ser una profesión autorizada , 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 los requisitos de basura (o completamente peligroso), simplemente se rechazarán. Saben que no es una excusa para decir: “bueno, hice mi mejor esfuerzo, pero él insistió, y tengo que hacer lo que él dice”. Podrían perder su licencia por esa excusa.

No sé si usted o sus clientes son parte de una empresa que cotiza en bolsa, pero el almacenamiento de contraseñas de cualquier forma recuperable podría ocasionar que falle varios tipos diferentes de auditorías de seguridad. El problema no es lo difícil que sería para un “hacker” acceder a su base de datos para recuperar las contraseñas. La gran mayoría de las amenazas de seguridad son internas. Lo que necesita proteger es que un empleado descontento se vaya con todas las contraseñas y las venda al mejor postor. El uso de cifrado asimétrico y el almacenamiento de la clave privada en una base de datos independiente no hace absolutamente nada para evitar este escenario; siempre habrá alguien con acceso a la base de datos privada, y ese es un serio riesgo de seguridad.

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

Puede encriptar 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, cuando la contraseña necesita restaurarse en texto plano, puede descifrar de forma manual o semiautomática con la clave privada. La clave privada se puede almacenar en otro lugar y, además, se puede encriptar simétricamente (lo que requerirá una interacción humana para descifrar la contraseña).

Creo que esto es similar a la forma en que funciona el Windows Recovery Agent .

  • Las contraseñas se almacenan encriptadas
  • Las personas pueden iniciar sesión sin descifrar el 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 un banco seguro, si así 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, ha otorgado a sus clientes un mecanismo legal de no repudio y pueden rechazar 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 poner la transacción a través de ellos mismos. Si las contraseñas se almacenan correctamente como resúmenes en vez de texto cifrado, esto es imposible, ya sea que el cliente final haya ejecutado la transacción él mismo o incumplido 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 contraseñas éticamente para la posterior recuperación de texto sin formato. Es tan simple como eso. Incluso Jon Skeet no puede almacenar éticamente las contraseñas para la posterior recuperación de texto sin formato. Si sus usuarios pueden recuperar contraseñas en texto plano de alguna manera u otra, entonces potencialmente también lo puede hacer un hacker que encuentre una vulnerabilidad de seguridad en su código. Y no solo se está comprometiendo la contraseña de un usuario, sino que se trata de todas.

Si sus clientes tienen un problema con eso, dígales que el almacenamiento de contraseñas de manera recuperable es contrario a la ley. Aquí en el Reino Unido en cualquier caso, la Ley de Protección de Datos de 1998 (en particular, Anexo 1, Parte II, Párrafo 9) requiere que los controladores de datos utilicen las medidas técnicas apropiadas para mantener seguros los datos personales, teniendo en cuenta, entre otras cosas, la daño que podría causar si los datos se vieran comprometidos, lo que podría ser considerable para los usuarios que comparten contraseñas entre los sitios. Si todavía tienen problemas para entender el hecho de que es un problema, indíquenles 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 correo electrónico por correo electrónico que los conecte de manera automática y los lleve 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 en el blog que escribí sobre el tema:

Actualización: ahora estamos empezando a ver demandas y enjuiciamientos contra empresas que no protegen adecuadamente las contraseñas de sus usuarios. Ejemplo: LinkedIn abofeteó con una demanda colectiva de $ 5 millones ; Sony multó con £ 250,000 por el pirateo de datos de PlayStation . Si recuerdo correctamente, 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 mencioné que los sitios web orientados principalmente a personas mayores, con problemas mentales o muy jóvenes pueden volverse confusos para las personas cuando se les pide que realicen una rutina segura de recuperación de contraseñas. Aunque podemos encontrarlo simple y mundano en esos casos, algunos usuarios necesitan la asistencia adicional de tener un técnico de servicio que los ayude a ingresar al sistema o que se lo envíen por correo electrónico directamente.

En dichos sistemas, la tasa de abandono de estos datos demográficos podría obstaculizar la aplicación si los usuarios no tuvieran este nivel de asistencia de acceso, así que responda con esa 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 progtwig de Internet no funciona, no sé mi contraseña”. “OK”, dice el abejón de servicio al cliente “déjame revisar algunos detalles y luego te daré una nueva contraseña . Cuando vuelvas a iniciar sesión, te preguntará si deseas conservar esa contraseña o cambiarla por algo que recuerdes. más fácilmente.”

Luego, el sistema está configurado para saber cuándo se ha restablecido la contraseña y mostrar el mensaje “¿Desea conservar la nueva contraseña o elegir uno nuevo?”.

¿Cómo es esto peor para los menos alfabetizados que se les haya dicho su contraseña anterior? Y si bien la persona de servicio al cliente puede hacer travesuras, la base de datos en sí misma es mucho más segura en caso de que se incumpla.

Comenta lo que está mal en mi sugerencia y te sugeriré una solución que realmente haga lo que inicialmente querías.

Michael Brooks ha sido bastante eloquent 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. Encripte la contraseña con la clave pública de otra persona, alguna autoridad externa. De esta forma, no podrá reconstruirlo personalmente, y el usuario tendrá que dirigirse a esa autoridad externa y solicitar que se recupere su contraseña.
  2. Encripte la contraseña usando una clave generada a partir de una segunda frase de contraseña. Haga esta encriptación del lado del cliente y nunca la transmita al servidor de manera clara. Luego, para recuperar, vuelva a descifrar el lado del cliente volviendo a generar la clave desde su entrada. Es cierto que este enfoque es básicamente el uso de una segunda contraseña, pero siempre puedes decirles que la 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 compañía del cliente para que mantenga la clave privada. Asegúrese de que generen la clave ellos mismos, y almacénela con instrucciones en una caja fuerte, etc. Incluso podría agregar seguridad al elegir encriptar y suministrar 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 de qué se trataba!

Se han debatido muchas cuestiones de seguridad para el usuario en respuesta a esta pregunta, pero me gustaría agregar una mención de los beneficios. Hasta el momento, no he visto un beneficio legítimo mencionado por tener una contraseña recuperable almacenada en el sistema. Considera esto:

  • ¿El usuario se beneficia al recibir su contraseña por correo electrónico? No. Reciben más beneficios de un enlace de restablecimiento de contraseña de uso único, que ojalá les permita elegir una contraseña que recordarán.
  • ¿El usuario se beneficia al tener su contraseña mostrada en la pantalla? No, por la misma razón que arriba; deberían elegir una nueva contraseña.
  • ¿El usuario se beneficia al tener una persona de soporte que le dice la contraseña al usuario? No; una vez más, 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 pobres que requieren el intercambio de contraseñas de terceros (¡no use dichas API nunca!). Quizás pueda ganar su argumento diciendo sinceramente a sus clientes que la compañía no obtiene beneficios y solo responsabilidades almacenando contraseñas recuperables .

Leyendo entre las líneas de este tipo de solicitudes, verá que sus clientes probablemente no entienden o incluso realmente se preocupan por 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 quieren 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 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.
  • Desactivar las restricciones de contraseña. Estoy seguro de que todos nos hemos sentido 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 fortaleza 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 relajadas, los usuarios tendrán más probabilidades de usar una contraseña que no olvidarán.
  • No caduque las contraseñas.
  • Permitir al usuario reutilizar una contraseña anterior.
  • Permitir al usuario elegir su propia pregunta de restablecimiento de contraseña.

Pero si, por algún motivo (y por favor díganos el motivo) 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 sin contraseña. sistema de autenticación basado Como 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 el ú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 bashs de fuerza bruta están protegidos.
  • Haga que el usuario elija una pregunta con una respuesta breve que solo ellos conozcan la respuesta, que nunca cambiará, que siempre recordarán, y que no les importará que otras personas la descubran.
  • 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 suposiciones (vea esta ingeniosa fotografía de cómo el G1 hace esto para desbloquear el teléfono).
  • Para un sitio web para niños, puede generar automáticamente una criatura difusa basada en el nombre de usuario (más o menos como un identicon) y pedirle al usuario que le dé un nombre secreto a la criatura. A continuación, 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 todo el mundo … Mi reacción inicial fue muy similar a @Michael Brooks, hasta que me di cuenta, como @stefanw, que el problema aquí es que se han roto los requisitos, 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 una opción de seguridad incorrecta .
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 en los que simplemente no lo vale (pero aún se requiere una contraseña simple).

Es importante recordar que la verdadera experiencia en seguridad consiste en encontrar las compensaciones apropiadas, NO en lanzar de manera dogmática las “mejores prácticas” que cualquiera puede leer en línea.

Como tal, sugiero otra solución:
Dependiendo del valor del sistema, y SÓLO SI el sistema tiene un valor bajo apropiado sin un activo “caro” (la identidad misma, incluida), Y existen requisitos empresariales válidos que hacen que el proceso adecuado sea imposible (o suficientemente difícil / costoso) , Y el cliente conoce todas las advertencias …
Entonces podría ser apropiado simplemente permitir encriptación reversible, sin aros especiales para saltar.
Me estoy quedando corto en decir que no me preocupo por el cifrado, porque es muy simple / barato de implementar (incluso considerando la gestión de claves pasible), y proporciona cierta 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, visualización en la pantalla, etc.
Dado que la suposición aquí es que el valor de la contraseña robada (incluso en conjunto) es bastante baja, cualquiera de estas soluciones puede ser válida.


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

Para empezar, 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 está en absoluto en disputa …
Además, enfatizaré que en muchas situaciones, MÁS, MÁS, está realmente mal, incluso sucio, desagradable, y feo .

Sin embargo, el quid de la cuestión está en torno al principio , ¿hay alguna situación en la que no sea necesario prohibir esto y, de ser así, cómo hacerlo de la manera más correcta que corresponda a la situación ?

Ahora, como @Thomas, @sfussenegger y algunos otros mencionaron, la única manera correcta de responder a esa pregunta es hacer un análisis de riesgo completo de cualquier situación dada (o hipotética), para entender lo que está en juego, cuánto vale la pena proteger , y qué otras mitigaciones están en juego para brindar 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 real. Las mejores prácticas son buenas hasta cierto punto (por lo general, como pautas para los inexpertos y los piratas informáticos), después de ese momento el análisis de riesgos reflexivo toma el control.

Ya sabes, es gracioso: siempre me consideré uno de los fanáticos de la seguridad, y de alguna manera estoy del lado opuesto a los llamados “expertos en seguridad” … Bueno, la verdad es que, porque soy un fanático, y un experto en seguridad real de la vida real: no creo en lanzar un dogma de “mejores prácticas” (o CWEs) 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 verdadero problema al que se están defendiendo. Más seguridad no equivale necesariamente a una buena seguridad”.
El análisis de riesgos y los verdaderos fanáticos de la seguridad apuntarían a un compromiso más inteligente basado en el valor / riesgo, basado en el riesgo, la pérdida potencial, posibles amenazas, mitigaciones complementarias, etc. Cualquier “experto en seguridad” que no pueda apuntar a un análisis de riesgo sólido como el En base a sus recomendaciones, o apoyar compensaciones lógicas, pero preferirían lanzar dogma y CWE sin siquiera entender cómo realizar un análisis de riesgo, no son más que Security Hacks, y su experiencia no vale el papel higiénico en el que lo imprimieron.

De hecho, así es como obtenemos la ridiculez de Airport Security.

Pero antes de que hablemos 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 antecedentes sobre esta situación, todos estamos formulando hipótesis, ya que la pregunta es qué hipotéticos situación podría haber …)
Asummos un sistema de VALOR BAJO, pero no tan real como para que sea de acceso público: el propietario del sistema desea evitar la suplantación casual, aunque la seguridad “alta” 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 piratear el sitio … Espera, ¿no está APT en boga ahora …?)
Solo por ejemplo, digamos que estoy organizando un sitio simple para una gran reunión familiar, permitiendo que todos puedan intercambiar ideas sobre dónde queremos ir en nuestro viaje de campamento este año. Estoy menos preocupado por algún hacker anónimo, o incluso el primo Fred exprimiendo repetidas sugerencias para volver al lago Wantanamanabikiliki, ya que estoy hablando de que la tía Erma no podrá iniciar sesión cuando lo necesite. Ahora, la tía Erma, siendo física nuclear, no es muy buena recordando contraseñas, o incluso usando computadoras … Así que quiero eliminar toda la fricción posible para ella. Una vez más, NO me preocupan los hacks, simplemente no quiero errores tontos de inicios de sesión incorrectos. Quiero saber quién viene y qué es lo que quieren.

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

  • Suplantar a los usuarios? No, ya acepté ese riesgo, no interesante.
  • ¿Administrador malvado? Bueno, tal vez … Pero, una vez más, no me importa si alguien puede hacerse pasar por otro usuario, INTERNAL o no … y de todos modos un administrador malicioso va a obtener su contraseña pase lo que pase. Si su administrador se ha vuelto malo, se acabó el juego.
  • Otro problema que se ha planteado es que la identidad en realidad se comparte entre varios sistemas. Ah! Este es un riesgo muy interesante, que requiere una mirada más de cerca.
    Permítanme comenzar afirmando que no es la identidad real que se comparte, sino la prueba o la credencial de autenticación. Bien, 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 solo es semántica … Excepto que no lo es . La identidad se gestiona por separado en cada sistema, en este escenario (aunque es posible que existan sistemas de identificación de terceros, como OAuth, que es un elemento separado 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, tendré acceso a las contraseñas de la tía Erma para el sitio de misiles nucleares.

Hmmm.

¿Hay algo aquí que te parezca desagradable?

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 frakkin (para MI familia). Entonces, ¿de quién es la responsabilidad? Umm … ¿Qué tal el sistema de misiles nucleares? Duh.
En segundo lugar, si quería 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 hackear su sitio? ¿O luchando con tu encriptación simétrica? Goshdarnitall, puedo poner mi propio sitio web simple , hacer que los usuarios se registren para recibir NOTICIAS MUY IMPORTANTES sobre lo que quieran … Puffo Prest, “robé” sus contraseñas.

Sí, la educación del usuario siempre regresa para mordernos en la mente, ¿no es así?
Y no hay nada que puedas hacer al respecto … Incluso si tienes que codificar sus contraseñas en tu sitio y hacer todo lo demás que pueda pensar en la TSA, agregaste protección a su contraseña, NO TENGO , si van a mantener colocando promiscuamente sus contraseñas en cada sitio con el que tropiezan. Ni siquiera te molestes en intentarlo.

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

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

Otros pocos puntos, en respuesta a algunos problemas planteados anteriormente:

  • CWE no es una ley, ni un reglamento, ni siquiera un estándar. Es una colección de debilidades comunes , es decir, el inverso de “Mejores prácticas”.
  • El problema de la identidad compartida es un problema real, pero incomprendido (o tergiversado) por los detractores aquí. Es una cuestión de compartir la identidad en sí misma (!), NO sobre descifrar las contraseñas en sistemas de bajo valor. Si comparte una contraseña entre un sistema de bajo valor y uno de alto valor, ¡el problema ya está allí!
  • Por el momento, el punto anterior en realidad apuntaba EN CONTRA usando 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 del todo 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 dual, de las claves de encriptación NO ocurren 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 lo que hace que la profesión de desarrollador se vea tan mal: son respuestas como esas, que hacen que la profesión de seguridad parezca aún peor. De nuevo, lo que se requiere es un análisis de riesgos centrado en el negocio; de lo contrario, se hará inútil. Además de estar equivocado.
  • Supongo que esta es la razón por la cual no es una buena idea simplemente contratar a un desarrollador regular y dejar caer más responsabilidades de seguridad sobre él, sin capacitación para pensar de manera diferente, y buscar las soluciones correctas. Sin ofender, para aquellos de ustedes que están aquí, estoy a favor, pero es necesario más entrenamiento.

Uf. Qué larga publicación …
Pero para responder a su pregunta original, @Shane:

  • Explique al cliente la forma correcta de hacer las cosas.
  • Si él todavía insiste, explique un poco más, insista, discuta. Haga una rabieta, si es necesario.
  • Explícale el RIESGO EMPRESARIAL. Los detalles son buenos, las cifras son mejores, una demostración en vivo es generalmente mejor.
  • SI TODAVÍA insiste Y presenta razones comerciales válidas, es hora de que haga una llamada de juicio:
    ¿Es este sitio de bajo o ningún valor? ¿Es realmente un caso comercial válido? ¿Es lo suficientemente bueno para ti? ¿No hay otros riesgos que pueda considerar que superarían 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 poner el proceso necesario en su lugar. Cualquier otra decisión (nuevamente, en esta situación) es una mala compensación.

Entonces, línea de fondo, y una respuesta real: encriptarlo con un algoritmo simétrico simple, proteger la clave de encriptación con ACL fuertes y preferiblemente DPAPI o similares, documentarla y hacer que el cliente (alguien con el suficiente antigüedad como para tomar esa decisión) apruebe eso.

¿Qué tal una casa a medio camino?

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

En lugar de restablecer las contraseñas, permita enviar una contraseña de un solo uso (que debe cambiarse tan pronto como se produzca el primer inicio de sesión). Deje que el usuario cambie a la contraseña que quiera (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 encriptarla 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 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. Cargan su clave pública de PGP.
  4. Les pides que establezcan una nueva contraseña.
  5. Ellos envían su contraseña
  6. Hash la contraseña utilizando el mejor algoritmo hash de contraseñas disponible (por ejemplo, bcrypt). Úselo cuando valide el próximo inicio de sesión.
  7. Encriptas la contraseña con la clave pública y la guardas por separado.

En caso de que el usuario le pida su contraseña, responda con la contraseña encriptada (no hash). Si el usuario no desea poder recuperar su contraseña en el futuro (solo podrían 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 hackear mi sistema no es una cuestión de “si” sino de “cuando”.

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:

  • Encriptar con: openssl_encrypt (string $ data, string $ method, string $ password)
    • Manual de PHP .
  • arg de datos :
    • la información sensible (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 : utiliza una información que solo el usuario conoce 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 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, solo 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?”

PD 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, entonces nunca use esta información para codificar los datos. Utilice siempre una información que solo el usuario conozca o que sea difícil de conocer para alguien que no sea familiar.

PD 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 es hash en la base de datos (sha1, md5, etc.), pero en el momento del inicio de sesión guardo la contraseña de texto sin formato en 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 permanece siempre en la memoria, destruida al final de la sección. Cuando el usuario hace clic en el botón “comprar con un clic”, el sistema usa esta contraseña. Si el usuario inició sesión con un servicio como Facebook, Twitter, etc., solicito la contraseña nuevamente al momento de la compra (vale, no es un “clic”) o luego uso algunos datos del servicio que el usuario usó para iniciar sesión (como la identificación de Facebook).

Proteger credenciales no es una operación binaria: segura / no segura. La seguridad se trata de la evaluación de riesgos y se mide en un continuo. Los fanáticos de la seguridad odian pensar de esta manera, pero la fea verdad es que nada es perfectamente seguro. Las contraseñas hash con requisitos de contraseña estricta, muestras de ADN y escaneos de retina son más seguros, pero a costa del desarrollo y la experiencia del usuario. Las contraseñas de texto simple son mucho menos seguras pero son más económicas de implementar (pero deben evitarse). Al final del día, todo se reduce a un análisis de costo / beneficio de una infracción. Implementa seguridad en función del valor de los datos que se aseguran y su valor de tiempo.

¿Cuál es el costo de que la contraseña de alguien salga al air libre? ¿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 proporciona 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 pueda ponerlos en riesgo por no cumplir con los estándares de la industria. Si un cliente solicita específicamente el cifrado bidireccional, me aseguraré de que documente sus objeciones, pero eso no debe impedirle implementar de la mejor manera que conozca. Al final del día, es el dinero del cliente. Sí, deberías presionar para usar hashes unidireccionales, pero decir que es absolutamente la única opción y que todo lo demás no es ético es una completa tontería.

Si está almacenando contraseñas con encriptación 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 otras plataformas, necesitará ver qué opciones tiene disponibles en esas. Como otros han sugerido, puede usar encriptación asimétrica.

No existe ninguna ley (ni la Ley de Protección de Datos en el Reino Unido) de la que tenga conocimiento que indique específicamente que las contraseñas deben almacenarse usando hash 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 plano pueden calificar legalmente bajo dicha restricción.

Sin embargo, esto saca a la luz un aspecto más: 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 riesgos razonable, documentar sus objeciones e implementar el sistema de la manera más segura que pueda, dados los requisitos del cliente.

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

Implemento sistemas de autenticación de múltiples factores para ganarse la vida, por lo que para mí es natural pensar que puede restablecer o reconstruir la contraseña, mientras que temporalmente usa un factor menos para autenticar al usuario solo por el flujo de trabajo de restablecimiento / recreación. Particularmente 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 OTP de software para teléfonos inteligentes (que la mayoría de los usuarios ya llevan consigo durante 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 reiniciables cuando no son el único factor utilizado para autenticar a un usuario. Admito que para la reutilización de contraseñas entre escenarios de sitios, la situación aún no es bonita, ya que el usuario insistirá en tener la contraseña original porque quiere abrir los otros sitios también, pero puede intentar entregar la contraseña reconstruida en la forma más segura posible (htpps y apariencia discreta en el html).

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

Acabo de enterarme de esta discusión interesante y acalorada. Sin embargo, lo que más me sorprendió fue la poca atención que se le 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 en texto sin formato? ¿Por qué es de tanto valor?

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

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

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 hizo:

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

Y aquí hay una 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 de qué se trataba o más bien le enviasen algo como “# zy * RW (ew”?

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

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

Como usuario, ¡quiero que las cosas sean simples! ¡No quiero trabajar duro!

¡Si inicio sesión en un sitio de noticias para leer periódicos, quiero escribir 1111 como contraseña y pasar!

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 leo 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.

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

Manejo de contraseñas perdidas / olvidadas:

Nadie debería ser capaz de recuperar contraseñas.

Si los usuarios olvidaron sus contraseñas, al menos deben conocer sus nombres de usuario o direcciones de correo electrónico. A petición, 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 la línea directa, agregue algunos roles a su modelo de concesiones y permita que la función de la línea directa inicie sesión temporalmente como usuario identificado. Registre todos los inicios de sesión de esa 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 claro al registrarse, antes de cifrarla y perderla? He visto muchos sitios web hacerlo, y obtener esa contraseña del correo electrónico del usuario es más seguro que dejarlo en tu servidor / comp.

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

Podemos o bien contraseñas hash 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 visitas futuras 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ñas es si realmente se necesita una contraseña. Si lo único que hace su política de contraseñas es causar llamadas al servicio de atención al cliente, quizás pueda deshacerse de él.

¿Los usuarios realmente necesitan recuperar (p. Ej., Saber) 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 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 los reinicios deben registrarse en alguna parte y una buena práctica sería generar un correo electrónico para el 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 el usuario administra y la otra es como una llave maestra / esqueleto que solo es conocida por el personal de soporte y es la misma para todos los usuarios. De esta forma, cuando un usuario tiene un problema, la persona de soporte puede iniciar sesión en la cuenta con la llave 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, cada vez que se utiliza la clave maestra, también puede validar las credenciales de personas de soporte.

-EDIT- En respuesta a los comentarios sobre no tener una clave maestra: acepto 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 nos fijamos en la pregunta, toda la premisa es que el cliente ordenó un entorno de seguridad altamente comprometido.

Una clave maestra no necesita ser tan mala como parecería primero. Solía ​​trabajar en una planta de defensa donde percibieron la necesidad de que el operador de la computadora central tenga “acceso especial” en ciertas ocasiones. Simplemente pusieron la contraseña especial en un sobre sellado y lo pegaron con cinta adhesiva en el 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 era ver si se había abierto el sobre y, de ser así, cambiar la contraseña (por otro departamento) y colocar la nueva contraseña en un sobre nuevo. El proceso comenzó todo. otra vez. El operador sería cuestionado sobre por qué lo había abierto y el incidente sería documentado para el registro.

Si bien este no es un procedimiento que diseñaría, sí 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 abusos.

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

Así que supongo que la verdadera respuesta es si uno quiere hacer las cosas bien: uno contrata personas en las que puede confiar, hace verificaciones de antecedentes y ejerce una supervisión y responsabilidad gerencial adecuadas.

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

Por lo poco que entiendo sobre este tema, creo que si está construyendo un sitio web con un inicio de sesión / contraseña, entonces ni siquiera debería ver la contraseña de texto claro en su servidor. La contraseña debe ser hasheada, y probablemente salada, antes incluso de abandonar al cliente.

Si nunca ves la contraseña de texto claro, no se plantea 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 juzgarlo yo mismo, 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 característica.
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.
otorgue a los servidores web permisos de escritura solo si puede.

Almacene el cifrado no recuperable de la contraseña en el DB del sitio (llamémoslo “pase-a”) como lo hacen las personas normales 🙂
en cada nuevo usuario (o cambio de contraseña), almacene una copia simple de la contraseña en el DB remoto. use la identificación del servidor, la identificación del usuario y “pass-a” como una 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 pueda obtener la contraseña y su contexto (ID del sitio + ID del usuario + “pase-a”), tiene que:

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

puede controlar la accesibilidad del servicio de recuperación de contraseñas (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 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 garantizarse mejor (puede ajustar los permisos, los procesos y los servicios de forma estricta).

en general, haces el trabajo más difícil para el pirata informático. la posibilidad de una violación de seguridad en un solo servidor sigue siendo la misma, pero los datos significativos (una coincidencia de cuenta y contraseña) serán difíciles de armar.

Otra opción que quizás no haya considerado es permitir acciones por correo electrónico. Es un poco engorroso, pero lo implementé para un cliente que necesitaba usuarios “externos” a su sistema para ver (leer solo) ciertas partes del sistema. Por ejemplo:

  1. Una vez que un usuario está registrado, tiene acceso completo (como un sitio web regular). 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 el 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 que le pregunta si desea 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 mencionaste en los comentarios, esto no funcionará si el correo electrónico está en peligro, pero aborda el comentario de @joachim sobre 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 en esta solución sería enviar la solicitud de acción a un administrador confiable 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 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 el usuario ingresó literalmente también coincida.

Esto le permite al usuario ingresar su contraseña secreta, pero también les 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 sin formato”.