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


1344

A medida que continúo construyendo más y más sitios web y aplicaciones web, a menudo se me pide que almacene las contraseñas de los usuarios de manera que puedan recuperarse si el usuario tiene un problema (ya sea para enviar por correo electrónico un enlace de contraseña olvidado, guíelo a través del teléfono, etc.) Cuando puedo, lucho amargamente contra esta práctica y hago mucha programación 'extra' para hacer posible el restablecimiento de contraseñas y la asistencia administrativa sin almacenar su contraseña real.

Cuando no puedo combatirlo (o no puedo ganar), siempre codifico la contraseña de alguna manera para que, al menos, no se almacene como texto sin formato en la base de datos, aunque sé que si mi base de datos se piratea el culpable no tardaría mucho en descifrar las contraseñas, por lo que me siento incómodo.

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

Moral y éticamente me siento responsable de proteger lo que puede ser, para algunos usuarios, su medio de vida, incluso si lo tratan con mucho menos respeto. Estoy seguro de que hay muchas vías para abordar y argumentos para formular salsas y diferentes opciones de codificación, pero ¿hay una única 'mejor práctica' cuando tiene que almacenarlas? En casi todos los casos estoy usando PHP y MySQL si eso hace alguna diferencia en la forma en que debo manejar los detalles.

Información adicional para Bounty

Quiero aclarar que sé que esto no es algo que quiera hacer y que, en la mayoría de los casos, lo mejor es negarse a hacerlo. Sin embargo, no estoy buscando una conferencia sobre los méritos de adoptar este enfoque. Estoy buscando los mejores pasos a seguir si usted adopta este enfoque.

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

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

Gracias a todos

Esta ha sido una pregunta divertida con mucho debate y la he disfrutado. Al final, seleccioné una respuesta que conserva la seguridad de la contraseña (no tendré que guardar texto plano o contraseñas recuperables), pero también hace posible que la base de usuarios que especifiqué inicie sesión en un sistema sin los inconvenientes principales que he encontrado recuperación de contraseña normal

Como siempre, hubo alrededor de 5 respuestas que me gustaría haber marcado como correctas por diferentes razones, pero tuve que elegir la mejor, el resto obtuvo un +1. ¡Gracias a todos!

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


155
Creo que él sabe que no es bueno. Todavía está buscando la mejor solución bajo los requisitos establecidos.
stefanw

33
Al final del día, todo lo que hará será implementar cuidadosamente una vulnerabilidad evitable.
torre

20
@Michael Brooks: quiero que sepa que estoy totalmente de acuerdo con CWE-257 y me encantaría citar textualmente cada vez que se me pide que haga que las contraseñas sean recuperables como texto sin formato. Sin embargo, en realidad, los clientes y usuarios rara vez están interesados ​​en las regulaciones NIST y solo quieren que lo haga de todos modos. El 90% de las veces puedo convencerlos de lo contrario, pero en ese 10% de las veces cuando no puedo, estoy tratando de determinar el mejor curso de acción; en esos casos, CWE-257 es cenizas en mi mano (desafortunadamente).
Shane

81
@AviD: El "bajo valor" del sistema no tiene absolutamente ninguna relación con este problema porque las personas reutilizan sus contraseñas . ¿Por qué la gente no puede entender este simple hecho? Si descifra las contraseñas en algún sistema de "bajo valor", es probable que tenga varias contraseñas válidas para otros sistemas de "alto valor".
Aaronaught

20
También se ha pasado por alto otro punto, que acabo de mencionar en la secuencia de comentarios a mi respuesta: ¿Cómo sabe que la persona que solicita estos requisitos es confiable? ¿Qué pasa si la excusa de "usabilidad" es solo una fachada que enmascara una intención real de robar las contraseñas en algún momento en el futuro? Su ingenuidad puede haber costado millones de clientes y accionistas. ¿Cuántas veces deben repetir esto los expertos en seguridad antes de que finalmente se hunda? Las amenazas de seguridad más comunes y más graves son siempre INTERNAS.
Aaronaught

Respuestas:


1037

¿Qué tal tomar otro enfoque o ángulo en este problema? Pregunte por qué se requiere que la contraseña esté en texto sin formato: si es para que el usuario pueda recuperar la contraseña, entonces, estrictamente hablando, realmente no necesita recuperar la contraseña que estableció (de todos modos, no recuerda cuál es). necesitan poder darles una contraseña que puedan usar .

Piénselo: si el usuario necesita recuperar la contraseña, es porque la ha olvidado. En cuyo caso, una nueva contraseña es tan buena como la anterior. Pero, uno de los inconvenientes de los mecanismos comunes de restablecimiento de contraseña utilizados hoy en día es que las contraseñas generadas producidas en una operación de restablecimiento generalmente son un montón de caracteres aleatorios, por lo que es difícil para el usuario simplemente escribir correctamente a menos que copien pegar. Eso puede ser un problema para los usuarios de computadoras menos inteligentes.

Una forma de evitar ese problema es proporcionar contraseñas generadas automáticamente que sean texto de lenguaje más o menos natural. Si bien las cadenas de lenguaje natural pueden no tener la entropía que tiene una cadena de caracteres aleatorios de la misma longitud, no hay nada que diga que su contraseña generada automáticamente debe tener solo 8 (o 10 o 12) caracteres. Obtenga una frase de contraseña autogenerada de alta entropía al unir varias palabras aleatorias (deje un espacio entre ellas, de modo que puedan ser reconocibles y escribibles por cualquiera que pueda leer). Seis palabras aleatorias de longitud variable son probablemente más fáciles de escribir correctamente y con confianza que 10 caracteres aleatorios, y también pueden tener una entropía más alta. Por ejemplo, la entropía de una contraseña de 10 caracteres extraída al azar de mayúsculas, minúsculas, dígitos y 10 símbolos de puntuación (para un total de 72 símbolos válidos) tendrían una entropía de 61.7 bits. Usando un diccionario de 7776 palabras (como Diceware usa) que podría seleccionarse aleatoriamente para una frase de contraseña de seis palabras, la frase de contraseña tendría una entropía de 77.4 bits. Ver elPreguntas frecuentes sobre Diceware para más información.

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

  • una contraseña con aproximadamente 74 bits de entropía: "K: & $ R ^ tt ~ qkD"

Sé que preferiría escribir la frase, y con copiar y pegar, la frase no es menos fácil de usar que la contraseña tampoco, por lo que no hay pérdida allí. Por supuesto, si su sitio web (o lo que sea el activo protegido) no necesita 77 bits de entropía para una frase de contraseña generada automáticamente, genere menos palabras (lo que estoy seguro de que sus usuarios apreciarían).

Entiendo los argumentos de que hay activos protegidos por contraseña que realmente no tienen un alto nivel de valor, por lo que la violación de una contraseña podría no ser el fin del mundo. Por ejemplo, probablemente no me importaría si se violara el 80% de las contraseñas que uso en varios sitios web: todo lo que podría suceder es que alguien envíe spam o publique bajo mi nombre por un tiempo. Eso no sería genial, pero no es como si entraran a mi cuenta bancaria. Sin embargo, dado el hecho de que muchas personas usan la misma contraseña para sus sitios de foros web como lo hacen para sus cuentas bancarias (y probablemente bases de datos de seguridad nacional), creo que sería mejor manejar incluso esas contraseñas de "bajo valor" como no -recuperable.


93
+1 para frases de contraseña, que actualmente parecen ofrecer el mejor equilibrio entre la seguridad de la contraseña y la recuperación del usuario.
Aaronaught

197
También puede hacer una oración completa, por ejemplo, <adjetivo> <noun> es <verb> <adverb>. El gato verde está saltando salvajemente. tener listas para las categorías. Con 1024 opciones para cada uno tiene 40 bits de entropía.
Dominik Weber

28
+1 por considerar la reutilización de la contraseña como un problema crítico para evitarla
lurscher el

57
"Piénselo, si el usuario necesita recuperar la contraseña, es porque la ha olvidado", ¡no necesariamente es cierto! A menudo quiero obtener mi contraseña porque estoy en la computadora portátil, y sé que mi máquina en casa tiene mi contraseña almacenada, o está escrita en un lugar seguro, y no quiero romperla al obtener una nueva. .
joachim

55
La pregunta con el puntaje más alto en el nuevo sitio de IT Security SE trata sobre la validez de este cálculo de entropía. (Bueno, técnicamente, se trata de la xkcd que @Pieter vinculado.)
Pops

592

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

Arquitecto: Para un edificio de este tamaño y capacidad, necesitará salidas de emergencia aquí, aquí y aquí.
Cliente: No, eso es demasiado complicado y costoso de mantener, no quiero puertas laterales o puertas traseras.
Arquitecto: Señor, las salidas de emergencia no son opcionales, se requieren según el código de incendios de la ciudad.
Cliente: No te pago por discutir. Solo haz lo que te pedí.

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

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

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

La programación de computadoras puede no ser una profesión con licencia , pero las personas a menudo parecen preguntarse por qué nuestra profesión no recibe el mismo respeto que un ingeniero civil o mecánico, bueno, no busque más. Esas profesiones, cuando se entregan requisitos de basura (o directamente peligrosos), simplemente se negarán. Saben que no es una excusa para decir, "bueno, hice lo mejor que pude, pero él insistió, y tengo que hacer lo que dice". Podrían perder su licencia por esa excusa.

No sé si usted o sus clientes son o no parte de una empresa que cotiza en bolsa, pero el almacenamiento de contraseñas en cualquier forma recuperable podría hacer que falle varios tipos diferentes de auditorías de seguridad. El problema no es cuán difícil sería para algunos "hackers" que obtuvieron acceso a su base de datos para recuperar las contraseñas. La gran mayoría de las amenazas de seguridad son internas. De lo que necesita protegerse es de algún empleado descontento que se va con todas las contraseñas y las vende al mejor postor. El uso de cifrado asimétrico y el almacenamiento de la clave privada en una base de datos separada no hace absolutamente nada para evitar este escenario; siempre habrá alguien con acceso a la base de datos privada, y ese es un grave riesgo de seguridad.

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


124
@Aaronaught: creo que es un punto justo y válido, pero déjame decirte eso. Usted está trabajando en un proyecto para una empresa como empleado y su jefe dice "este es un requisito de nuestro sistema" (por cualquier razón). ¿Dejas el trabajo lleno de justa indignación? Sé que hay una obligación cuando tengo el control total de ser responsable, pero si una empresa decide arriesgarse a fallar en las auditorías o en la responsabilidad, entonces es mi deber sacrificar mi trabajo para probar un punto, o busco lo MEJOR ¿Y la forma MÁS SEGURA de hacer lo que dicen? Solo estoy jugando al abogado del diablo ..
Shane

44
No soy abogado, pero considera esto. Si su supervisor le ordena que haga algo en contra de los intereses de la empresa, como exponerlos a una responsabilidad fácilmente evitada, ¿es su trabajo obedecer o rechazar cortésmente? Sí, son tu jefe, pero tienen un jefe propio, incluso si son los inversores. Si no pasas por encima de ellos, ¿quién va a rodar cuando se explote tu agujero de seguridad? Solo algo a tener en cuenta.
Steven Sudit

68
Los desarrolladores siempre intentan decir cómo nuestros trabajos son mucho más difíciles que otros porque tenemos requisitos de basura que cambian todo el tiempo. Bueno, este es un ejemplo perfecto de por qué; Nuestra profesión necesita desesperadamente una columna vertebral. Nuestra profesión necesita desesperadamente poder decir "no, este no es un requisito aceptable, no es algo que pueda desarrollar de buena fe, usted puede ser mi cliente / empleador pero tengo responsabilidades profesionales hacia sus clientes y el público, y si quieres hacer esto, tendrás que buscar en otro lado ".
Aaronaught

36
@sfussenegger: No necesitas saber el fondo. Es inaceptable Supone que el cliente es 100% confiable, ¿qué sucede si solicita este requisito específicamente para poder quitar las contraseñas más tarde? La seguridad es uno de los pocos elementos en desarrollo que están tallados en piedra. Hay algunas cosas que simplemente no hace, y almacenar diez contraseñas recuperables es diez de ellas.
Aaronaught

37
Bien, hagamos una evaluación de riesgos, aquí y ahora. "Si almacena las contraseñas en una forma recuperable, está creando un riesgo no trivial de robo de contraseñas. También es probable que al menos algunos usuarios usen las mismas contraseñas para su correo electrónico y cuentas bancarias. Si se roban las contraseñas. y las cuentas bancarias se agotan, es probable que aparezca en los titulares, nadie volverá a hacer negocios con usted y probablemente será demandado fuera de existencia ". ¿Podemos cortar la mierda ahora? El hecho de que hayas introducido la palabra "nazis" en esto muestra claramente que no tienes sentido de la razón.
Aaronaught

206

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

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

  • Las contraseñas se almacenan encriptadas
  • Las personas pueden iniciar sesión sin descifrar en texto sin formato
  • Las contraseñas se pueden recuperar en texto plano, pero solo con una clave privada, que se puede almacenar fuera del sistema (en una caja fuerte del banco, si lo desea).

34
-1 las contraseñas nunca deben "encriptarse" Es una violación de CWE-257 cwe.mitre.org/data/definitions/257.html
rook

100
1. La pregunta indicaba que la contraseña debería ser recuperable en texto plano, por lo que este es un requisito. 2. Estoy usando cifrado asimétrico aquí y no cifrado simétrico. La clave para descifrar no es necesaria para las operaciones diarias y se puede guardar en un banco seguro. La argumentación en el enlace es válida, pero no se aplica a esta situación.
stefanw

57
Es cierto, pero ¿podría aceptar que, dados los requisitos, esta es la forma más responsable de hacerlo? Puede golpearme todo el día con su CWE-257, no va a cambiar el interesante problema de almacenar y trabajar con credenciales de forma segura y poder recuperarlos a su forma original si es necesario.
stefanw

10
El Agente de recuperación de Windows también es un mal ejemplo aquí, ya que se ocupa del cifrado real, no de la administración de contraseñas. Una clave de cifrado no es lo mismo que una contraseña; Las reglas y prácticas que rodean a cada una son completamente diferentes. El cifrado y la autenticación no son lo mismo. El cifrado es para la privacidad : se usa una clave para proteger los datos . La autenticación es para la identidad , donde la clave son los datos (es un factor en el proceso de autenticación). Así que repito, el cifrado y la autenticación no son lo mismo. No puede aplicar válidamente los principios de uno al otro.
Aaronaught

16
+1 ¿Dónde está el punto de insistir obsesivamente en CWE-257? Es una debilidad (CWE), no una vulnerabilidad (CVE). Comparar contraseñas recuperables con desbordamientos de búfer es comparar manzanas y naranjas. Simplemente asegúrese de que el cliente comprenda el problema (permítale firmar algo que lo diga; de lo contrario, es posible que no recuerde nada si tiene alguna duda) y continúe. Además, las medidas de seguridad requeridas dependen del valor del sistema y del riesgo potencial de un ataque. Si un atacante exitoso solo puede cancelar algunas suscripciones a boletines, no hay razón para discutir sobre algún problema.
sfussenegger

133

No te rindas El arma que puede usar para convencer a sus clientes es la no repudiabilidad. Si puede reconstruir las contraseñas de los usuarios a través de cualquier mecanismo, le ha dado a sus clientes un mecanismo legal de no repudio y pueden repudiar cualquier transacción que dependa de esa contraseña, porque no hay forma de que el proveedor pueda probar que no reconstruyeron la contraseña y pasar la transacción a través de ellos mismos. Si las contraseñas se almacenan correctamente como resúmenes en lugar de texto cifrado, esto es imposible, por lo tanto, el cliente final ejecutó la transacción él mismo o incumplió su deber de cuidado con la contraseña. En cualquier caso, eso deja la responsabilidad directamente con él. He trabajado en casos en los que eso equivaldría a cientos de millones de dólares. No es algo que quieras equivocarte.


2
¿Los registros del servidor web no cuentan en un tribunal? ¿O en este caso se supondría que también eran falsos?
Vinko Vrsalovic

10
@Vinko Vrsalovic, los registros del servidor web NO DEBEN contar en el tribunal, para hacerlo debe demostrar que no repudia, prueba de autenticidad, cadena de evidencia, etc., que los registros del servidor web claramente no son.
AviD

77
Exactamente. El proveedor tiene que demostrar que solo el cliente pudo haber realizado esa transacción. Un registro del servidor web no hace eso.
Marqués de Lorne

No todas las contraseñas son realmente necesarias para "transacciones", por así decirlo. Digamos que el sitio web es para desarrollar una lista de marcadores de páginas web. En este caso, el límite de responsabilidad (que generalmente se menciona en los términos y condiciones al registrarse en el sitio web) es cero, porque no hay una transacción financiera. Si el sitio web no tiene acciones que afecten a otros, como máximo, los datos se pierden para el usuario pirateado. La empresa está protegida por los términos y condiciones.
Sablefoste

1
@Sablefoste En ese sitio web. Si el usuario usa la misma contraseña en otro lugar, está creando el riesgo de filtrar sus credenciales privadas. Si nunca participa en la práctica, no puede causar el problema.
Marqués de Lorne

94

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

Si sus clientes tienen un problema con eso, dígales que almacenar contraseñas de manera recuperable es ilegal. En cualquier caso, en el Reino Unido, la Ley de Protección de Datos de 1998 (en particular, el Anexo 1, Parte II, Párrafo 9) requiere que los controladores de datos utilicen las medidas técnicas apropiadas para mantener la seguridad de los datos personales, teniendo en cuenta, entre otras cosas, la daño que podría causar si se comprometieran los datos, lo que podría ser considerable para los usuarios que comparten contraseñas entre sitios. Si todavía tienen problemas para asimilar el hecho de que es un problema, indíqueles algunos ejemplos del mundo real, como este .

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

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

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


8
@jimmycakes: es bueno hacerlo en un sistema de baja seguridad, pero si está almacenando datos de alto valor, entonces debe suponer que el correo electrónico de las personas ya está comprometido y que enviarles un enlace de inicio de sesión directo compromete su sistema. +1 por responder a mi pregunta con una alternativa factible, pero señalando una falla en la lógica en su conjunto. No quiero que Payppal envíe un enlace de inicio de sesión directo NUNCA. Puede sonar paranoico, pero siempre asumo que mi cuenta de correo electrónico está corrupta, me mantiene honesto. ;)
Shane

Absolutamente: esperaría que mi banco al menos me llame y verifique mi identidad antes de permitirme restablecer ( no recuperar) mi contraseña. Lo que he descrito aquí es el estándar mínimo absoluto de seguridad de contraseña que esperaría de cualquier sitio web, en cualquier lugar.
jammycakes

1
Ignorando al banco o paypal que de todos modos no tendrían la restricción establecida; Si supone que su correo electrónico está comprometido, ¿cómo es posible algún método en línea? Si envía por correo electrónico una contraseña generada, ¿cómo es eso más seguro?
Peter Coulton el

No estoy hablando de obtener la contraseña de un solo individuo, estoy hablando de obtener múltiples contraseñas de una base de datos. Si un sistema almacena las contraseñas de forma recuperable en texto sin formato, un hacker puede potencialmente escribir un script para extraer todas las contraseñas de su base de datos.
jammycakes

Me pregunto sobre el envío de un enlace / contraseña en un correo electrónico, pasando por la red en forma simple a través de nodos de red desconocidos ...
Jakub

55

Después de leer esta parte:

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

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

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

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

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

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


44
@john - Creo que es una solución perfectamente viable. ¡Prepárate para ser criticado por amenazas internas! Sabes, si tuviera que hacer esto con un restablecimiento de contraseña intermedio (el técnico establece la contraseña manualmente como una mesa temporal y le dice a Mabel que escriba 1234 como su contraseña), entonces probablemente funcionaría bien en un sistema que no contiene datos importantes. Si se tratara de un entorno de alta seguridad, entonces tenemos un problema en el que el servicio de atención al cliente puede establecer la contraseña del CEO en 1234 e iniciar sesión directamente. No existe una solución perfecta, pero esta funciona en muchos casos. (+1)
Shane

55
Acabo de notar esta respuesta. @ Shane, no entiendo por qué pronosticaste un incendio sobre "amenazas internas". La capacidad de cambiar una contraseña no es una debilidad notable; el problema es la capacidad de descubrir una contraseña que probablemente se utilizará para otros servicios: su correo electrónico, su banco, sus sitios de compras en línea que tienen almacenada su información de CC. Esa debilidad no se manifiesta aquí; si Bob restablece la contraseña de Mabel y se la cuenta por teléfono, eso no le da acceso a ninguna de sus otras cuentas. Sin embargo, forzaría en lugar de "sugerir" un restablecimiento de contraseña al iniciar sesión.
Aaronaught

@Aaronaught: entiendo su punto de vista, pero en lo que estoy pensando es en momentos en que incluso la gente del servicio al cliente está bloqueada en ciertas áreas de un sistema (como nómina, contabilidad, etc.) y permitirles establecer una contraseña directamente es Un problema de seguridad en sí mismo. Sin embargo, sí entiendo que el tipo de sistema sobre el que hice esta pregunta difiere en gran medida de un sistema de contabilidad interno. Probablemente podríamos tener una discusión completamente diferente sobre los sistemas internos propietarios y la seguridad de las contraseñas.
Shane

1
@Shane: Entonces la pregunta tiene aún menos sentido. Supuse que querías que alguien le leyera una contraseña por teléfono. Si desea enviar por correo electrónico a los usuarios sus contraseñas a través de un sistema de autoservicio automatizado, también podría prescindir de la contraseña por completo porque está "protegida" con algo mucho más débil. Tal vez necesite ser mucho más específico sobre exactamente qué tipo de escenarios de usabilidad está tratando de soportar. Tal vez ese análisis le muestre posteriormente que las contraseñas recuperables ni siquiera son necesarias.
Aaronaught

44
El código proporcionado por la persona de soporte no tiene que ser literalmente la nueva contraseña. Puede ser un código único que desbloquea la función de restablecimiento de contraseña.
kgilpin

42

Michael Brooks ha sido bastante expresivo sobre CWE-257: el hecho de que sea cual sea el método que utilice, usted (el administrador) aún puede recuperar la contraseña. Entonces, ¿qué hay de estas opciones:

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

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


8
Y, por supuesto, podría usar cualquier técnica de separación secreta para requerir que alguien de su empresa sea descifrado. Pero nada de eso cumple con los requisitos originales de poder enviar sus contraseñas a un usuario o hacer que un partidario de teléfono de primer nivel que no
esté listo lo guíe

27

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

  • ¿Se beneficia el usuario de recibir su contraseña por correo electrónico? No. Ellos reciben más beneficios de un enlace de restablecimiento de contraseña de un solo uso, que se espera pueda permitirles elegir una contraseña que le recuerde.
  • ¿Se beneficia el usuario de mostrar su contraseña en la pantalla? No, por la misma razón que arriba; deberían elegir una nueva contraseña.
  • ¿Se beneficia el usuario de que una persona de soporte le diga la contraseña al usuario? No; De nuevo, si la persona de soporte considera que la solicitud del usuario de su contraseña está debidamente autenticada, es más beneficioso para el usuario recibir una nueva contraseña y la oportunidad de cambiarla. Además, la asistencia telefónica es más costosa que el restablecimiento automático de contraseñas, por lo que la empresa tampoco se beneficia.

Parece que los únicos que pueden beneficiarse de las contraseñas recuperables son aquellos con intenciones maliciosas o partidarios de API deficientes que requieren el intercambio de contraseñas de terceros (¡por favor, no use dichas API nunca!). Quizás pueda ganar su argumento declarando sinceramente a sus clientes que la compañía no obtiene beneficios y solo responsabilidades al almacenar contraseñas recuperables .

Al leer entre líneas de este tipo de solicitudes, verá que sus clientes probablemente no entiendan o realmente no se preocupen en absoluto sobre cómo se administran las contraseñas. Lo que realmente quieren es un sistema de autenticación que no sea tan difícil para sus usuarios. Entonces, además de decirles cómo en realidad no quieren contraseñas recuperables, debe ofrecerles formas de hacer que el proceso de autenticación sea menos doloroso, especialmente si no necesita los altos niveles de seguridad de, por ejemplo, un banco:

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

Pero si usted, por alguna razón (y por favor díganos la razón) realmente, realmente, realmente necesita poder tener una contraseña recuperable, podría proteger al usuario de comprometer potencialmente sus otras cuentas en línea dándoles una contraseña no sistema de autenticación basado Debido a que las personas ya están familiarizadas con los sistemas de nombre de usuario / contraseña y son una solución bien ejercida, este sería un último recurso, pero seguramente hay muchas alternativas creativas a las contraseñas:

  • Deje que el usuario elija un pin numérico, preferiblemente no de 4 dígitos, y preferiblemente solo si los intentos de fuerza bruta están protegidos.
  • Haga que el usuario elija una pregunta con una respuesta breve que solo ellos conozcan, nunca cambiará, siempre recordarán y no les importa que otras personas se enteren.
  • Haga que el usuario ingrese un nombre de usuario y luego dibuje una forma fácil de recordar con suficientes permutaciones para protegerse contra las conjeturas (vea esta ingeniosa foto de cómo el G1 hace esto para desbloquear el teléfono).
  • Para el sitio web de un niño, podrías generar automáticamente una criatura difusa basada en el nombre de usuario (algo así como un identicon) y pedirle al usuario que le dé un nombre secreto a la criatura. Luego se les puede solicitar que ingresen el nombre secreto de la criatura para iniciar sesión.

Respondí a los comentarios aquí, en mi respuesta, ya que fue bastante largo, creo que es importante revisar el análisis y la discusión de los problemas planteados. stackoverflow.com/questions/2283937/…
AviD

¿Se beneficia el usuario de mostrar su contraseña en la pantalla? En mi opinión, ¡definitivamente sí! Cada vez que obtengo una contraseña oscura de Internet, agradezco a Apple que puedo hacerla visible para no tener que volver a escribirla 100 veces con dolor. Me imagino cómo se sentiría una persona discapacitada.
Dmitri Zaitsev

1
¿Por qué es mejor mostrar una contraseña oscura que permitirle elegir una nueva contraseña que pueda recordar?
Jacob

@Jacob: ¿Más entropía?
Alexander Shcheblikin

25

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.


55
Las contraseñas compartidas entre su sitio de bajo valor con "no" activos caros y Facebook / GMail / su banco son activos caros, incluso en sitios de bajo valor.
jammycakes

3
Creo que el problema aquí es que los grupos de usuarios mencionados anteriormente tienden a usar la misma contraseña para todas las aplicaciones de muchos niveles de seguridad diferentes (desde banca hasta blogs de recetas). Entonces, la pregunta es si es responsabilidad del desarrollador proteger a los usuarios incluso de sí mismos. Definitivamente diría que sí.
ercan

77
Lo siento, pero la identidad en sí misma es un activo de alto valor, punto. Sin excepciones, sin excusas. No importa cuán pequeño e intrascendente creas que es tu sitio. Y una contraseña compartida es la identidad si permite que el hacker entre en las cuentas de Facebook, cuentas de Gmail, cuentas bancarias, etc. de sus usuarios. No tiene nada que ver con la semántica, pero tiene que ver con las consecuencias. Pregúntele a cualquiera que haya sido afectado por un ataque de hackers como este: theregister.co.uk/2009/08/24/4chan_pwns_christians
jammycakes

2
@Jacob, ¿en qué mundo sería demandado su cliente porque las cuentas de Erma en otros sistemas se han visto comprometidas? Incluso debido a una negligencia grave por parte de su cliente (lo cual NO es un hecho, como lo expliqué), y ADEMÁS del hecho de que NO HAY MANERA de demostrar que el otro sistema fue violado debido al suyo, no hay una posición legal posible para reclamar cualquier forma de daños de un sistema en el otro sistema. Sería expulsado de la corte con prejuicio, y encontrando al demandante en desacato. Sin embargo, Erma podría tener la culpa por violar numerosos Términos de servicio ...
AviD

55
@Jacob, eso está muy mal. El hecho de que la contraseña sea la misma (lo que violaría claramente su ToS y su política de seguridad), no es legal para corrolar los dos. Eso incluso ADEMÁS del hecho de que PROPORCIONARLO sería casi imposible. Como comentario aparte, también señalaré que NO HAY LEY que exija que una compañía aleatoria no tenga prácticas de seguridad laxas, a menos que las regulaciones específicas sean relevantes. Y además de eso, las contraseñas están encriptadas (!), Por lo que la laxitud está lejos de ser una conclusión perdida.
AviD

21

¿Qué tal una casa a mitad de camino?

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

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

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


Sabes, lo he usado en varias situaciones (por lo general, este es mi punto medio), pero la gente me ha dicho que el usuario final simplemente no va a obtener la interacción y que el soporte debe poder decirles su contraseña 'debido a circunstancias en ese modelo de negocio'. Sin embargo, estoy de acuerdo en que, cuando sea posible, esto es preferible.
Shane

Siempre puede decirle a su cliente sobre el riesgo de que su DB caiga en manos malvadas y que obtenga la publicidad de contraseñas robadas ... Hay muchos ejemplos.
Oded

66
Pídales que firmen el "diseño", con una cláusula adicional de que no pueden demandarlo si lo que les advirtió realmente sucede ... Al menos, entonces usted se cubre.
Oded

44
-1 las contraseñas nunca deben "encriptarse" Es una violación de CWE-257 cwe.mitre.org/data/definitions/257.html
rook

34
@Michael Brooks: no hay necesidad de votar y copiar y pegar el mismo comentario una y otra vez; Todos somos conscientes de que es una mala práctica. Shane declaró que carece de influencia en el asunto, por lo que se proponen las siguientes mejores cosas.
Johannes Gorset

13

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

Entonces los pasos serían:

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

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


55
La mayoría de los usuarios no tienen una clave PGP (todavía no la tengo; después de 20 años en la industria, nunca he sentido la necesidad), y no es un proceso sin fricción obtenerla. Además, una clave privada es realmente solo un proxy para una contraseña real de todos modos. Es una contraseña para una contraseña, en otras palabras; son tortugas hasta el fondo.
Robert Harvey

1
@RobertHarvey El objetivo es permitir que un usuario recupere su contraseña sin permitir que los empleados del sitio o cualquier hacker acceda a ella. Al exigir que el proceso de recuperación ocurra en la propia computadora del usuario, usted impone esto. Bien puede haber alternativas a PGP que podrían lograr lo mismo. Puede que haya tortugas hasta el fondo (tal vez algunos elefantes en el camino), pero no veo otra forma. Para la población en general (no es probable que sea un objetivo individual) tener sus contraseñas en un papel y no poder recuperarlas del servicio, sería más seguro de lo que somos actualmente
Nicholas Shanks el

Me gusta porque obliga a todos a tener una clave pública PGP, lo cual, curiosamente, es algo muy ético.
Lodewijk

simplemente podría generar uno y dárselo al usuario.
Mi1

@RobertHarvey Puede tener razón en que este "no es un proceso sin fricción", pero podría ser un servicio adicional para usuarios avanzados, que los usuarios habituales pueden ignorar. En cuanto al argumento acerca de que un PK es "una contraseña para una contraseña", recuerde que en teoría puede ser así para muchas contraseñas; puede usar diferentes contraseñas para diferentes servicios y cifrarlas todas con la misma clave. Entonces la PK será más valiosa que una sola contraseña. Quizás es de una manera abstracta comparable a un administrador de contraseñas (?). Sin embargo, no tengo claro de inmediato qué consecuencias puede tener esto ...
Kjartan

12

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


44
@sneg - Bueno, soy un tipo muy convincente, pero a veces es un jefe y otras un cliente, así que no siempre tengo la influencia que necesito para convencerlos de una forma u otra. Aunque practicaré en el espejo un poco más ...;)
Shane

Para ser convincente, realmente no necesita ningún otro apalancamiento que no sea su competencia y habilidad de comunicación. Si conoces una mejor manera de hacer algo pero la gente no escucha ... Piensa en ello.
z-boss

77
@ z-boss - Aparentemente no has trabajado con / para algunas de las cabezas duras con las que he tenido el placer de trabajar. A veces no importa si tu lengua está chapada en oro y puedes reprogramar Google Chrome en un día (lo que podría decir que podría ser útil) aún no se moverán.
Shane

11

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

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

  • cifrar con: openssl_encrypt (cadena $ datos, cadena $ método, cadena $ contraseña)
  • arg de datos :
    • la información confidencial (por ejemplo, la contraseña del usuario)
    • serializar si es necesario, por ejemplo, si la información es una matriz de datos como información sensible múltiple
  • contraseña arg : use una información que solo el usuario conozca como:
    • la placa de usuario
    • Número de seguridad social
    • número de teléfono del usuario
    • el nombre de la madre del usuario
    • una cadena aleatoria enviada por correo electrónico y / o sms en el momento del registro
  • método arg :
    • elija un método de cifrado, como "aes-256-cbc"
  • NUNCA almacene la información utilizada en el argumento de "contraseña" en la base de datos (o en cualquier lugar del sistema)

Cuando sea necesario recuperar estos datos, simplemente use la función "openssl_decrypt ()" y solicite al usuario la respuesta. Por ejemplo: "Para recibir su contraseña, responda la pregunta: ¿Cuál es su número de teléfono celular?"

PS 1 : nunca use como contraseña los datos almacenados en la base de datos. Si necesita almacenar el número de teléfono celular del usuario, nunca use esta información para codificar los datos. Siempre use una información que solo el usuario conozca o que sea difícil de conocer para alguien no familiar.

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


9

Asegurar credenciales no es una operación binaria: seguro / no seguro. La seguridad tiene que ver con la evaluación de riesgos y se mide de forma continua. Los fanáticos de la seguridad odian pensar de esta manera, pero la fea verdad es que nada es perfectamente seguro. Las contraseñas cifradas con requisitos de contraseña estrictos, muestras de ADN y escaneos de retina son más seguras pero a un costo de desarrollo y experiencia del usuario. Las contraseñas de texto sin formato son mucho menos seguras, pero su implementación es más barata (pero debe evitarse). Al final del día, se reduce a un análisis de costo / beneficio de una violación. Implementa la seguridad en función del valor de los datos que se protegen y su valor temporal.

¿Cuál es el costo de que la contraseña de alguien salga a la naturaleza? ¿Cuál es el costo de la suplantación en el sistema dado? Para las computadoras del FBI, el costo podría ser enorme. Para el sitio web único de cinco páginas de Bob, el costo podría ser insignificante. Un profesional brinda opciones a sus clientes y, cuando se trata de seguridad, expone las ventajas y los riesgos de cualquier implementación. Esto es doble si el cliente solicita algo que podría ponerlos en riesgo por no cumplir con los estándares de la industria. Si un cliente solicita específicamente un cifrado bidireccional, me aseguraría de que documente sus objeciones, pero eso no debería impedir que implemente de la mejor manera que sepa. Al final del día, es el dinero del cliente. Si,

Si está almacenando contraseñas con cifrado bidireccional, la seguridad se reduce a la administración de claves. Windows proporciona mecanismos para restringir el acceso a claves privadas de certificados a cuentas administrativas y con contraseñas. Si está alojando en otras plataformas, necesitaría ver qué opciones tiene disponibles en esas. Como otros han sugerido, puede usar cifrado asimétrico.

No hay ninguna ley (ni la Ley de Protección de Datos en el Reino Unido) de la que tenga conocimiento que establezca específicamente que las contraseñas deben almacenarse utilizando hashes unidireccionales. El único requisito en cualquiera de estas leyes es simplemente que razonable se tomen medidas para la seguridad. Si el acceso a la base de datos está restringido, incluso las contraseñas de texto sin formato pueden calificar legalmente bajo dicha restricción.

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


10
Su respuesta ignora por completo que las contraseñas se reutilizan en múltiples sitios / servicios, lo cual es fundamental para este tema y la razón por la cual las contraseñas recuperables se consideran una debilidad grave. Un profesional de seguridad no delega decisiones de seguridad al cliente no técnico; un profesional sabe que sus responsabilidades se extienden más allá del cliente que paga y no ofrece opciones con alto riesgo y cero recompensa. -1 por un discurso pesado en retórica y extremadamente ligero en hechos, y por no responder realmente la pregunta.
Aaronaught

44
Una vez más, está pasando por alto completamente la evaluación de riesgos. Para usar su argumento, no puede detenerse en solo hashes de 1 vía. TAMBIÉN debe incluir requisitos de complejidad, longitudes de contraseña, restricciones de reutilización de contraseña, etc. Argumentar que los usuarios usarán contraseñas tontas o reutilizarán contraseñas no es una justificación comercial suficiente si el sistema es irrelevante y, francamente, respondí la pregunta. La respuesta corta: presionar para usar una implementación estándar, documentar sus objeciones si es anulado y seguir adelante.
Thomas

77
¡Y de nuevo repites el error de que nada de esto importa para un sistema de bajo valor! El valor de la contraseña de un usuario no tiene nada que ver con el valor de la cuenta de un usuario en su sistema. Es un secreto , y uno que siempre debes guardar. Desearía poder dar otro -1 por el comentario que demuestra que todavía no entiendes los problemas aquí.
Aaronaught

55
La evaluación de riesgos es el tema central. La reutilización de contraseñas es solo un problema potencial en un conjunto de problemas mucho mayor. ¿Por qué no requieren llaveros? ¿Por qué no exigir que la persona conduzca a su oficina para iniciar sesión? Sin una evaluación razonable de los riesgos, no hay forma de responder estas preguntas. En su mundo, todo es un riesgo, por lo que cada sistema requiere seguridad de inicio de sesión a nivel del FBI. Simplemente no es así como funciona el mundo real.
Thomas

77
Lo único que está claro aquí es que todo su argumento no es más que una falacia de Slippery Slope y que está tratando de impulsar a los lectores con palabras de moda como "evaluación de riesgos" para encubrir ese hecho. Tenga la seguridad de que cualquier sistema que utilice el "FBI" será mucho más seguro que un hash de bcrypt y una longitud mínima de contraseña. Si requerir sistemas de autenticación estándar de la industria me convierte en un "fanático de la seguridad", entonces supongo que soy un fanático; personalmente, me duele saber que hay personas por ahí dispuestas a sacrificar MI seguridad por dinero. Eso no es ético .
Aaronaught

8

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


El usuario puede responder de manera diferente a la pregunta también. Algunas preguntas requieren respuestas más largas que son fáciles de reformular más adelante.
Monoman

55
Las preguntas de seguridad son una mala idea. ¿Cómo logra que su madre cambie su apellido de soltera una vez que se infringe la información? También vea Peter Gutmann's Engineering Security .
jww

7

Implemento sistemas de autenticación de múltiples factores para vivir, por lo que para mí es natural pensar que puede restablecer o reconstruir la contraseña, mientras que temporalmente utilizo un factor menos para autenticar al usuario solo para el flujo de trabajo de restablecimiento / recreación. En particular, el uso de OTP (contraseñas de un solo uso) como algunos de los factores adicionales, mitiga gran parte del riesgo si el intervalo de tiempo es corto para el flujo de trabajo sugerido. Hemos implementado generadores de software OTP para teléfonos inteligentes (que la mayoría de los usuarios ya llevan consigo todo el día) con gran éxito. Antes de que aparezcan quejas de un enchufe comercial, lo que estoy diciendo es que podemos reducir los riesgos inherentes de mantener las contraseñas fácilmente recuperables o restablecibles cuando no son el único factor utilizado para autenticar a un usuario.


Eliminar temporalmente un factor de un sistema de autenticación de múltiples factores es, de hecho, un medio mucho más seguro para restablecer una contraseña que los sistemas de "preguntas secretas" que se ven en tantos sitios. Pero en cuanto al almacenamiento de contraseñas en un formato recuperable, no estoy seguro de cómo ayuda, a menos que de alguna manera esté utilizando el segundo factor para cifrar u ofuscar el primero, y no estoy seguro de cómo es posible con algo como un SecurID. ¿Puedes explicar?
Aaronaught

@Aaronaught Lo que he dicho es que si se 'requiere' que tenga contraseñas recuperables, el riesgo inherente es menor si no es el único factor de autenticación, y también es más fácil para el usuario final, si ese flujo de trabajo reutiliza factores que él / ella ya posee y tiene acceso actual, en lugar de tratar de recordar, probablemente también haya olvidado 'respuestas secretas' o usar enlaces de tiempo limitado o contraseñas temporales, ambos enviados a través de canales inseguros (a menos que esté usando S-MIME con certificados de cliente, o PGP, ambos incurren en costos especialmente en la gestión de la asociación correcta y la caducidad / sustitución)
Monoman

1
Supongo que todo eso es cierto, pero el riesgo de compromiso público es mínimo para empezar; El problema más grave con las contraseñas recuperables es la seguridad interna y, potencialmente, permitir que un empleado descontento se vaya con las contraseñas de correo electrónico de miles de clientes, o que un CEO corrupto lo venda a phishers y spammers. La autenticación de dos factores es excelente para combatir el robo de identidad y la adivinación de contraseñas, pero en realidad no aporta mucho en cuanto a mantener segura la base de datos de contraseñas.
Aaronaught

5

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


5

Acabo de encontrar esta discusión interesante y acalorada. Sin embargo, lo que más me sorprendió fue la poca atención que se prestó a la siguiente pregunta básica:

  • Q1. ¿Cuáles son las razones reales por las que el usuario insiste en tener acceso a la contraseña almacenada de texto sin formato? ¿Por qué tiene tanto valor?

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

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

Como no tengo esta información y no puedo hablar con esos clientes, solo puedo adivinar: se trata de usabilidad, ver arriba.

Otra pregunta que he visto es:

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

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

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

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

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

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

Sé que es inseguro, pero ¿qué me importa que alguien tenga acceso a mi "cuenta"? ¡Sí, él también puede leer las noticias!

¿El sitio almacena mi información "privada"? ¿Las noticias que leí hoy? ¡Entonces es el problema del sitio, no el mío! ¿El sitio muestra información privada al usuario autenticado? ¡Entonces no lo muestres en primer lugar!

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

Para resumir, no creo que sea un problema de cómo almacenar de forma "segura" las contraseñas de texto sin formato (que sabemos que es imposible), sino cómo abordar la preocupación real de los clientes.


4

Manejo de contraseñas perdidas / olvidadas:

Nadie debería poder recuperar contraseñas.

Si los usuarios olvidaron sus contraseñas, al menos deben conocer sus nombres de usuario o direcciones de correo electrónico. Previa solicitud, genere un GUID en la tabla Usuarios y envíe un correo electrónico que contenga un enlace que contenga el GUID como parámetro a la dirección de correo electrónico del usuario.

La página detrás del enlace verifica que el parámetro guid realmente existe (probablemente con alguna lógica de tiempo de espera) y le pide al usuario una nueva contraseña.

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


GUID es una mala idea, no lo suficientemente aleatoria y fácil de usar. Hay otros problemas con esto, consulte stackoverflow.com/questions/664673/…
AviD

3

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


No asumiría que el correo electrónico es más seguro que cualquier otro sistema. Aunque esto elimina la preocupación legal de mis manos, todavía existe el problema de que alguien pierda / elimine su correo electrónico y ahora vuelvo al punto de partida.
Shane

Proporcione un restablecimiento de contraseña y envíe por correo electrónico la contraseña de texto sin formato. Creo que eso es lo máximo que puede hacer al respecto, sin guardar una copia de la contraseña usted mismo.
casraf

Esta es una idea absolutamente horrible. Es ineficaz (muchos usuarios realmente eliminan correos electrónicos después de leer) y peor de lo que está tratando de proteger (ya que el correo electrónico no está encriptado de manera predeterminada y pasa a través de redes no confiables). Es mejor sugerirle al usuario que tome nota de la contraseña ellos mismos, al menos enviándose un correo electrónico, la información nunca va más allá del servidor de correo electrónico, ¡no a través de Internet!
Ben Voigt

3

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

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

La única opción que a menudo se pasa por alto con la política de contraseña es si realmente se necesita una contraseña. Si lo único que hace su política de contraseña es causar llamadas de servicio al cliente, tal vez pueda deshacerse de ella.


Siempre que tenga una dirección de correo electrónico asociada con una contraseña, y esa contraseña sea recuperable, posiblemente haya filtrado la contraseña para esa dirección de correo electrónico debido a la reutilización de la contraseña. Esa es en realidad la principal preocupación aquí. Realmente no hay otra información de identificación personal que importe.
Aaronaught

1
Te perdiste completamente mi punto. Si realmente no necesita una contraseña, no recopile una. Los desarrolladores a menudo se quedan atrapados en el modo de pensar "así es como lo hacemos". A veces ayuda arrojar nociones preconcebidas.
Anopres

2

¿ Realmente necesitan los usuarios recuperar (por ejemplo, que se les diga) cuál fue la contraseña que olvidaron o simplemente necesitan poder ingresar al sistema? Si lo que realmente quieren es una contraseña para iniciar sesión, ¿por qué no tener una rutina que simplemente cambie la contraseña anterior (lo que sea) a una nueva contraseña que la persona de soporte puede darle a la persona que perdió su contraseña?

He trabajado con sistemas que hacen exactamente esto. La persona de soporte no tiene forma de saber cuál es la contraseña actual, pero puede restablecerla a un nuevo valor. Por supuesto, todos estos restablecimientos deben registrarse en algún lugar y una buena práctica sería generar un correo electrónico al usuario diciéndole que la contraseña se ha restablecido.

Otra posibilidad es tener dos contraseñas simultáneas que permitan el acceso a una cuenta. Una es la contraseña "normal" que administra el usuario y la otra es como una llave maestra / maestra que solo conoce el personal de soporte y es la misma para todos los usuarios. De esa manera, cuando un usuario tiene un problema, la persona de soporte puede iniciar sesión en la cuenta con la clave maestra y ayudar al usuario a cambiar su contraseña a lo que sea. No es necesario decir que el sistema también debe registrar todos los inicios de sesión con la clave maestra. Como medida adicional, siempre que se use la clave maestra, también podría validar las credenciales de las personas de soporte.

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

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

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

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

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

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


Una clave maestra sería muy arriesgada, el personal de soporte tendría acceso a todas las cuentas, y una vez que le entregue esa clave a un usuario, entonces tendrá la clave maestra y acceso a todo.
Carson Myers

Una llave maestra es una idea terrible, ya que si alguien la descubre (o se la revela por accidente), puede explotarla. Como mecanismo de restablecimiento de contraseña por cuenta es mucho preferible.
Phil Miller

Tengo curiosidad, ¿pensé que Linux por defecto tenía una cuenta de superusuario con acceso de nivel raíz? ¿No es esa una "clave maestra" para acceder a todos los archivos del sistema?
JonnyBoats

@ JonnyBoats Sí, lo es. Es por eso que los Unix modernos como Mac OS X deshabilitan la cuenta raíz.
Nicholas Shanks

@NicholasShanks: ¿Deshabilitar la cuenta raíz o deshabilitar el inicio de sesión interactivo en la cuenta raíz? Todavía hay mucho código ejecutándose con permisos ilimitados.
Ben Voigt

2

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

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

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


1

abra una base de datos en un servidor independiente y proporcione una conexión remota encriptada a cada servidor web que requiera esta función.
no tiene que ser una base de datos relacional, puede ser un sistema de archivos con acceso FTP, utilizando carpetas y archivos en lugar de tablas y filas.
conceda a los servidores web permisos de solo escritura si puede.

Almacene el cifrado no recuperable de la contraseña en la base de datos del sitio (llamémosle "pass-a") como hacen las personas normales :)
en cada nuevo usuario (o cambio de contraseña) almacene una copia simple de la contraseña en la base de datos remota. use la identificación del servidor, la identificación del usuario y "pass-a" como clave compuesta para esta contraseña. incluso puede usar un cifrado bidireccional en la contraseña para dormir mejor por la noche.

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

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

puede controlar la accesibilidad del servicio de recuperación de contraseña (exponerlo solo como un servicio web seguro, permitir solo cierta cantidad de recuperaciones de contraseñas por día, hacerlo manualmente, etc.) e incluso cobrar un extra por este "acuerdo de seguridad especial".
El servidor de base de datos de recuperación de contraseñas está bastante oculto, ya que no cumple muchas funciones y puede protegerse mejor (puede personalizar los permisos, procesos y servicios de manera estricta).

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


3
Si el servidor de aplicaciones puede acceder a él, también lo puede hacer cualquier persona con acceso al servidor de aplicaciones (ya sea un pirata informático o un intruso malicioso). Esto ofrece cero seguridad adicional.
molf

1
La seguridad adicional aquí es que la base de datos del servidor de aplicaciones no contiene contraseñas (por lo que se necesita un segundo pirateo, a las bases de datos de las bases de datos), y las bases de datos de las bases de datos pueden protegerse mejor contra actividades irregulares, ya que usted controla la accesibilidad del servicio de recuperación de contraseñas. para que pueda detectar recuperaciones masivas de datos, cambiar la clave SSH de recuperación semanalmente, o incluso no permitir la recuperación automática de pases, y hacerlo todo manualmente. Esta solución también se adapta a cualquier otro esquema de cifrado interno (como las claves públicas + privadas, salt, etc.) para las contraseñas DB.
Amir Arad

1

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

  1. Una vez que un usuario está registrado, tiene acceso completo (como un sitio web normal). El registro debe incluir un correo electrónico.
  2. Si se necesitan datos o una acción y el usuario no recuerda su contraseña, aún puede realizar la acción haciendo clic en un botón especial " enviarme un correo electrónico para obtener permiso ", justo al lado del botón " enviar ".
  3. La solicitud se envía al correo electrónico con un hipervínculo preguntando si desean que se realice la acción. Esto es similar a un enlace de correo electrónico de restablecimiento de contraseña, pero en lugar de restablecer la contraseña, realiza la acción de una sola vez .
  4. Luego, el usuario hace clic en "Sí" y confirma que se deben mostrar los datos, o se debe realizar la acción, revelar los datos, etc.

Como mencionó en los comentarios, esto no funcionará si el correo electrónico se ve comprometido, pero aborda el comentario de @joachim acerca de no querer restablecer la contraseña. Eventualmente, tendrían que usar el restablecimiento de contraseña, pero podrían hacerlo en un momento más conveniente, o con la ayuda de un administrador o amigo, según sea necesario.

Un giro a esta solución sería enviar la solicitud de acción a un administrador de confianza externo. Esto funcionaría mejor en casos con usuarios de edad avanzada, con problemas mentales, muy jóvenes o confundidos. Por supuesto, esto requiere un administrador de confianza para que estas personas respalden sus acciones.


1

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

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

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


¿Por qué cree que es necesario comparar lo que el usuario ingresó directamente con la contraseña hash almacenada en la base de datos? ¿Qué tipo de funcionalidad te da eso? Además, al hacer esto, es muy importante aplicar la función de comparación de tiempo constante entre la contraseña ingresada por el usuario y la contraseña cifrada de la base de datos. De lo contrario, es casi trivialmente posible determinar la contraseña cifrada en función de las diferencias de tiempo.
Artjom B.

1
@ArtjomB. La pregunta pregunta cómo proteger la contraseña del usuario y al mismo tiempo permitir que el servicio de atención al cliente (CS) hable / envíe un correo electrónico a un usuario ingresando su contraseña olvidada. Al hacer que la versión hash sea utilizable como una contraseña de texto sin formato, CS puede leerla y hacer que el usuario la use en lugar de su contraseña olvidada. CS también puede usarlo para iniciar sesión como usuario y ayudarlo en una tarea. Esto también permite que los usuarios que se sienten cómodos con los sistemas automatizados de contraseña olvidada estén protegidos, ya que la contraseña que ingresan y usan está cifrada.
Eliott

Veo. No he leído la pregunta en su totalidad. El uso de una comparación de tiempo constante todavía es necesario para evitar la ruptura trivial de todo el sistema.
Artjom B.
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.