RSA vs PBKDF2 per l'archiviazione delle password (teorico)

Question

RSA vs PBKDF2 per l'archiviazione delle password (teorico)

#1 da (5 voti)

4

So che non è il modo giusto per archiviare le password, ma lo sto chiedendo da una prospettiva teorica:

Supponiamo che le password di un sito Web siano state crittografate con la crittografia asimmetrica RSA e che la chiave di decodifica privata sia stata scartata, rendendola effettivamente un viaggio a senso unico. Ora questi "digesti" password sono stati in qualche modo trapelati.

Ci vorrebbe più tempo per decifrare le password criptate di RSA di quante ne creerebbe le password se fossero state sottoposte a hash con PBKDF2?

password-management rsa password-cracking pbkdf2

posta John 06.06.2013 - 20:19

fonte

1 risposta

Leggi altre domande sui tag password-management rsa password-cracking pbkdf2

Server che controlla la password del client senza mai entrarne in possesso Qual è lo svantaggio dell'uso della versione protetta del protocollo ARP con spoofing

score 5 · Accepted Answer

Le due situazioni non sono paragonabili. Infatti, la crittografia RSA, come tutti gli altri algoritmi di crittografia asimmetrica, è un processo randomizzato: se si codificano gli stessi dati due volte, con la stessa chiave pubblica, si fa non ottenere lo stesso messaggio crittografato due volte. Questo è di progettazione : poiché la crittografia asimmetrica utilizza la chiave pubblica che è, yay, pubblica, tutti può crittografare i dati con quella chiave. Dal momento che vogliamo evitare una ricerca esauriente sui dati stessi, abbiamo bisogno di questo comportamento non deterministico. Come descritto in PKCS # 1 , almeno 8 byte di riempimento casuale vengono aggiunti ai dati di input prima applicare l'esponenziazione modulare che è al centro della crittografia RSA.

Questo ha due conseguenze:

Questo potrebbe non essere risolto enumerando le password possibili. Se l'utente malintenzionato "indovina" la password corretta, non può ancora sapere se la password corrisponde a quella crittografata.
Nessuno può sapere se una determinata password corrisponde a ciò che è stato crittografato. Pertanto, una password crittografata con RSA non può essere utilizzata per verificare le password (se la chiave privata viene persa), contrariamente a una versione hash della password. Le tue password sono uguali a quelle perse e nessun server sarà in grado di stabilire se una determinata password è corretta o meno utilizzando queste password crittografate con RSA.

Quindi non ha senso confrontare i "tempi di cracking" tra RSA e PBKDF2.

Ora, naturalmente, un programmatore di aspiranti aspiranti potrebbe aver immaginato qualcosa che assomiglia vagamente all'RSA, ma senza il padding casuale, e quindi può essere usato come un hash della password. Questo sarebbe davvero un hash password (fatto in casa). Supponendo che il suddetto programmatore non l'abbia complicato troppo (un'ipotesi già abbastanza ottimistica), allora si applicherebbe la forzatura bruta, con la stessa efficienza consentita dall'algoritmo: si tratta semplicemente di provare le password, un processo che va veloce come l'algoritmo è veloce. Inoltre, probabilmente, questo hashing della password non proprio RSA non sarebbe corretto, consentendo l'attacco parallelo di più password con la condivisione dei costi. PBKDF2 include i sali e anche la lentezza configurabile (con un conteggio delle iterazioni), proprio per resistere meglio a tali attacchi.