Pregunta:
¿Es útil proteger contraseñas hash con cifrado?
papafe
2013-11-12 16:59:10 UTC
view on stackexchange narkive permalink

Imagínese que estoy aplicando hash a las contraseñas de los usuarios con un valor aleatorio, suficientemente largo, mediante el uso de extensión de clave y un hash seguro. ¿Sería más seguro cifrar finalmente el hash con una clave simétrica?

posible duplicado de [Contraseña Hashing agregar sal + pimienta o la sal es suficiente?] (http://security.stackexchange.com/questions/3272/password-hashing-add-salt-pepper-or-is-salt-enough)
Seis respuestas:
bobince
2013-11-12 18:50:59 UTC
view on stackexchange narkive permalink

¿Cuál es el modelo de amenazas? Podría ser beneficioso proteger el almacenamiento de contraseñas con un secreto del lado de la aplicación, pero solo si cree que es un escenario realista que su base de datos se verá comprometida, sin su servidor de aplicaciones, que contiene la secreto, también habiendo sido comprometido.

Por lo general, la capa de la aplicación se considera la parte más vulnerable y la capa de la base de datos más protegida, y por esta razón no se considera útil proteger los datos con una aplicación del lado secreto. Pero ese puede no ser el caso para todas las aplicaciones, y personalmente cuestionaría un poco esta suposición dada la prevalencia de la inyección SQL.

La desventaja de introducir un secreto del lado de la aplicación es que ahora debe preocuparse por procesos de gestión de claves. ¿Cuál es su mecanismo para reemplazar la llave si se ve comprometida? ¿Vas a rotarlo de forma natural? ¿Cómo se almacena su clave para que pueda mover servidores y no perderla (haciendo potencialmente inútiles todos sus datos)? Para las claves de corta duración (utilizadas, por ejemplo, para firmar tokens de sesión) puede que no le importe, pero el almacenamiento de contraseñas a largo plazo se vuelve importante.

La otra desventaja de los cifrados simétricos (especialmente los cifrados en bloque) es implementarlos correctamente . Dado que está haciendo hash y no necesita recuperabilidad, podría incluir el secreto en el hash (como un 'pimiento') ... pero entonces no podría volver a hash todos los datos de contraseña en un cambio de clave , por lo que tendría que tener un método de varias teclas para la sustitución.

ETA recomentar a @Pacerier:

El hash no previene un ataque de adivinación fuera de línea por alguien que ha obtenido la base de datos de contraseñas. Solo aumenta la cantidad de tiempo que tarda ese ataque en dar frutos; con un esquema de hash de dificultad adecuada (es decir, rondas de derivación de claves en lugar de la longitud de la sal cruda per se), es de esperar que aumente esa cantidad de tiempo al tiempo suficiente para que se dé cuenta de que ha sido pirateado y cambie las contraseñas de todos antes de que muchos de sus cuentas se pierden.

Proteger el contenido con una clave secreta (ya sea mediante encriptación o incluyendo la clave secreta en el material hash) evita el ataque de adivinanzas fuera de línea, pero solo mientras la clave secreta sea no se filtró. Si la clave secreta está en el servidor de la aplicación, separado del servidor de la base de datos, las contraseñas solo son atacables si ambas máquinas están comprometidas.

Qué beneficio es discutible, dado que muchos tipos de ataques pueden terminar comprometiendo ambos, especialmente si el servidor de la aplicación y el servidor de la base de datos son la misma máquina. También hay un precio a pagar en manejabilidad como se discutió. Por lo tanto, si hay un beneficio neto debe juzgarse caso por caso con referencia al modelo de amenaza.

Las preguntas indican que está usando una sal aleatoria lo suficientemente larga. Entonces, ¿cuál es el punto de cifrar el hash en primer lugar? ¿Qué tiene de vulnerable simplemente mantener el hash como texto sin formato?
Adi
2013-11-12 17:04:49 UTC
view on stackexchange narkive permalink

Soy un gran admirador de agregar capas de protección a un sistema seguro como parte de una política de defensa en profundidad. Sin embargo, en este caso particular, el uso de cifrado simétrico para esta tarea crea otro problema en el sistema; tendrá que encargarse de la gestión de claves. La clave debe estar almacenada en algún lugar, y si su aplicación tiene acceso a ella, entonces un atacante que comprometió su sistema muy probablemente tendrá acceso a la clave.

Este procedimiento agrega más complejidad del sistema. La complejidad es uno de los enemigos de la seguridad. Lo desaconsejo encarecidamente.

martinstoeckli
2013-11-12 18:40:08 UTC
view on stackexchange narkive permalink

El cifrado de los hashes de contraseña puede proteger las contraseñas en una situación muy específica.

Hay escenarios en los que un atacante obtiene acceso de lectura a su base de datos, la inyección de SQL es una posibilidad, una copia de seguridad con fugas o una servidor dispuesto otro. En este caso, puede forzar bruta los hashes de contraseña. Con un algoritmo hash apropiado (función de derivación de claves), las contraseñas seguras serán seguras, las débiles, aunque se pueden recuperar más o menos rápido con un ataque de diccionario (pruebe las 1000 contraseñas más utilizadas ...).

Al encriptar los hashes de tu contraseña, agregas un secreto del lado del servidor a tus hashes. Eso significa que, además de la base de datos, un atacante necesita ahora privilegios en el servidor (para obtener la clave). Esta es la misma ventaja que le puede dar un pimiento, pero tiene la ventaja de que puede intercambiar la clave siempre que parezca necesario.

Si la clave se almacena de forma segura no es tan importante, lo importante son los adicionales privilegios que necesita el atacante. En el peor de los casos, el atacante obtendrá los hash de la contraseña y usted tendrá la misma situación que sin cifrado.

"Las contraseñas débiles, aunque se pueden recuperar más o menos rápido con un ataque de diccionario", esta afirmación es incorrecta. Es incorrecto porque OP dice "Estoy aplicando hash a las contraseñas de los usuarios con una sal aleatoria, suficientemente larga". Dado que se usa sal, el ataque de diccionario se vuelve inútil para una base de datos. Consulte http://stackoverflow.com/q/3566504/706456 para obtener más detalles.
@oleksii - No realmente, la sal evita el uso de tablas de arco iris y con sales únicas, cada contraseña debe ser forzada por separado. Contra la fuerza bruta de una sola contraseña, una sal no ayudará. Hoy en día puede calcular varios [Giga hashes por segundo] (http://hashcat.net/oclhashcat-lite/#performance) con hardware común, por eso necesita un algoritmo lento. Incluso con un algoritmo lento, puede probar las contraseñas más utilizadas, esto es una especie de ataque de diccionario. Te invito a que eches un vistazo a mi tutorial sobre [almacenamiento seguro de contraseñas] (http://www.martinstoeckli.ch/hash/en/index.php).
Otra forma de verlo: la limitación de la velocidad y / o el bloqueo de los intentos de inicio de sesión están ampliamente aceptados como importantes para los ataques en línea para evitar la fuerza bruta y el relleno de credenciales.Es un habitual en el top 10 de OWASP. Los ataques fuera de línea eluden estas protecciones, al igual que la inyección SQL si puede usar un punto final no cubierto por el límite de tasa de inicio de sesión o el bloqueo de cuenta.Además de comprometer las contraseñas reutilizadas en otros sitios, el atacante puede potencialmente usar las credenciales rellenas o forzadas para iniciar sesión con éxito en su sitio la primera vez sin intentos fallidos.Vale la pena considerarlo en su modelo de amenazas.
Ken Bolger
2013-11-20 14:13:08 UTC
view on stackexchange narkive permalink

Creo que hay razones para cifrar un resumen seguro.

Parece generalmente aceptado que la mejor práctica hoy en día es usar bcrypt, PBKDF2 o algoritmos similares para aplicar sal y aplicar un factor de trabajo a la generación del resumen de contraseñas. El uso de un pimiento también es una excelente manera de evitar que las contraseñas pobres o bien conocidas sean fácilmente forzadas sin importar el algoritmo / factor de trabajo que se utilice.

Sin embargo, el uso de algoritmos lentos requiere el factor de trabajo para ser actualizado a medida que mejora el rendimiento del hardware y debe elegirse para mitigar los ataques de fuerza bruta, pero no para la verificación lenta de contraseña para los usuarios que inician sesión en su sistema Al utilizar el cifrado simétrico de un hash de contraseña, ya no se requieren la carga de trabajo ni los requisitos de pimienta. Siempre que la clave simétrica esté bien protegida (usando un HSM, por ejemplo) y se hayan establecido buenos procesos de administración de claves, no puedo ver una desventaja para este enfoque. La dificultad de un ataque de fuerza bruta es la misma que forzar la clave sin importar si la contraseña es de buena calidad o no.

Ciertamente no crearía la infraestructura para hacer esto como todos los comentarios anteriores con respecto a la administración de claves. y mantener la clave separada del servidor de aplicaciones se aplicaría. Pero si la infraestructura ya está en su lugar y bien establecida, ciertamente hay algunas ventajas de cifrar un hash de contraseña salado.

Owen
2013-11-12 18:32:49 UTC
view on stackexchange narkive permalink

Yo diría que no. Por las razones que ha dicho Adnan, la clave debe ser accesible y, por lo tanto, este paso probablemente solo agregue complejidad al sistema, lo cual es innecesario.

Un mejor enfoque en mi opinión sería ver el cifrado como una computación que podría pagar, pero no usar, y considerando si podría usar esa computación para un enfoque de hash diferente.

Matt Surabian
2013-11-19 19:53:21 UTC
view on stackexchange narkive permalink

Existe la idea errónea de que la superposición de diferentes prácticas de cifrado da como resultado algo que es más seguro que cualquier práctica individual por sí sola. Sin embargo, ese rara vez es el caso.

El hash de contraseña implementado correctamente con una sal larga es criptográficamente seguro. El propósito de aplicar hash y salar contraseñas es proteger los datos en reposo. Lo que significa que nadie que se apodere de su base de datos de contraseñas debería saber cuáles son las contraseñas e incluso si logran descifrar una o más contraseñas, eso no debería dar ninguna ventaja para descifrar otra.

Como Adobe nos ha mostrado en las últimas semanas, los cifrados de bloques simétricos no son buenos para esta tarea. El hash con sal evita este problema por completo.

Otros han señalado que el cifrado adicional de sus contraseñas hash introduce el problema de la gestión de claves y no ofrece seguridad / robustez adicional para los datos almacenados. El cifrado es bueno para garantizar que solo aquellos con las credenciales adecuadas puedan acceder a los datos. El cifrado es reversible por este motivo. Este no es un paradigma de autenticación.

Cuando nos autenticamos, queremos que el servidor use algo que conoce (la sal) y un secreto que solo su usuario conoce (la contraseña) para generar consistentemente el mismo bloque único de datos. Sabemos que el usuario es quien dice ser porque podemos reproducir esta mancha gigante una y otra vez. La sal asegura que incluso dos contraseñas idénticas no tengan el mismo hash en la base de datos. El cifrado adicional tampoco ofrece ayuda en ese frente.

1) Generalmente, la sal no es un secreto, ya que no se puede asumir que un servidor comprometido se las arregla para retener ningún secreto. Las contraseñas saladas siguen siendo vulnerables a los ataques de adivinación de contraseñas, ya que los humanos apestan al elegir buenas contraseñas. 2) Es posible agregar un valor secreto a los hash de contraseña, ya sea cifrando el hash o concatenando un valor secreto, comúnmente llamado pimienta, a la sal. 3) Adobe ha demostrado que agregar una clave puede ser útil, ya que a veces no se la roban ni se publica. 4) Adobe no ha demostrado por qué los cifrados de bloques simétricos son malos para esto, solo que el modo ECB apesta.
5) No es necesario un hash de contraseña para que sea resistente a colisiones. Solo necesita ser resistente a la preimagen.
Editado arriba para mayor claridad. No quise dar a entender que la sal tenía que ser secreta, solo que es algo que el servidor tiene en su poder. Del mismo modo, al mencionar la resistencia a colisiones, estaba tratando de ilustrar que la sal evita que dos contraseñas idénticas tengan el mismo hash en la base de datos.
Cinco años después, ni una sola contraseña de Adobe ha sido pirateada por medios criptográficos.Solo comparando las sugerencias de contraseña, podemos estar razonablemente seguros de algunas.El caso de Adobe es el * peor * ejemplo si desea demostrar que cifrar las contraseñas es una mala idea, ya que está demostrando exactamente lo contrario.


Esta pregunta y respuesta fue traducida automáticamente del idioma inglés.El contenido original está disponible en stackexchange, a quien agradecemos la licencia cc by-sa 3.0 bajo la que se distribuye.
Loading...