È necessario usare qualcosa come bcrypt o scrypt? Gli hash sono molto più lunghi da archiviare in un database. Si può fare a meno di usare MD5 o SHA salato e rimanere al sicuro?
MD5 e SHA-1 sono enfaticamente scelte sbagliate per l'archiviazione delle password. Il problema non è la loro resistenza alla collisione; è che sono progettati per essere estremamente veloci. Una GPU moderna può tentare fino a miliardi di password al secondo quando si esegue la forzatura bruta attraverso un elenco di hash. Questo può distruggere ogni possibile password alfanumerica di otto caratteri al massimo qualche giorno; è con una sola GPU.
Il vantaggio di bcrypt e scrypt è che possono consumare arbitrariamente molte risorse; bcrypt ha requisiti CPU configurabili, scrypt ha requisiti CPU e memoria configurabili. Aumentando questi fattori di lavoro, è possibile aumentare notevolmente la quantità di sforzi necessari a un utente malintenzionato per tentare anche una singola password nel database.
Per quanto riguarda la lunghezza: è il 2014. Lo storage è essenzialmente infinitamente economico. Salvare 40 byte per record non è semplicemente una scusa accettabile per selezionare algoritmi di hashing della password noti. In qualunque progetto tu stia lavorando, sicuramente ci sono compiti più utili su cui investire le tue limitate risorse di sviluppo.
Non c'è, infatti, niente di simile a "salted MD5" o "salted SHA-1". MD5 e SHA-1 sono funzioni di hash ben definite, che prendono come input una sequenza di bit di lunghezza (quasi) arbitraria e generano una sequenza di bit di lunghezza fissa (128 e 160 bit, rispettivamente). Non c'è sale ovunque nelle definizioni di MD5 e SHA-1; neanche la password, per quello.
Ciò che le persone chiamano "salted MD5" o "salted SHA-1" sono in realtà una nuova costruzione crittografica, assemblando alcune convenzioni di codifica (per trasformare la password in una sequenza di bit) e un valore salt (un'altra sequenza di caratteri o bit ) in una (o alcune) invocazioni della funzione di hash. Ci sono molti modi possibili per farlo e nessuno standard. Nella migliore delle ipotesi, possiamo avere una famiglia di disegni che possono essere raggruppati sotto la terminologia generica "MD5 con un po 'di sale". Crittograficamente, queste costruzioni non devono essere equivalenti l'una all'altra; alcuni potrebbero essere piuttosto poveri.
Anche supponendo che il tuo specifico "MD5 salato" capiti di non compromettere le cose, hai ancora il problema principale di MD5 (o SHA-1), e cioè velocità . Velocità significa che gli attaccanti possono provare molte potenziali password al secondo; i numeri sono in miliardi al secondo (benchmark lì ). Se vuoi "scappare" con MD5 o SHA-1 salato allora devi combattere quella velocità con più password entropia . Non la lunghezza della password, attenzione! la lunghezza è solo approssimativamente correlata alla sicurezza. Aggiungere più caratteri non aiuta; aggiungendo più caratteri di cui l'autore dell'attacco non conosce è ciò che aiuta.
Realisticamente, se devi scappare con MD5 o SHA-1 salato, devi utilizzare almeno 60 bit di entropia in ciascuna password. Questo non è realistico: gli utenti medi non produrranno o ricorderanno tali password. Nella migliore delle ipotesi, puoi considerarti felice se i tuoi utenti raggiungono 30 bit di entropia. In altre parole, con MD5 o SHA-1 salato, non raggiungerai il livello di sicurezza richiesto di un fattore un miliardo o giù di lì. Queste sono scarse probabilità; per fare un'analogia, questo sarebbe simile al tentativo di invadere gli Stati Uniti da militari quando il tuo intero esercito consiste in un solo soldato armato di mazza da baseball. Stallone non riuscito . Anche Chuck Norris lo troverebbe difficile.
Vai a leggere queste risposte:
E vai a comprare un nuovo disco! Il mio primo vero disco rigido (nel 1991) aveva una dimensione di 40 megabyte e sarebbe stato idoneo per archiviare gli hash di bcrypt per oltre mezzo milione di utenti. Il tuo server ha 23 anni di hardware e hai oltre mezzo milione di utenti? Se è così, ti saluto per il tuo coraggio e ti suggerisco caldamente di andare a dormire in qualche asilo con assistenza medica. Altrimenti, l'argomento "hash sono molto più grandi" è, non c'è un modo carino per dirlo, davvero stupido.
Ok, c'è è un metodo sicuro per farla franca con l'utilizzo di MD5 o SHA-1 salato. È sufficiente avere un server così poco interessante e privo di dati non noiosi che gli aggressori non si preoccupino nemmeno di attaccarlo. La pigrizia è ancora la forza più strong nell'universo, dopotutto.
No, non puoi scappare con MD5 o SHA e questo argomento è stato davvero discusso a morte.
Tutti gli algoritmi hash generici come MD5 o SHA sono estremamente vulnerabili agli attacchi a forza bruta, perché sono progettati per la velocità. Ad esempio, una vecchia GPU come HD 6990 può calcolare circa 10 miliardi di hash MD5 al secondo e 4 miliardi di hash SHA-1 al secondo utilizzando oclHashcat .
È facile vedere che anche le password decenti non sopravviveranno a un simile attacco. Ad esempio, la ricerca dell'intero spazio di tutte le password con 6 caratteri alfanumerici richiede solo 6 secondi se si utilizza MD5. E anche 8 caratteri richiedono solo 6 ore. L'aggiunta di sali non cambia questo. Mentre i sali costringono l'attaccante a inseguire individualmente ogni hash, questo non fa molta differenza vista la performance.
Quando si eliminano le password, non si desidera la velocità. Al contrario, la procedura dovrebbe essere molto costosa e lenta. Ecco perché sono necessari algoritmi specializzati per hash delle password come bcrypt e scrypt.
Salting MD5 non è abbastanza buono. MD5 non è resistente alla collisione, il che significa che un utente malintenzionato può creare una password per abbinare qualsiasi dato valore hash (indipendentemente dal fatto che sia effettivamente la password "giusta"). L'attaccante non si cura di quale fosse il valore prima di averlo cancellato, inclusa la salatura che fai; hanno solo bisogno del valore finale per produrre una password valida.
D'altra parte, credo che molte versioni di SHA (almeno SHA-2 e SHA-3) siano ancora considerate sicure, ma non so quale sia lo stato dell'arte per l'archiviazione delle password. A seconda dell'applicazione, potresti volerlo eseguire più volte.
EDIT - A pensarci bene, non sono sicuro che sia possibile invertire MD5 per produrre un particolare salt se si mantiene il sale associato con l'account sul lato server. Sono abbastanza sicuro che MD5 non è ancora raccomandato.