De acuerdo con el comentario que hice sobre la pregunta:
un punto importante ha sido muy ignorado por casi todos ... Mi reacción inicial fue muy similar a @Michael Brooks, hasta que me di cuenta, como @stefanw, de que el problema aquí es requisitos rotos , pero estos son lo que son.
Pero entonces, ¡se me ocurrió que ese podría no ser el caso! El punto que falta aquí es el valor tácito de los activos de la aplicación. Simplemente hablando, para un sistema de bajo valor, un mecanismo de autenticación completamente seguro, con todo el proceso involucrado, sería excesivo, y el error elección de seguridad .
Obviamente, para un banco, las "mejores prácticas" son imprescindibles, y no hay forma de violar éticamente CWE-257. Pero es fácil pensar en sistemas de bajo valor donde simplemente no vale la pena (pero aún se requiere una contraseña simple).
Es importante recordar que la verdadera experiencia en seguridad se encuentra en encontrar compensaciones apropiadas, NO en difundir dogmáticamente las "Mejores Prácticas" que cualquiera puede leer en línea.
Como tal, sugiero otra solución:
dependiendo del valor del sistema, y SOLO SI el sistema tiene un valor apropiadamente bajo sin un activo "costoso" (la identidad en sí, incluida), Y hay requisitos comerciales válidos que hacen el proceso adecuado imposible (o lo suficientemente difícil / costoso), Y el cliente se da cuenta de todas las advertencias ...
Entonces podría ser apropiado simplemente permitir el cifrado reversible, sin aros especiales para saltar.
Me estoy deteniendo antes de decir que no se moleste en absoluto con el cifrado, porque es muy simple / barato de implementar (incluso considerando una administración de claves aceptable), y proporciona ALGUNA protección (más que el costo de implementarlo). Además, vale la pena ver cómo proporcionar al usuario la contraseña original, ya sea por correo electrónico, mostrarla en la pantalla, etc.
Dado que aquí se supone que el valor de la contraseña robada (incluso en conjunto) es bastante bajo, cualquiera de estas soluciones puede ser válida.
Dado que hay una discusión animada, en realidad VARIAS discusiones animadas, en las diferentes publicaciones y en los hilos de comentarios separados, agregaré algunas aclaraciones y responderé a algunos de los muy buenos puntos que se han planteado aquí.
Para comenzar, creo que está claro para todos aquí que permitir que se recupere la contraseña original del usuario es una mala práctica y, en general, no es una buena idea. Eso no se discute en absoluto ...
Además, enfatizaré que en muchas situaciones, más que nada, es realmente incorrecto, incluso asqueroso, desagradable y feo .
Sin embargo, el quid de la cuestión gira en torno al principio : ¿existe alguna situación en la que no sea necesario prohibir esto? De ser así, cómo hacerlo de la manera más correcta y apropiada para la situación .
Ahora, como @Thomas, @sfussenegger y algunos otros mencionaron, la única forma adecuada de responder a esa pregunta es hacer un análisis de riesgo exhaustivo de cualquier situación dada (o hipotética), para comprender qué está en juego, cuánto vale la pena proteger y qué otras mitigaciones están en juego para proporcionar esa protección.
No, NO es una palabra de moda, esta es una de las herramientas básicas y más importantes para un profesional de seguridad real. Las mejores prácticas son buenas hasta cierto punto (generalmente como pautas para los inexpertos y los piratas informáticos), después de ese punto, se hace cargo de un análisis de riesgo reflexivo.
Ya sabes, es divertido: siempre me consideré uno de los fanáticos de la seguridad, y de alguna manera estoy en el lado opuesto de los llamados "expertos en seguridad" ... Bueno, la verdad es que, porque soy un fanático, y un verdadero experto en seguridad de la vida real: no creo en decir el dogma "Best Practice" (o CWE) SIN ese análisis de riesgos tan importante .
"Tenga cuidado con el fanático de la seguridad que se apresura a aplicar todo en su cinturón de herramientas sin saber cuál es el problema real contra el que se defiende. Más seguridad no necesariamente equivale a una buena seguridad".
El análisis de riesgos y los verdaderos fanáticos de la seguridad señalarían una compensación más inteligente basada en el valor / riesgo, basada en el riesgo, la pérdida potencial, las posibles amenazas, las mitigaciones complementarias, etc. Cualquier "experto en seguridad" que no pueda señalar un análisis de riesgo sólido como el La base de sus recomendaciones, o el apoyo a las compensaciones lógicas, pero en su lugar preferirían arrojar dogmas y CWE sin siquiera comprender cómo realizar un análisis de riesgos, no son más que trucos de seguridad, y su experiencia no vale el papel higiénico en el que lo imprimieron.
De hecho, así es como obtenemos la ridiculez que es la seguridad del aeropuerto.
Pero antes de hablar sobre las compensaciones apropiadas para hacer en ESTA SITUACIÓN, echemos un vistazo a los riesgos aparentes (aparente, porque no tenemos toda la información de fondo sobre esta situación, todos tenemos la hipótesis, ya que la pregunta es qué hipotética situación podría haber ...)
Supongamos un sistema de BAJO VALOR, pero no tan trivial como el acceso público: el propietario del sistema quiere evitar la suplantación casual, pero la "alta" seguridad no es tan importante como la facilidad de uso. (Sí, es una compensación legítima ACEPTAR el riesgo de que cualquier script-kiddie competente pueda hackear el sitio ... Espera, ¿APT no está en boga ahora ...?)
Solo por ejemplo, digamos que estoy organizando un sitio simple para una gran reunión familiar, permitiendo que todos piensen en dónde queremos ir en nuestro viaje de campamento este año. Estoy menos preocupado por algún pirata informático anónimo, o incluso por el primo Fred apretando repetidas sugerencias para regresar al lago Wantanamanabikiliki, ya que estoy preocupado por que tía Erma no pueda iniciar sesión cuando lo necesite. Ahora, tía Erma, como física nuclear, no es muy buena para recordar contraseñas, ni siquiera para usar computadoras ... Así que quiero eliminar toda la fricción posible para ella. Una vez más, NO estoy preocupado por los hacks, simplemente no quiero errores tontos de inicio de sesión incorrecto; quiero saber quién vendrá y qué quieren.
De todas formas.
Entonces, ¿cuáles son nuestros principales riesgos aquí, si encriptamos simétricamente las contraseñas, en lugar de usar un hash unidireccional?
- Hacerse pasar por usuarios? No, ya he aceptado ese riesgo, no es interesante.
- Administrador malvado? Bueno, tal vez ... Pero de nuevo, no me importa si alguien puede hacerse pasar por otro usuario, INTERNO o no ... y de todos modos un administrador malintencionado obtendrá su contraseña sin importar qué , si su administrador se dañó, su juego termina de todos modos.
- Otro problema que se ha planteado es que la identidad se comparte entre varios sistemas. Ah! Este es un riesgo muy interesante, que requiere una mirada más cercana.
Permítanme comenzar afirmando que no es la identidad real la que se comparte, sino la prueba o la credencial de autenticación. De acuerdo, dado que una contraseña compartida me permitirá ingresar a otro sistema (por ejemplo, mi cuenta bancaria o gmail), esta es efectivamente la misma identidad, por lo que es solo semántica ... Excepto que no lo es . La identidad se administra por separado por cada sistema, en este escenario (aunque puede haber sistemas de identificación de terceros, como OAuth, aún así, se separa de la identidad en este sistema, más sobre esto más adelante).
Como tal, el punto central de riesgo aquí, es que el usuario ingresará voluntariamente su (misma) contraseña en varios sistemas diferentes, y ahora, yo (el administrador) o cualquier otro hacker de mi sitio tendremos acceso a las contraseñas de tía Erma para El sitio de misiles nucleares.
Hmmm
¿Te parece algo extraño?
Debería.
Comencemos con el hecho de que proteger el sistema de misiles nucleares no es mi responsabilidad , solo estoy construyendo un sitio de salida familiar para mi familia. Entonces, ¿de quién es la responsabilidad? Umm ... ¿Qué tal el sistema de misiles nucleares? Duh
Segundo, si quisiera robar la contraseña de alguien (alguien que se sabe que usa repetidamente la misma contraseña entre sitios seguros y no tan seguros), ¿por qué molestaría en hackear su sitio? ¿O luchando con su cifrado simétrico? Goshdarnitall, puedo crear mi propio sitio web simple , hacer que los usuarios se registren para recibir NOTICIAS MUY IMPORTANTES acerca de lo que quieran ... Puffo Presto, "robé" sus contraseñas.
Sí, la educación del usuario siempre regresa para mordernos en el hienie, ¿no?
Y no hay nada que puedas hacer al respecto ... Incluso si FUERAS descifrando sus contraseñas en tu sitio, y haces todo lo que la TSA pueda pensar, agregaste protección a su contraseña NO UNO MISMO , si van a mantener pegando promiscuamente sus contraseñas en cada sitio en el que se encuentran. No te molestes en intentarlo.
Dicho de otra manera, no eres dueño de sus contraseñas , así que deja de intentar actuar como lo haces.
Entonces, mis estimados expertos en seguridad, como solía preguntar una anciana por Wendy's, "¿DÓNDE está el riesgo?"
Otros pocos puntos, en respuesta a algunas cuestiones planteadas anteriormente:
- CWE no es una ley o reglamento, ni siquiera un estándar. Es una colección de debilidades comunes , es decir, el inverso de las "Mejores prácticas".
- El tema de la identidad compartida es un problema real, pero mal entendido (o tergiversado) por los detractores aquí. Se trata de compartir la identidad en sí misma (!), NO de descifrar las contraseñas en sistemas de bajo valor. Si está compartiendo una contraseña entre un sistema de bajo valor y uno de alto valor, ¡el problema ya está ahí!
- Por cierto, el punto anterior en realidad apuntaría CONTRA el uso de OAuth y similares tanto para estos sistemas de bajo valor como para los sistemas bancarios de alto valor.
- Sé que fue solo un ejemplo, pero (lamentablemente) los sistemas del FBI no son realmente los más seguros. No se parece mucho a los servidores del blog de tu gato, pero tampoco superan a algunos de los bancos más seguros.
- El conocimiento dividido, o el control dual, de las claves de cifrado NO suceden solo en el ejército, de hecho, PCI-DSS ahora requiere esto básicamente de todos los comerciantes, por lo que ya no está tan lejos (SI el valor lo justifica).
- Para todos aquellos que se quejan de que preguntas como estas son las que hacen que la profesión de desarrollador se vea tan mal: son las respuestas como esas, las que hacen que la profesión de seguridad se vea aún peor. Una vez más, el análisis de riesgos centrado en el negocio es lo que se requiere, de lo contrario te volverás inútil. Además de estar equivocado.
- Supongo que esta es la razón por la cual no es una buena idea simplemente tomar un desarrollador regular y dejar caer más responsabilidades de seguridad sobre él, sin capacitación para pensar de manera diferente y buscar las compensaciones correctas. Sin ofender, para aquellos de ustedes aquí, estoy a favor, pero se necesita más capacitación.
Uf. Qué publicación tan larga ...
Pero para responder a tu pregunta original, @Shane:
- Explique al cliente la forma correcta de hacer las cosas.
- Si todavía insiste, explique un poco más, insista, discuta. Haga un berrinche, si es necesario.
- Explíquele el RIESGO EMPRESARIAL. Los detalles son buenos, las cifras son mejores, una demostración en vivo suele ser la mejor.
- SI TODAVÍA insiste Y presenta razones comerciales válidas, es hora de que usted haga una llamada de juicio:
¿Es este sitio bajo o sin valor? ¿Es realmente un caso de negocios válido? ¿Es lo suficientemente bueno para ti? ¿No hay otros riesgos que pueda considerar que superen las razones comerciales válidas? (Y, por supuesto, el cliente NO es un sitio malicioso, pero eso es duh).
Si es así, solo adelante. No vale la pena el esfuerzo, la fricción y el uso perdido (en esta situación hipotética) para establecer el proceso necesario. Cualquier otra decisión (nuevamente, en esta situación) es una mala compensación.
Entonces, en resumen, y una respuesta real: cifrarlo con un algoritmo simétrico simple, proteger la clave de cifrado con ACL fuertes y preferiblemente DPAPI o similares, documentarla y hacer que el cliente (alguien lo suficientemente alto como para tomar esa decisión) firme eso.