Pregunta ¿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 programació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 codificación, 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 resto obtuvo un +1. ¡Gracias a todos!

También, gracias a todos en la comunidad de Stack que votaron por esta pregunta y / o la marcaron como favorita. 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.


1346
2018-02-17 19:54


origen


Respuestas:


¿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 necesidad de poder darles una contraseña que puedo 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. Ver el Preguntas frecuentes sobre Diceware para 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.


1039
2018-02-28 08:16



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 emergencia aquí, aquí y aquí.
Cliente:  No, eso es demasiado complicado y costoso de mantener, no quiero puertas laterales ni puertas traseras.
Arquitecto:  Señor, las salidas de incendios 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 programación de computadoras puede no ser una con licencia profesión, 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 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 va a haber alguien con acceso a la base de datos privada, y eso es un serio riesgo de seguridad.

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


593
2018-02-18 16:05



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 en realidad algo similar a la forma en que Agente de recuperación de Windows trabajos.

  • 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).

206
2018-02-17 20:07



No te rindas. El arma que puede usar para convencer a sus clientes es la no repudiabilidad. Si puede reconstruir contraseñas de usuario a través de cualquier mecanismo, ha dado su los clientes son 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 que la transacción se realice a través de ellos mismos. Si las contraseñas se almacenan correctamente como resúmenes en lugar de texto cifrado, esto es imposible, ya sea que el cliente final haya ejecutado la transacción él mismo o haya incumplido 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 equivaldría a cientos de millones de dólares. No es algo que quieras equivocarte.


134
2018-02-18 09:59



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 todos ellos.

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 éste.

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:

Actualizar: ahora estamos empezando a ver demandas y enjuiciamientos contra compañías que no aseguran adecuadamente las contraseñas de sus usuarios. Ejemplo: LinkedIn abofeteó con una demanda colectiva de $ 5 millones; Sony multa 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.


95
2018-02-23 15:20



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 ser 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 ayuda adicional de cualquiera de tener   un técnico de servicio les ayuda en el   sistema o tenerlo enviado por correo electrónico   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 eran   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 exige un sistema de contraseña recuperable. Por ejemplo: La tía Mabel llama y dice "Tu programa de internet no funciona, no sé mi contraseña". "OK", dice el servicio al cliente zumbido "déjame revisar algunos detalles y luego voy a darle una nueva contraseña. La próxima vez que inicie sesión, le preguntará si desea mantener esa contraseña o cambiarla a 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 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.


55
2018-02-25 11:27



Michael Brooks ha sido bastante elocuente 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. Encriptar la contraseña con de alguien más Llave pública - 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!


42
2018-02-18 13:56



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 ahora, 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 con suerte les permitiría elegir una contraseña que será recuerda.
  • ¿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 puedas ganar tu argumento diciendo sinceramente a tus 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 eso no es 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 usted, por alguna razón (y por favor díganos el motivo) realmente realmente realmente Necesita poder tener una contraseña recuperable, puede proteger al usuario de comprometer potencialmente sus otras cuentas en línea dándoles un sistema de autenticación sin contraseña. 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 intentos 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 evitar las suposiciones (vea esta foto ingeniosa 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.

28
2018-02-27 20:10



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 lo que no se habla valor 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 incorrecto 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 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 ningún activo "costoso" (la identidad misma, incluida), Y existen requisitos comerciales 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á alrededor el principio, ¿Hay alguna situación en la que no sea necesario? para prohibir esto, y si es así, cómo hacerlo en el la forma más correcta adecuada a la situación.

Ahora, como @Thomas, @sfussenegger y algunos otros mencionaron, la única forma correcta de responder esa pregunta es hacer un análisis de riesgo de cualquier situación dada (o hipotética), para entender qué 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 verdadero experto en seguridad de la vida real: no creo en lanzar un dogma de "mejores prácticas" (o CWEs) SIN ese importantísimo análisis de riesgo.
"Tenga cuidado con el fanático de la seguridad que se apresura a aplicar todo en su cinturón de herramientas sin saber cuál es el 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 ...)
Asumamos 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 no importa qué - Si tu administrador se ha vuelto malo, se termina el juego de todos modos.
  • 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 el real identidad eso es compartido, más bien el 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 solo es semántica ... Excepto que no 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 es no es mi responsabilidad, 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 aguantar mi propio sitio web simple, haga 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 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 la TSA, agregaste protección a su contraseña. NINGUNO WHIT, si van a mantener constantemente sus contraseñas en cada sitio con el que tropiecen. Ni siquiera te molestes en intentarlo.

Dicho de otra manera, Usted no posee sus contraseñas, así que deja de tratar de actuar como lo haces.

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 cierto, el punto anterior en realidad señalaría EN CONTRA usando OAuth y similares para estos sistemas de bajo valor y 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 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 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.


25
2018-02-23 15:01