encryption - partir - Almacenamiento de contraseñas encriptadas

generador de contraseñas wifi (11)

Mi compañero de trabajo y yo estamos teniendo una discusión civilizada sobre la seguridad de las contraseñas. Por favor ayúdenos a resolver nuestras diferencias.

Uno de nosotros toma el punto de vista de que:

El almacenamiento de contraseñas cifradas con una clave pública además de una versión de hash unidireccional está bien y puede ser útil para la integración con otros sistemas de autenticación en el futuro en caso de una fusión o adquisición.
Solo el CEO / CTO tendría acceso a la clave privada, y solo se usaría cuando fuera necesario. La validación de inicio de sesión regular todavía se producirá a través de la contraseña hash
Lo he hecho anteriormente en compañías anteriores y hay muchos sitios que lo hacen y han sobrevivido a auditorías de seguridad de compañías Fortune 500 antes.
Esta es una práctica común y aceptada, incluso para las instituciones financieras, por lo tanto, no es necesario declararlo explícitamente en la política de privacidad.
Sitios como Mint.com hacen esto.

El otro de nosotros toma el siguiente punto de vista:

El almacenamiento de contraseñas, incluso en forma cifrada, es un riesgo de seguridad innecesario y, en primer lugar, es mejor evitar la exposición a este riesgo.
Si la clave privada cae en las manos equivocadas, los usuarios que usan la misma contraseña en múltiples sitios corren el riesgo de que todos sus inicios de sesión se vean comprometidos.
Esto es una violación de la confianza de nuestros usuarios, y si se implementa esta práctica, se les debe informar explícitamente sobre esto.
Esto no es una práctica en toda la industria y no los sitios de grandes nombres (Google, Yahoo, Amazon, etc.) implementan esto. Mint.com es un caso especial porque necesitan autenticarse con otros sitios en su nombre. Además, solo almacenan las contraseñas a sus instituciones financieras, no su contraseña a Mint.com.
Esta es una bandera roja en las auditorías.

¿Pensamientos? ¿Comentarios? ¿Has trabajado en una organización que implementó esta práctica?

y podría ser útil para la integración con otros sistemas de autenticación en el futuro

Si no hay una necesidad inmediata de almacenar la contraseña en un formato cifrado reversible, no lo haga .

Contraseñas de hash

Almacenar contraseñas en forma reversible es innecesario y arriesgado.

En mi opinión, una infracción de seguridad parece mucho más probable que la necesidad de combinar tablas de contraseñas. Además, el costo de una brecha de seguridad parece mucho más alto que el costo de implementar una estrategia de migración. Creo que sería mucho más seguro codificar las contraseñas de forma irreversible.

Estrategia migratoria

En el caso de una fusión de la empresa, el algoritmo original utilizado para las contraseñas de hash se puede anotar en una tabla de contraseñas combinadas y se pueden llamar diferentes rutinas para verificar las contraseñas de diferentes usuarios, determinadas por este identificador. Si lo desea, el hash almacenado (y su identificador) también pueden actualizarse en este momento, ya que la contraseña de texto simple del usuario estará disponible durante la operación de inicio de sesión. Esto permitiría una migración gradual a un único algoritmo hash. Tenga en cuenta que las contraseñas deberían caducar después de algún tiempo, por lo que esto sería un límite superior en el tiempo que requeriría la migración.

Amenazas

Hay un par de vías para atacar contraseñas encriptadas:

El custodio clave de descifrado podría estar corrupto. Podrían descifrar las contraseñas y robarlas. Un custodio puede hacer esto por su cuenta, o puede ser sobornado o chantajeado por otra persona. Un ejecutivo sin entrenamiento especial es especialmente susceptible a la ingeniería social.

También se puede realizar un ataque en la clave pública utilizada para el cifrado. Al sustituir la clave pública real por una propia, cualquiera de los administradores de la aplicación podría recopilar contraseñas. Y si solo el CEO tiene la clave de descifrado real, es poco probable que esto se descubra durante mucho tiempo.

Mitigación

Suponiendo que esta batalla se pierda, y las contraseñas estén encriptadas, en lugar de troceadas, pelearía por un par de concesiones:

Como mínimo, la clave de descifrado debe requerir la cooperación de varias personas para su recuperación. Una técnica clave para compartir como el algoritmo secreto de Shamir sería útil.
También se requieren medidas para proteger la integridad de la clave de cifrado. El almacenamiento en un token de hardware a prueba de manipulaciones o el uso de un MAC basado en contraseña puede ayudar.

Bueno, en primer lugar, otorgarle al CEO / CTO acceso a las contraseñas de texto sin formato es una estupidez. Si estás haciendo las cosas bien, no hay necesidad de esto. Si un hacker rompe su sitio, ¿qué le impide atacar al CEO a continuación?

Ambos métodos son incorrectos.

Comparando el hash de una contraseña recibida con un hash almacenado significa que el usuario envía su contraseña de texto simple en cada inicio de sesión, una puerta trasera en su aplicación web lo obtendrá. Si el hacker no tiene suficientes privilegios para plantar una puerta trasera, simplemente romperá los hashes con su botnet de GPU de 10K. Si los hashes no pueden romperse, significa que tienen colisiones, lo que significa que tienes un hash débil, lo que aumenta un ataque de fuerza bruta ciega por magnitudes. No estoy exagerando, esto sucede todos los días, en sitios con millones de usuarios.

Permitir que los usuarios utilicen contraseñas de texto simple para iniciar sesión en su sitio significa permitirles usar la misma contraseña en cada sitio. Esto es lo que hace el 99% de todos los sitios públicos en la actualidad, es una práctica patética, maliciosa y anti-evolutiva.

La solución ideal es utilizar una combinación de certificados de cliente SSL y certificados de servidor. Si lo haces correctamente, hará que el ataque MITM / Phishing común sea imposible ; un ataque de este tipo no podría usarse contra las credenciales O la sesión. Además, los usuarios pueden almacenar sus certificados de cliente en hardware criptográfico, como tarjetas inteligentes, lo que les permite iniciar sesión en cualquier computadora sin el riesgo de perder sus credenciales (aunque aún serían vulnerables al secuestro de sesión).

Usted hace pensar que no estoy siendo razonable, pero los certificados de cliente SSL se inventaron por una razón ...

Cada vez que tengo algo que ver con las contraseñas, se las hace de una manera, con una sal cambiante, es decir, hash (userId + clearPassword). Estoy muy contento cuando nadie en nuestra empresa puede acceder a las contraseñas de forma clara.

El argumento a favor de almacenarlos parece ser que podría simplificar la integración en el caso de una fusión o adquisición. Cada otra declaración en ese lado del argumento no es más que una justificación: o "por eso no es tan malo" o "otras personas lo están haciendo".

¿Cuánto vale la pena poder hacer conversiones automáticas que un cliente no quiera hacer en caso de una fusión o adquisición? ¿Con qué frecuencia anticipa las fusiones y / o adquisiciones? ¿Por qué sería tan difícil usar las contraseñas con hash tal como son o pedir a sus clientes que acepten explícitamente los cambios?

Me parece una razón muy fina.

Por otro lado, cuando almacena contraseñas en forma recuperable, siempre existe el peligro de que salgan. Si no lo haces, no hay; No puedes revelar lo que no sabes. Este es un riesgo grave. El CEO / CTO puede ser descuidado o deshonesto. Puede haber una falla en el cifrado. Ciertamente, habría una copia de seguridad de la clave privada en algún lugar, y eso podría salir.

En resumen, para incluso considerar el almacenamiento de contraseñas en forma recuperable, quisiera una buena razón. No creo que la conveniencia potencial de implementar una conversión que podría o no ser requerida por una posible maniobra de negocios califique.

O, para ponerlo en una forma que la gente de software pueda entender, YAGNI.

Estoy de acuerdo en que la forma más segura sigue siendo el hash de una sola vía (¡pero con una sal, por supuesto!). Solo recurriría al cifrado cuando fuera necesario para integrarme con otros sistemas.

Incluso cuando tiene un sistema construido que va a necesitar integración con otros sistemas, es mejor pedirles a sus usuarios esa contraseña antes de integrarlos. De esa manera el usuario se siente ''en control'' de sus propios datos. Al revés, comenzando con las contraseñas encriptadas, mientras que el uso no es claro para el usuario final, planteará muchas preguntas cuando comience a integrarse en algún momento.

Así que definitivamente iré con el hash unidireccional, a menos que haya una razón clara (¡claro en cuanto al desarrollo y claro para el usuario final!) Que la contraseña no encriptada se necesita de inmediato.

edición: incluso cuando se necesita la integración con otros sistemas, almacenar contraseñas recuperables no es la mejor manera. Pero eso, por supuesto, depende del sistema para integrarse.

Estoy trabajando en una institución financiera y aquí el acuerdo es: nadie debería saber la contraseña del usuario, por lo que la política predeterminada e implementada que se usa en todas partes es: una forma de hash de contraseñas con un fuerte algoritmo de hash.

Por una vez estoy a favor de esta opción: no quiere meterse en la molestia de manejar la situación en la que perdió su contraseña de cifrado de dos vías o alguien la robó y pudo leer las contraseñas almacenadas.

Si alguien pierde su contraseña, simplemente cámbiala y dásela. Si una empresa necesita fusionarse, TIENEN que mantener las contraseñas con hash como están: la seguridad está por encima de todo.

Piénselo de esta manera: ¿almacenaría las llaves de su casa en una caja que tiene una cerradura con una llave que tiene, o preferiría tenerlas siempre con usted? En el primer caso: todo el mundo podría acceder a las llaves de su casa, con la llave o el poder adecuados para romper la caja, en el segundo caso, para tener sus llaves, un potencial de la casa debería amenazarlos o quitárselos de alguna manera ... Lo mismo ocurre con las contraseñas, si están en una base de datos bloqueada, es como si nadie tuviera una copia de ellas, por lo que nadie puede acceder a sus datos.

He tenido que mover las cuentas de usuario entre sitios (como podría ocurrir en una fusión o adquisición) cuando las contraseñas se hacían de una sola forma y no era un problema. Así que no entiendo este argumento.

Incluso si las dos aplicaciones utilizan diferentes algoritmos de hash, habrá una forma sencilla de manejar la situación.

La primera práctica de almacenar la versión recuperable de contraseñas es sencillamente incorrecta. Independientemente del hecho de que los grandes sitios hacen esto. Está mal. Están equivocados.

Desconfío automáticamente de cualquier sitio que almacene mi contraseña sin ser borrada. ¿Quién sabe qué pasaría si los empleados de esa gran empresa deciden divertirse? Hubo un caso en que un tipo de Yahoo robó y vendió correos electrónicos de usuarios. ¿Qué pasa si alguien roba / vende toda la base de datos con mis correos electrónicos y contraseñas?

No es necesario que conozca mi contraseña original para realizar la autenticación. Incluso si decide más adelante dividir el sistema, agregar uno nuevo o integrarse con un tercero, aún estará bien con solo un hash de la contraseña.

Si eres un caso marginal, como mint.com, sí, hazlo. Mint almacena sus contraseñas en varios otros sitios (su banco, tarjeta de crédito, 401k, etc.), y cuando inicia sesión en Mint, va a todos esos otros sitios, inicia sesión a través de un script como usted y retira sus datos financieros actualizados. en un sitio centralizado fácil de ver. ¿Es seguro el papel de aluminio? Probablemente no. ¿Me encanta? Sí.

Si no eres un caso marginal, señor no, nunca deberías estar haciendo esto. Trabajo para una gran institución financiera, y esto ciertamente no es una práctica aceptada. Esto probablemente me haría despedir.

¿Por qué deberían ser los CEOs más confiables / confiables que otras personas? Hay ejemplos de personas gubernamentales de alto rango que han perdido datos confidenciales.
No hay razón para que un sitio normal tenga que almacenar una contraseña, ni una sola .
¿Qué pasa si en el futuro esas claves privadas pueden romperse? Si la clave utilizada es una clave débil, como sucedió recientemente en Debian.

El resultado final es: ¿Por qué asumir riesgos tan grandes por poco o ningún beneficio? La mayoría de las empresas nunca van a necesitar una contraseña encriptada.