RSA vs PBKDF2 para el almacenamiento de contraseñas (teórico)

Question

RSA vs PBKDF2 para el almacenamiento de contraseñas (teórico)

#1 de Thomas Pornin (5 votos)

4

Sé que esta no es la forma correcta de almacenar contraseñas, pero lo pregunto desde una perspectiva teórica:

Suponga que las contraseñas de un sitio web se cifraron con el cifrado asimétrico RSA y la clave de descifrado privada se descartó, lo que lo convierte en un viaje de ida. Ahora estos "compendios" de contraseñas se filtraron de alguna manera.

¿Llevaría más tiempo descifrar las contraseñas cifradas RSA que descifrar las contraseñas si se hubieran pirateado con PBKDF2?

password-management rsa password-cracking pbkdf2

pregunta John 06.06.2013 - 20:19

fuente

1 respuesta

Lea otras preguntas en las etiquetas password-management rsa password-cracking pbkdf2

impide que un usuario no autorizado tenga acceso a la intranet Verificación de la huella dactilar SSH de un servidor público

score 5 · Accepted Answer

Las dos situaciones no son comparables. De hecho, el cifrado RSA, como todos los demás algoritmos de cifrado asimétrico, es un proceso aleatorio: si cifra los mismos datos dos veces, con la misma clave pública, no recibe el mismo mensaje cifrado dos veces. Esto es por diseño : dado que el cifrado asimétrico utiliza la clave pública que es, yay, public, todos pueden cifrar los datos con esa clave. Como queremos evitar una búsqueda exhaustiva de los datos en sí, necesitamos este comportamiento no determinista. Como se describe en PKCS # 1 , se agregan al menos 8 bytes de relleno aleatorios a los datos de entrada antes aplicando la exponenciación modular que es el núcleo del cifrado RSA.

Esto tiene dos consecuencias:

Esto no se puede descifrar enumerando las contraseñas posibles. Si el atacante "adivina" la contraseña correcta, aún no puede saber si la contraseña coincide con la cifrada.
Nadie puede decir si una contraseña determinada coincide con lo que se ha cifrado. Por lo tanto, una contraseña cifrada RSA no se puede utilizar para verificar las contraseñas (si se pierde la clave privada), al contrario de una versión con hash de la contraseña. Sus contraseñas son tan buenas como perdidas, y ningún servidor podrá saber si una contraseña dada es correcta o no al usar estas contraseñas encriptadas RSA.

Por lo tanto, no tiene sentido comparar los "tiempos de craqueo" entre RSA y PBKDF2.

Ahora, por supuesto, algún programador aspirante podría haber imaginado algo que se parece vagamente a RSA, pero sin el relleno aleatorio, y por lo tanto puede usarse como un hash de contraseña. Esto sería de hecho un hash de contraseña (hecho en casa). Suponiendo que dicho programador no lo frustró demasiado (una suposición ya bastante optimista), entonces se aplicaría la fuerza bruta, con tanta eficiencia como lo permita el algoritmo: esto es simplemente una cuestión de intentar contraseñas, un proceso que va tan rápido como El algoritmo es rápido. Además, posiblemente, este hashing de contraseñas no del todo RSA no tendría sal, lo que permitiría un ataque paralelo de varias contraseñas con costos compartidos. PBKDF2 incluye sales y también lentitud configurable (con un recuento de iteraciones), precisamente para resistir mejor tales ataques.