¿Cómo debo abordar éticamente el almacenamiento de contraseñas de usuario para una posterior recuperación de texto plano?

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

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, son necesarias según el incendio de la ciudad. codificar.
Cliente: No te pago para que discutas. Haz lo que te pedí.

¿El arquitecto pregunta entonces cómo construir éticamente este edificio sin salidas de incendios?

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 incendios. Usted 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 programación de computadoras puede no ser una profesión con licencia, pero la gente a menudo parece preguntarse por qué nuestra profesión no recibe el mismo respeto que un ingeniero civil o mecánico - bueno, no busque más. Esas profesiones, cuando se les entrega basura (o simplemente peligrosos) requisitos, 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 él dice."Podrían perder su licencia por esa excusa.

No se si usted o sus clientes son parte de alguna compañía que cotiza en bolsa, pero almacenar contraseñas en cualquier forma recuperable causaría que fallara varios tipos diferentes de auditorías de seguridad. El problema no es lo difícil que sería para algún "hacker" que tuvo acceso a su base de datos para recuperar las contraseñas. La gran mayoría de las amenazas a la seguridad son internas. De lo que necesitas protegerte es de un empleado descontento que se va con todo las contraseñas y venderlas 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 va a haber alguien con acceso a la base de datos privada, y eso es un grave riesgo de seguridad.

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

Puede cifrar la contraseña + una sal con una clave pública. Para los inicios de sesión, compruebe si el valor almacenado es igual al valor calculado a partir de la entrada del usuario + salt. Si llega un momento en el que la contraseña debe restaurarse en texto plano, puede descifrarla manualmente o semiautomáticamente con la clave privada. La clave privada puede almacenarse en otro lugar y, además, puede cifrarse simétricamente (lo que necesitará una interacción humana para descifrar la contraseña).

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

• Las contraseñas se almacenan cifradas
• La gente puede iniciar sesión sin descifrar a texto plano
• 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 puedes usar para convencer a tus clientes es la no repudiabilidad. Si puede reconstruir contraseñas de usuario a través de cualquier mecanismo, 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 manera de que el proveedor pueda probar que no reconstruyeron la contraseña y pusieron 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, ergo ya sea el cliente final ejecutó la transacción él mismo o incumplió su deber de cuidado w. r.t. la contraseña. En cualquier caso, eso deja la responsabilidad directamente con él. He trabajado en casos en los que eso ascendería a cientos de millones de dólares. No es algo que quieras equivocarte.

No puede almacenar éticamente contraseñas para una posterior recuperación de texto plano. Es tan simple como eso. Incluso Jon Skeet no puede almacenar éticamente contraseñas para una posterior recuperación de texto plano. Si sus usuarios pueden recuperar contraseñas en texto plano de alguna manera u otra, entonces potencialmente también puede hacerlo un hacker que encuentre una vulnerabilidad de seguridad en su código. Y eso no es solo la contraseña de un usuario que está siendo comprometida, sino todas ellas.

Si sus clientes tienen un problema con eso, dígales que almacenar contraseñas recuperables es contra la ley. En cualquier caso, aquí en el Reino Unido, la Ley de Protección de Datos de 1998 (en particular, el Anexo 1, Parte II, párrafo 9) requiere que los controladores de datos utilicen las medidas técnicas adecuadas para mantener seguros los datos personales, teniendo en cuenta, entre otras cosas, el daño que podría causarse si los datos se vieran comprometidos, lo que podría ser considerable para los usuarios que comparten contraseñas entre sitios. Si todavía tienen problemas grokking el hecho de que es un problema, señalarlos para algunos ejemplos del mundo real, como este.

La forma más sencilla de permitir a los usuarios recuperar un inicio de sesión es enviarles por correo electrónico un enlace ú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éstraselo en acción.

Aquí hay un par de entradas de blog que escribí en el asunto:

• 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 empezando a ver demandas y enjuiciamientos contra empresas que no protegen las contraseñas de sus usuarios correctamente. Ejemplo: LinkedIn recibió una demanda colectiva de 5 5 millones; Sony multado con £250,000 por PlayStation data hack . Si mal no recuerdo, LinkedIn estaba cifrando 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 hice el punto de que sitios web orientados en gran medida hacia el ancianos, con problemas mentales o muy los jóvenes pueden llegar a ser confusos para las personas cuando se les pide que realicen una rutina de recuperación de contraseña segura. Aunque podemos encontrarlo simple y mundano en esos casos algunos usuarios necesitan la ayuda adicional de tener un servicio técnico les ayuda en el sistema o enviarlo por correo electrónico / mostrarlo directamente a ellos.

En tales sistemas la tasa de desgaste de estos datos demográficos podría cojear la aplicación si los usuarios no estaban dado este nivel de asistencia de acceso, así que por favor responda con tal configuración en mente.

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

Luego, el sistema está configurado para saber cuándo se ha restablecido la contraseña y mostrar un mensaje "¿desea conservar la nueva contraseña o elegir una nueva?".

¿Cómo es esto peor para los menos alfabetizados en PC que que se les diga su antigua contraseña? Y mientras que la persona de servicio al cliente puede conseguir hasta travesuras, la base de datos en sí mismo es mucho más seguro en caso de que se viole.

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 vocal sobre CWE-257 - el hecho de que cualquiera que sea el método que utilice, usted (el administrador) todavía puede recuperar la contraseña. Entonces, ¿qué tal estas opciones:

1. Cifrar la contraseña con la clave pública de otra persona - alguna autoridad externa. De esa manera no se puede reconstruir personalmente, y el usuario tendrá que ir a esa autoridad externa y pedir que se recupere su contraseña.
2. Cifrar la contraseña utilizando una clave generada de una segunda frase de contraseña. Haga este cifrado del lado del cliente y nunca lo transmita de forma transparente al servidor. Luego, para recuperarse, realice el descifrado del lado del cliente nuevamente al volver a generar la clave de su entrada. Es cierto que este enfoque es básicamente el uso de una segunda contraseña, pero siempre se puede decir que escribirlo, o utilizar el antiguo enfoque de preguntas de seguridad.

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

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

• ¿Se beneficia el usuario de que se le envíe su contraseña por correo electrónico? No. Reciben más beneficios de un enlace de restablecimiento de contraseña de un solo uso, que con suerte les permitiría elegir una contraseña ellos recordarán.
• ¿ Se beneficia el usuario de que su contraseña se muestre en la pantalla? No, por la misma razón que la anterior; deben 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 para su contraseña está correctamente autenticada, es más beneficioso para el usuario que se le dé una nueva contraseña y la oportunidad de cambiarla. Además, el soporte telefónico es más costoso que el restablecimiento automatizado 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 intención maliciosa o partidarios de API pobres que requieren el intercambio de contraseñas de terceros (por favor, no utilice dichas API nunca!). Tal vez pueda ganar su argumento declarando con veracidad a sus clientes que la compañía no obtiene beneficios y solo responsabilidades al almacenar contraseñas recuperables.

Lectura entre las líneas de este tipo de solicitudes, verá que sus clientes probablemente no entienden o incluso se preocupan en absoluto 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. Así que, además de decirles que 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:

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

Pero si, por alguna razón (y por favor díganos la razón) realmente, realmente, realmente necesita poder tener una contraseña recuperable, podría proteger al usuario de comprometer potencialmente sus otras cuentas en línea dándoles un sistema de autenticación sin contraseña. Debido a que la gente ya está familiarizada con los sistemas de nombre de usuario / contraseña y son una solución bien ejercitada, este sería un último recurso, pero seguramente hay un montón de creatividad alternativas 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 contra.
• Haga que el usuario elija una pregunta con una respuesta corta a la que solo ellos conocen la respuesta, 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 adivinanzas (ver esta ingeniosa foto de cómo el G1 hace esto para desbloquear el teléfono).
• Para un sitio web infantil, puedes generar automáticamente una criatura borrosa basada en el nombre de usuario (algo así como un identicon) y pedirle al usuario que le dé un nombre secreto a la criatura. A continuación, se les puede pedir que introduzcan el nombre secreto de la criatura para iniciar sesión.

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

Es importante recordar, la verdadera experiencia en seguridad está en encontrar las compensaciones adecuadas, NO en expresar dogmáticamente lo " Mejor 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 es apropiadamente de bajo valor sin un activo "caro" (la identidad en sí, incluida), Y hay requisitos comerciales válidos que hacen que el proceso adecuado sea imposible (o suficientemente difícil/costoso), Y el cliente es consciente de todas las advertencias...
Entonces podría ser apropiado simplemente permitir cifrado reversible, sin aros especiales para saltar.
Me estoy deteniendo justo antes de decir que no se moleste con el cifrado en absoluto, porque es muy simple / barato de implementar (incluso considerando la administración de claves pasibles), y PROPORCIONA CIERTA protección (más que el costo de implementarlo). Además, vale la pena mirar cómo proporcionar al usuario la contraseña original, ya sea por correo electrónico,mostrando en la pantalla, etc.
Dado que la suposición aquí es que el valor de la robada la contraseña (incluso en conjunto) es bastante baja, cualquiera de estas soluciones puede ser válida.

Dado que hay una animada discusión en curso, en realidad VARIAS discusiones animadas, en los diferentes mensajes y hilos de comentarios separados, agregaré algunas aclaraciones y responderé a algunos de los muy buenos puntos que se han planteado en otros lugares 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 es en absoluto objeto de controversia...
Además, voy a enfatizar que en muchas, no EN LA MAYORÍA DE LAS situaciones-es realmente incorrecto, incluso asqueroso, desagradable Y feo.

Sin embargo, el quid de la cuestión está en torno a el principio, ¿Hay alguna situación en la que no sea necesario prohibir esto, y si es así, cómo hacerlo de la manera más correcta y apropiada a la situación.

Ahora, como @Thomas, @ sfussenegger y algunos otros mencionado, la única manera adecuada de responder a esa pregunta, es hacer un análisis de riesgos a fondo 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 en vivo. Las mejores prácticas son buenas hasta cierto punto (generalmente como pautas para los inexpertos y los hacks), después de eso 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 en el lado opuesto de los llamados "Expertos en Seguridad"... Bueno, la verdad es-porque soy un fanático y un experto en seguridad de la vida real-que no creo en el dogma de las "Mejores Prácticas" (o CWEs) SIN ese importantísimo análisis de riesgos .
"Cuidado con el fanático de la seguridad que es rápido para aplicar todo en su cinturón de herramientas sin saber cuál es el problema real contra el 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 una compensación más inteligente basada en el valor/riesgo, basada en el riesgo, las pérdidas potenciales, las posibles amenazas, las mitigaciones complementarias, etc. Cualquier "Experto en seguridad" que no pueda apuntar a un análisis de riesgo sólido como base para sus recomendaciones, o apoyar compensaciones lógicas, sino que prefiera lanzar dogma y CWEs sin siquiera entender cómo realizar un análisis de riesgos, no son más que Hacks de seguridad, y su experiencia no vale la pena el papel higiénico en el que lo imprimieron.

De hecho, así es como obtenemos la ridiculez que es la Seguridad Aeroportuaria.

Pero antes de hablar de las compensaciones apropiadas para hacer en ESTA SITUACIÓN, echemos un vistazo a los riesgos aparentes (aparentes, porque no tenemos toda la información de fondo sobre esta situación, todos estamos hipotetizando - ya que la la pregunta es qué situación hipotética podría haber...)
Asumamos un sistema DE BAJO VALOR, pero no tan trival que sea de acceso público: el propietario del sistema quiere evitar la suplantación casual, pero la seguridad "alta" no es tan primordial 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, ahora no está de moda...?)
Solo por ejemplo, digamos que estoy organizando un sitio simple para una gran reunión familiar, lo que permite que todo el mundo haga una lluvia de 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 primo Fred apretando en repetidas sugerencias para volver al lago Wantanamanabikiliki, como estoy acerca de tía Aunt no ser capaz de iniciar sesión cuando ella necesita. Ahora, tía Erma, siendo física nuclear, no es muy buena para recordar contraseñas, o incluso con el uso de computadoras en absoluto... Así que quiero eliminar toda la fricción posible para ella. UNA vez más, NO estoy preocupado por los hacks, yo simplemente no quiero errores tontos de inicio de sesión incorrecto-quiero saber quién viene, y lo que quieren.

De todos modos.
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 he aceptado ese riesgo, no es interesante.
• Mal administrador? 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 malicioso va a conseguir su contraseña no importa lo que - si su administrador ha ido mal, su juego ha terminado de todos modos.
• Otra cuestión que se ha planteado, es que la identidad es realmente compartida 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 verdadera identidad la que se comparte, sino la prueba , o la credencial de autenticación. De acuerdo, ya que una contraseña compartida me permitirá efectivamente la entrada a otro sistema (por ejemplo, mi cuenta bancaria, o gmail), esto es efectivamente la misma identidad, por lo que es solo semántica... Excepto que no es. La identidad es administrada por separado por cada sistema, en este escenario (aunque podría haber sistemas de identificación de terceros, como OAuth - aún así, está separada 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 Tía Erma para el sitio de misiles nucleares.

Hmmm.

¿Algo aquí te parece raro?

Debería.

Comencemos con el hecho de que proteger el sistema de misiles nucleares no es mi responsabilidad , solo estoy construyendo un maldito sitio de salida familiar (para MI familia). Entonces de quién ES la responsabilidad? Umm... ¿Y 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 otros no tan seguros): ¿por qué me molestaría en hackear su sitio? O luchando con su cifrado simétrico? Goshdarnitall, solo puedo poner mi propio sitio web simple, hacer que los usuarios se registren para recibir NOTICIAS MUY IMPORTANTES sobre lo que quieran... Puffo Presto, "robé" sus contraseñas.

Sí, la educación del usuario siempre vuelve a mordernos en el hienie, ¿no?
Y no hay nada que puedas hacer al respecto... Incluso si tuviera que hash sus contraseñas en su sitio, y hacer todo lo demás que la TSA puede pensar, usted agregó protección a su contraseña NI UNA PIZCA, si van a mantener promiscuamente pegando sus contraseñas en cada sitio que se topan con. Ni te molestes en intentarlo.

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

Así que, mis Queridos Expertos en Seguridad, como un viejo la señora solía preguntar por Wendy's, " ¿DÓNDE está el riesgo?"

Otros puntos, en respuesta a algunas cuestiones planteadas anteriormente:

• CWE no es una ley, o regulación, o incluso un estándar. Es una colección dedebilidades comunes , es decir, el inverso de las "Mejores Prácticas".
• La cuestión de la identidad compartida es un problema real, pero mal entendido (o tergiversado) por los detractores aquí. Es una cuestión de compartir la identidad en sí misma(!), NO se trata de romper el contraseñas en sistemas de bajo valor. Si está compartiendo una contraseña entre un sistema de bajo valor y un sistema de alto valor, ¡el problema ya está ahí!
• Por cierto, el punto anterior en realidad apuntaría CONTRA usando OAuth y similares para estos sistemas de bajo valor y los sistemas bancarios de alto valor.
• Sé que fue solo un ejemplo, pero (tristemente) los sistemas del FBI no son realmente los más seguros. No se parecen mucho a los servidores del blog de tu gato, pero tampoco superan algunos de los bancos más seguros.
• El conocimiento dividido, o el control dual, de las claves de cifrado NO sucede solo en el ejército, de hecho PCI-DSS ahora requiere esto de básicamente 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 las que hacen que la profesión de seguridad se vea aún peor. Una vez más, centrado en los negocios análisis de riesgo es lo que se requiere, de lo contrario te haces inútil. Además de estar equivocado.
• Supongo que esta es la razón por la que no es una buena idea simplemente tomar un desarrollador regular y dejar más responsabilidades de seguridad en él, sin capacitación para pensar de manera diferente, y buscar las compensaciones correctas. Sin ofender, para los que están aquí, estoy a favor, pero más entrenamiento está en orden.

¡Uf. Qué post tan largo...
Pero para responder a tu pregunta original, @Shane:

• Explicar al cliente la forma correcta de hacer las cosas.
• Si todavía insiste, explique un poco más, insista, discuta. Haz una rabieta, si es necesario.
• Explíquele el RIESGO DEL NEGOCIO. Los detalles son buenos, las cifras son mejores, una demostración en vivo suele ser mejor.
• SI TODAVÍA insiste Y presenta razones de negocios válidas, es hora de que hagas una llamada de juicio:
  ¿Este sitio tiene un valor bajo o nulo? ¿Es realmente un caso de negocio válido? ¿Es lo suficientemente bueno para ti? Ser ¿no hay otros riesgos que pueda considerar, que superarían las razones comerciales válidas? (Y por supuesto, es el cliente NO un sitio malicioso, pero eso es duh).
  Si es así, adelante. No vale la pena el esfuerzo, la fricción y la pérdida de uso (en esta situación hipotética) para poner en marcha el proceso necesario. Cualquier otra decisión (de nuevo, en esta situación) es una mala compensación.

Por lo tanto, la línea de fondo, y una respuesta real-cifrar 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 senior para tomar esa decisión) la firme.

¿Qué tal un centro de rehabilitación?

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

En lugar de restablecer contraseñas, permita el envío de 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 desee (la anterior, si así lo desea).

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

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

Así que 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 la recuperación de la contraseña en el futuro.
3. Suben su PGP público clave.
4. Les pides que establezcan una nueva contraseña.
5. Envían su contraseña.
6. Usted hash la contraseña utilizando el mejor algoritmo de hash de contraseña disponible (por ejemplo, bcrypt). Use esto cuando valide el siguiente inicio de sesión.
7. Encripta la contraseña con la clave pública y la almacena por separado.

Si el usuario solicita su contraseña, usted responde con la contraseña cifrada (no con hash). Si el usuario no desea poder recuperar su contraseña en en el futuro (solo podrían restablecerlo a uno generado por el servicio), los pasos 3 y 7 se pueden omitir.

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 es una cuestión de "si" sino de "cuándo".

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

• cifrar con: openssl_encrypt (string data data, string method method, string password password)
  • Manual de PHP .
• data arg :
  • el información sensible (por ejemplo, la contraseña de usuario)
  • serializar si es necesario, por ejemplo, si la información es una matriz de datos como información sensible múltiple
• password arg : utilice una información que solo el usuario conoce como:
  • la matrícula de usuario
  • número de seguro 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 registro tiempo
• método arg :
  • elija un método de cifrado, como "aes-256-cbc"
• NUNCA almacene la información utilizada en el argumento "password" 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 pregunte 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 un dato almacenado 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. Utilice siempre una información que solo el usuario conoce o que es difícil que alguien no familiar sepa.

PS 2 : para información de tarjeta de crédito, como "one click buying", lo que hago es usar la contraseña de inicio de sesión. Esta contraseña está hash en la base de datos (sha1, md5, etc.), pero al momento de iniciar sesión almaceno la contraseña de texto sin formato en sesión o en una cookie segura no persistente (es decir, at memory). 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 haga clic en el botón "one click buying", el sistema utilizará esta contraseña. Facebook, facebook, twitter, etc. Si el usuario ha iniciado sesión con un servicio como facebook, twitter, etc., entonces vuelvo a solicitar la contraseña en el momento de la compra (ok, no es un "clic en" completo) o luego uso algunos datos del servicio que el usuario utilizó para iniciar sesión (como el id de Facebook).

Asegurar las 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 con Hash con estrictos requisitos de contraseña, las muestras de ADN y los escaneos de retina son más seguros, pero a un costo de desarrollo y experiencia del usuario. Las contraseñas de texto plano son mucho menos seguras, pero son más baratas de implementar (pero deben evitarse). Al final de el día, todo se reduce a un análisis de costo/beneficio de una brecha. La seguridad se implementa 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 único sitio web de cinco páginas de Bob, el costo podría ser insignificante. Un profesional ofrece opciones a sus clientes y, cuando se trata de seguridad, establece la ventajas y riesgos de cualquier implementación. Esto es doblemente así si el cliente solicita algo que podría ponerlos en riesgo debido a no cumplir con los estándares de la industria. Si un cliente solicita específicamente el cifrado bidireccional, me aseguraría de que documente sus objeciones, pero eso no debería impedirle implementar de la mejor manera que conoce. Al final del día, es el dinero del cliente. Sí, usted debe presionar para el uso de hashes unidireccionales, pero decir que es absolutamente la única opción y cualquier cosa lo demás no es ético es una tontería absoluta.

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, debería ver qué opciones tiene disponibles en ellas. Como otros han sugerido, puede usar cifrado asimétrico.

No existe ninguna ley (ni la Ley de Protección de Datos en el Reino Unido) de la que soy consciente de que establece específicamente que las contraseñas deben almacenarse utilizando hashes unidireccionales. El único requisito en cualquiera de estas leyes es simplemente que razonable se toman medidas de seguridad. Si el acceso a la base de datos está restringido, incluso las contraseñas de texto plano pueden calificar legalmente bajo tal restricción.

Sin embargo, esto trae a la luz un aspecto más: la precedencia legal. Si la precedencia legal sugiere que debe usar hashes unidireccionales dada la industria en el que se está construyendo su sistema, entonces eso es completamente diferente. Esa es la munición que usas para convencer a tu 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 según 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 de la pregunta de seguridad como texto sin formato (hash that en su lugar)

Me gano la vida implementando sistemas de autenticación de múltiples factores, por lo que para mí es natural pensar que puede restablecer o reconstruir la contraseña, mientras utiliza temporalmente un factor menos para autenticar al usuario solo para el flujo de trabajo de restablecimiento/recreación. En particular, el uso de OTP (contraseñas de un solo uso) como algunos de los factores adicionales, mitiga gran parte del riesgo si la ventana de tiempo es corta para el flujo de trabajo sugerido. Hemos implementado generadores OTP de software 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 plug comercial, lo que estoy diciendo es que podemos reducir los riesgos inherentes de mantener 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 los escenarios de sitios la situación todavía no es bonita, ya que el usuario insistirá en tener la contraseña original porque él / ella quiere abrir los otros sitios también, pero usted puede tratar de entregar la contraseña reconstruida de la manera más segura posible (htpps y apariencia discreta en el html).

Lo siento, 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 encontrarme con esta interesante y acalorada discusión. 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 en texto plano? ¿Por qué tiene tanto valor?

La información de que los usuarios son mayores o jóvenes realmente no responde a esa pregunta. Pero cómo una decisión del negocio se puede hacer sin la comprensión apropiada del cliente preocupación?

Ahora, ¿por qué importa? Porque si la verdadera causa de la solicitud de los clientes es el sistema que es dolorosamente difícil de usar, entonces 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 hecha:

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

Y aquí está la respuesta posible. Si tienes a cat llamada " miaumiau "y usaste su nombre como contraseña pero olvidaste que lo hiciste, ¿preferirías que te recordaran lo que era o que te enviaran algo como"#zy*RW(ew"?

Otra posible razón es que el usuario considera que es un trabajo duro para llegar a una nueva contraseña! Así que tener la antigua contraseña devuelta da la ilusión de salvarla de ese doloroso trabajo de nuevo.

Solo estoy tratando de entender la razón. Pero cualquiera que 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 inicio sesión en un sitio de noticias para leer periódicos, quiero escribir 1111 como contraseña y estar a través!!!

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, ¡el mío no! ¿El sitio muestra información privada al usuario autenticado? ¡Entonces no lo muestres en primer lugar!

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

Para resumir, no creo que sea un problema de cómo almacenar "de forma segura" contraseñas de texto sin formato (lo 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. Si lo solicita, genere un GUID en la tabla Usuarios y envíe un correo electrónico con 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 nueva contraseña.

Si necesita tener usuarios de ayuda de la línea directa, agregue algunos roles a su modelo de subvenciones y permita que el rol de la línea directa inicie sesión temporalmente como usuario identificado. Registre todos los inicios de sesión de la línea directa. Por ejemplo, Bugzilla ofrece esta función de suplantación a los administradores.

¿Qué hay de enviar por correo electrónico la contraseña de texto plano al registrarse, antes de cifrarla 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/borrador.

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

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

El una 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 de servicio al cliente, tal vez pueda deshacerse de ella.

¿Realmente necesitan los usuarios recuperar (por ejemplo, que se les diga) cuál era 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 antigua (lo que sea) a una nueva contraseña que la persona de soporte puede dar a la persona que perdió su contraseña?

He trabajado con sistemas que hacen exactamente esto. La persona de apoyo no tiene forma de saber lo que la corriente contraseña es, pero puede restablecer 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 clave maestra/esqueleto que solo conoce el personal de soporte y es la misma para todos los usuarios. De esa manera cuando un usuario tiene un problema la persona de soporte puede iniciar sesión en la cuenta con la clave maestra y ayudar al usuario a cambiar su contraseña a lo que sea. No hace falta decir que todos los inicios de sesión con la clave maestra también deben ser registrados por el sistema. Como medida adicional, siempre que se use la clave maestra, también podría validar las credenciales de support persons.

- EDIT-En respuesta a los comentarios sobre no tener una clave maestra: Estoy de acuerdo en que es malo al igual que creo que es malo permitir que alguien 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 tiene por qué 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 pusieron la contraseña especial en un sobre sellado y la pegaron al escritorio del operador. Para utilizar la contraseña (que el operador no lo sabía) tuvo que abrir el sobre. En cada cambio de turno uno de los trabajos del supervisor de turno era ver si el sobre había sido abierto y si es así inmediatamente tener la contraseña cambiada (por otro departamento) y la nueva contraseña fue puesta en un nuevo sobre y el proceso comenzó de nuevo. El operador tendría que preguntar a los encuestados por qué había abierto y que el incidente sería documentado para el registro.

Si bien este no es un procedimiento que diseñaría, funcionó y proporcionó una excelente rendición de cuentas. Todo fue registrado y revisado, además de que todos los operadores tenían autorizaciones secretas del Departamento de Defensa y nunca tuvimos ningún abuso.

Debido a la revisión y supervisión, todos los operadores sabían que si abusaban del privilegio de abrir el sobre estaban sujetos a despido inmediato y posible procesamiento 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, hacer verificaciones de antecedentes y ejercer una supervisión y rendición de cuentas adecuadas en materia de gestión.

Pero, de nuevo, si el cliente de este pobre tipo tenía una buena gestión, no habrían pedido una solución de seguridad comprimida en primer lugar, ¿lo harían?

Por lo poco que entiendo sobre este tema, creo que si está construyendo un sitio web con un signon/contraseña, entonces ni siquiera debería ver la contraseña de texto plano en su servidor. La contraseña debe ser hash, y probablemente salado, incluso antes de que salga del cliente.

Si nunca ves la contraseña de texto plano, entonces la cuestión de la recuperación no surge.

Además, deduzco (de la web) que (supuestamente) algunos algoritmos como MD5 ya no son considerado seguro. 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 cifrada 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.
dé 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émosla "pass-a") como lo hace la gente normal:)
en cada nuevo usuario o contraseña cambiar) almacene una copia simple de la contraseña en la base de datos remota. utilice el id del servidor, el ID 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 tanto la contraseña como su contexto (id del sitio + id del usuario + "pass-a"), tiene que:

1. hackear la base de datos del sitio web para obtener un par o pares ("pass-a", id de usuario).
2. obtenga el id del sitio web de alguna configuración file
3. encuentra y hackea la base de datos de contraseñas remotas.

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 cobran extra por este "acuerdo de seguridad especial".
El servidor DB de recuperación de contraseñas está bastante oculto, ya que no cumple muchas funciones y puede estar mejor protegido (puede personalizar los permisos, procesos y servicios estrictamente).

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

Otra opción que puede no haber 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). El registro debe incluir un correo electrónico.
2. Si se necesitan datos o una acción y el usuario no recuerde su contraseña, todavía pueden realizar la acción por al hacer clic en un botón especial " envíame un correo electrónico para obtener permiso", justo al lado del botón regular " 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. El usuario luego hace clic en "Sí", y confirma que los datos deben mostrarse, o la acción debe realizarse, datos revelado, etc.

Como mencionaste en los comentarios, esto no funcionará si el correo electrónico está comprometido, pero sí responde al 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 a esta solución sería enviar la solicitud de acción a un administrador de confianza de terceros. Esto funcionaría mejor en casos con personas mayores, con problemas mentales, muy jóvenes o usuarios confusos. Por supuesto, esto requiere un administrador de confianza para que estas personas apoyen sus acciones.

Salte y 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 salar / hashing), sino también permitir que lo que el usuario, literalmente, entró para que coincida también.

Esto le 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 salted/hashed sea también una contraseña de "texto plano".