¿Por qué los sitios web almacenan los hashes de las contraseñas, no sus textos cifrados?

Entiendo que usted cree que las contraseñas serían más seguras si se almacenaran al tener el sitio:

1. Genere un par único de clave pública / privada.
2. Deseche inmediatamente la clave privada de manera segura.
3. Cifre la contraseña con la clave pública.
4. Almacene la clave pública y la contraseña cifrada en la base de datos, de manera similar a la práctica común de almacenar la contraseña de sal y hash.

Su declaración de que este modelo de almacenamiento para contraseñas sería más seguro que las técnicas modernas es falsa. Si bien este enfoque tiene la calidad de irreversibilidad que es esencial para el almacenamiento de contraseñas y tiene las defensas de cómputo adecuadas, carece de las defensas de rendimiento necesarias para prevenir incluso un ataque de diccionario simple.

Algoritmos de hash de almacenamiento de contraseñas modernos como bcrypt y scrypt están diseñados para ejecutarse con lentitud incluso en hardware especializado. Por otro lado, los algoritmos de cifrado están diseñados para ser lo más eficaces posible. Por lo tanto, un ataque de diccionario sin conexión para descifrar las contraseñas que fueron cifradas con una clave pública será mucho más rápido (probablemente muchos órdenes de magnitud) que un ataque similar que intente descifrar los hash de bcrypt o scrypt.

TLS usa una clave pública y privada para cifrar una sesión. Los clientes solo tienen el certificado que contiene la clave pública, pero para usarlo, el servidor contiene la clave privada. Fuera del servidor, esta comunicación es segura. Dentro del servidor, un atacante podría aprender la clave y descifrar las comunicaciones.

Si utilizamos el cifrado de la clave pública / privada para cifrar una contraseña y un atacante ingresa al servidor, pueden aprender la clave privada y luego descifrar todas las contraseñas.

El hash no tiene clave (aunque puede usar "sal"). A menudo se le llama función unidireccional, por lo que, a diferencia del cifrado, no tiene algoritmo "inverso". Si hash datos, no puedes deshacerlos fácilmente. Todavía puedes atacar con fuerza bruta un hash al intentar cada contraseña que puedas imaginar, y si los hashes coinciden, lo has adivinado. Pero no hay un valor mágico que recupere todas las contraseñas. Es por eso que el hashing almacena las contraseñas de forma más segura que el cifrado.

Con respecto a las fallas en MD5, SHA-1, etc., recuerde que hay varios usos para las funciones criptográficas de hash, y que las vulnerabilidades a las que se expone difieren según el caso de uso. Un uso para un hash es generar un resumen del mensaje, que es un número único que ayuda a validar una parte del texto sin cambios (como los datos contenidos en un certificado). Si se puede falsificar un segundo documento con el mismo valor de resumen, luego, un atacante podría crear un certificado falso y realizar un ataque de hombre en el medio a todos los usuarios del servidor. Pero si se encuentra una colisión entre dos contraseñas en una base de datos, corre el riesgo de filtrar solo la información de que tanto Ulkoma como JohnDeters eligieron la misma contraseña. Eso conlleva riesgos solo para dos personas en lugar de para cada usuario del sistema, lo que en general es un problema menos grave.

La propuesta de generar una clave pública única para cada usuario (descartar la clave privada), luego cifrar y almacenar la contraseña, da como resultado un sistema equivalente funcionalmente al uso de un hash salado. El atacante no tiene que descifrar la clave pública, solo tiene que intentar cifrar un montón de contraseñas con la clave pública hasta obtener una coincidencia.

La generación de un par de claves lleva tiempo, incluso con las computadoras modernas, toma varios segundos. No se necesitaría mucho esfuerzo para causar problemas con el rendimiento del servidor si tiene que generar una gran cantidad de pares de claves.

Además, almacenar una contraseña encriptada y una clave para cada una de ellas requeriría más almacenamiento que almacenar un hash o un hash más un salt para cada una. Para sitios pequeños, esto podría no ser una preocupación importante, pero cuando tiene millones de usuarios, se convierte en un problema potencial.

Efectivamente, el proceso sugerido es un proceso hash, simplemente menos eficiente que el uso de una rutina diseñada para hash entradas.

Tenemos mejores herramientas para esto, la función criptográfica hash, por lo que podría considerarse como un taladro eléctrico como un martillo. Funciona, y es una herramienta mucho mejor para algunos trabajos, pero tiene muchas más piezas móviles y un costo más alto que el martillo, ¡lo que hará un trabajo fantástico para meter las uñas!

Si se expone la clave del texto cifrado, dejará comprometida su db. Estas contraseñas se pueden descifrar y utilizar para iniciar sesión en su sitio o en cualquier otro sitio donde el usuario usó la misma contraseña (o similar) inmediatamente.

Los algoritmos de cifrado criptográfico seguro no son reversibles y permiten más tiempo para gestionar una infracción, ya que deberán ser forzados a la fuerza bruta.

No entiendo TLS lo suficiente como para comentarlo, pero la idea sigue siendo la misma. Con el hash, estás limitado a las técnicas de fuerza bruta y con el cifrado solo necesitas el acceso a la clave.

Editar: Otro beneficio del hashing es que protege mejores contraseñas mejor . En un caso donde la mayoría de sus usuarios utilizan contraseñas muy complejas y largas, será mucho más difícil violar muchas cuentas. El cifrado deja expuestas las contraseñas de todas .