Perché i siti Web archiviano le password "hash" e non i loro ciphertexts?

La mia comprensione è che ritieni che le password sarebbero più sicure se fossero archiviate avendo il sito:

1. Genera una coppia di chiavi pubblica / privata univoca.
2. Disporre immediatamente la chiave privata in modo sicuro.
3. Cripta la password con la chiave pubblica.
4. Archivia la chiave pubblica e la password crittografata nel database, in modo simile alla pratica comune di memorizzare la password salt e hash.

La tua affermazione che questo modello di archiviazione per le password sarebbe più sicuro delle tecniche moderne è falso. Mentre questo approccio ha la qualità di irreversibilità che è essenziale per la memorizzazione delle password e ha adeguate difese di precomputazione, non ha le difese prestazionali necessarie per prevenire anche un semplice attacco di dizionario.

Moduli di hashing di archiviazione delle password moderni come bcrypt e scrypt sono progettati per essere lenti da eseguire anche in presenza di hardware specializzato. D'altra parte, gli algoritmi di crittografia sono progettati per essere il più performante possibile. Quindi un attacco di dizionario offline per decifrare le password che sono state crittografate con una chiave pubblica sarà molto più veloce (probabilmente molti ordini di grandezza) di un attacco simile che tenta di crackare gli errori bcrypt o scrypt.

TLS utilizza una chiave pubblica e privata per crittografare una sessione. I client hanno solo il certificato contenente la chiave pubblica, ma per poterlo utilizzare, il server contiene la chiave privata. Al di fuori del server, questa comunicazione è sicura. All'interno del server, un utente malintenzionato può apprendere la chiave e decrittografare le comunicazioni.

Se utilizziamo la crittografia a chiave pubblica / privata per crittografare una password e un utente malintenzionato accede al server, possono apprendere la chiave privata e quindi decrittografare tutte le password.

L'hashing non ha una chiave (anche se può usare "salt".) Spesso viene chiamata una funzione a senso unico, quindi a differenza della crittografia non ha algoritmo "inverso". Se si cancellano i dati, non è possibile annullarli facilmente. Puoi ancora attaccare alla forza bruta un hash provando tutte le password che ti vengono in mente, e se gli hash corrispondono, hai indovinato. Ma non esiste un valore magico che recuperi tutte le password. Ecco perché l'hashing memorizza le password in modo più sicuro rispetto alla crittografia.

Per quanto riguarda i difetti in MD5, SHA-1, ecc., ricorda che ci sono diversi usi per le funzioni hash crittografiche e che le vulnerabilità che ciascuna espone differiscono in base al caso d'uso. Un uso per un hash è generare un digest di messaggi, che è un numero univoco che aiuta a convalidare una parte di testo non modificata (come i dati contenuti in un certificato). Se un secondo documento può essere falsificato con lo stesso valore di digest, quindi un utente malintenzionato potrebbe creare un certificato falso ed eseguire un attacco man-in-the-middle su tutti gli utenti del server. Ma se si trova una collisione tra due password in un database, rischia di perdere solo l'informazione che sia Ulkoma che JohnDeters hanno scelto la stessa password. Ciò comporta rischi per due sole persone invece che per ogni utente del sistema, che nel complesso è un problema meno grave.

La proposta di generare una chiave pubblica univoca per ogni utente (scartando la chiave privata), quindi crittografare e memorizzare la password, produce un sistema funzionalmente equivalente all'utilizzo di un hash salato. L'hacker non deve crackare la chiave pubblica, devono solo provare a crittografare un gruppo di password con la chiave pubblica fino a quando non ottengono una corrispondenza.

Generare una coppia di chiavi richiede tempo - anche con i computer moderni, ci vogliono diversi secondi. Non ci vorrebbe tanto sforzo per causare problemi con le prestazioni del server se devi generare un numero elevato di coppie di chiavi.

Inoltre, la memorizzazione di una password crittografata e una chiave per ciascuno richiederebbe più spazio di archiviazione di un hash o un hash più un salato per ciascuno. Per i siti di piccole dimensioni, questo potrebbe non essere un problema serio, ma quando hai milioni di utenti, diventa un potenziale problema.

In effetti, il processo suggerito è un processo di hash, meno efficace di una routine progettata per gli input hash.

Abbiamo strumenti migliori per questo - la funzione di hash crittografica - quindi questo potrebbe essere considerato come usare un trapano elettrico come un martello. Funziona, ed è uno strumento molto migliore per alcuni lavori, ma ha molte più parti in movimento e un costo maggiore rispetto al martello, il che farà un fantastico lavoro di ottenere chiodi!

Se la chiave per il testo cifrato viene esposta lascerà il tuo db compromesso. Queste password possono essere decodificate e utilizzate per accedere al tuo sito o qualsiasi altro sito in cui l'utente abbia utilizzato immediatamente la stessa password (o simile).

Gli algoritmi di hashing crittografici sicuri non sono reversibili e consentono più tempo per gestire una violazione poiché devono essere forzati brutalmente.

Non capisco abbastanza TLS per commentare, ma l'idea rimane la stessa. Con l'hashing, sei limitato alle tecniche a forza bruta e con la crittografia hai solo bisogno dell'accesso alla chiave.

Modifica: un altro vantaggio per l'hashing è che protegge le password migliori migliori . In un'istanza in cui la maggior parte degli utenti utilizza password molto complesse e lunghe, sarà molto più difficile violare molti account. La crittografia lascia le tutte password esposte.