Qualunque hash di password può mai essere sicuro?

21

La mia comprensione è il motivo principale per cui MD5 non è sicuro, è che può essere calcolato troppo rapidamente, consentendo troppi tentativi di essere provato. Le persone consigliano invece di utilizzare un hash che è stato progettato per deliberatamente lento , per fornire una sicurezza migliore.

Tuttavia, questo fornisce sicurezza solo alla velocità di calcolo corrente. Una volta che i computer diventano più veloci, questi non saranno migliori di md5. Quindi mi chiedo, è anche possibile avere una funzione di hash che è sicura, indipendentemente dal tempo necessario per l'esecuzione?

    
posta Benubird 09.12.2015 - 16:12
fonte

6 risposte

14

In primo luogo, MD5 ha altri problemi oltre alle veloci velocità di hashing, comprese le vulnerabilità di collisione .

Once computers become faster, then these will be no better than md5. So I wonder, is it even possible to have a hash function that is secure, irrespective of the time it takes to execute?

No, una stessa funzione hash potrebbe sempre essere incrinata usando un computer sufficientemente veloce (sufficientemente veloce essendo l'ambiguo proiettile d'argento). Tuttavia, le implementazioni degli algoritmi di hashing possono risolvere questo .

Ad esempio, bcrypt fornisce meccanismi per affrontare l'aumento della velocità di calcolo.

bcrypt utilizza il concetto di round per calcolare gli hash. Ad esempio, bcrypt cancellerà la tua password con un salt e un numero di round:

bcrypt("password","salt",10000)

Note: As pointed out by darkhogg, the rounds parameter isn't actually submitted to bcrypt. Instead a work factor is sent. The difference being that what is sent is actually a number N which is the exponent used to calculate the rounds. So although 10,000 is used here as an example for the number of rounds, the actual work unit you would need to supply to get 10,000 rounds would be much smaller.

esegue l'hash della combinazione di sale e password per 10.000 volte prima di memorizzare l'hash, il sale e il numero di round. Supponiamo quindi che al momento iniziale dell'implementazione siano necessari 10.000 round di hashing .02 secondi. Un anno dopo l'implementazione iniziale, si nota che 10.000 round richiedono solo 0,1 secondi o metà del tempo. Puoi cambiare i turni a 20.000. La prossima volta che un utente effettua l'accesso, il suo hash verrà calcolato con 10.000 round per l'autenticazione, ma l'hash verrà archiviato con 20.000 round, per l'autenticazione futura.

    
risposta data 09.12.2015 - 16:17
fonte
25

So I wonder, is it even possible to have a hash function that is secure, irrespective of the time it takes to execute?

No, certo che no. Pensa a una funzione di hash come qualcosa che assorbe qualsiasi stringa e genera una breve impronta digitale di quella stringa. Se ho un computer abbastanza veloce da elencare tutte le possibili stringhe e calcolare le loro impronte digitali (ovvero i valori hash), allora posso costruire una tabella di ricerca mappando ogni valore hash alla stringa che la produce. Con un computer infinitamente veloce con una memoria infinitamente grande posso costruire una tabella di ricerca che spezza qualsiasi funzione hash, anche teorica. Periodo.

Per una vera funzione di hash come SHA2 che ha un output a 256-bit, supponi di essere stato magicamente passato a quella tabella di ricerca per tutti i 2 256 possibili output, e presumi che ci vogliano 25 ms per esegui ogni hash, ti richiederebbe 6.7x10 57 x età dell'universo solo per verificare che la tabella di ricerca sia corretta. Ora, se invece di essere consegnato alla tabella di ricerca, dovevi calcolarlo da solo attraverso tentativi ed errori, quel numero sarebbe ancora più grande. Quindi sì, tutte le funzioni di hash possono essere interrotte da un "computer veramente veloce", ma come veramente veramente veloce, come le età dell'universo più veloce di qualsiasi computer che abbiamo oggi. [Come sottolineato da @ BlueRaja-DannyPflughoeft nei commenti, ottenere abbastanza elettricità per fare questo calcolo richiederebbe il consumo di diverse stelle quindi non è fisicamente possibile per una società pre-interstellare]

Il motivo per cui gli attacchi sono trattabili con le moderne funzioni di hash, che ci costringe a fare trucchi come il sale e l'iterazione per renderli più lenti, è che per cose come le password non è necessario controllare tutti i 2 256 possibili pre-immagini. Se tutti usassero generatori di password casuali questo sarebbe vero, ma la gente no ... infatti l'1,5% di noi (1 su 68 persone) usa la password "123456" (source) . Quindi è sufficiente controllare le cose che le persone usano comunemente come password. Un elenco delle password più comuni da 100 k consente di accedere a quasi tutti gli utenti su Internet, che un computer modesto può verificare in pochi minuti se sono stati sottoposti a hash solo una volta. Compensiamo le password deboli delle persone rendendo più lunghi i calcoli di hash. Se sono salati e generati 10.000 volte, pochi minuti su hardware modesto possono arrivare fino a mesi su un impianto GPU personalizzato.

In sintesi; molti dei problemi che abbiamo con gli hash non sono dovuti al fatto che gli hash stessi sono deboli, ma perché chiediamo loro di proteggere i dati che è facile indovinare.

    
risposta data 09.12.2015 - 16:20
fonte
3

Come hanno affermato Mike Ounsworth, amccormack e Romain Clair nelle loro risposte, se disponi di poteri di calcolo illimitati, sarai in grado di interrompere qualsiasi algoritmo hash semplicemente (pre) calcolando ogni possibile input.

La tua vera domanda è probabilmente: Di cosa ho bisogno per l'hash e per quanto tempo lo salverò? Quindi se usi hash per memorizzare password ti consiglio questo link: Come fare in modo sicuro le password di hash?

Ma se ne hai solo bisogno perché vuoi calcolare in modo univoco un identificatore temporaneo per qualche input, allora md5 potrebbe comunque essere sufficiente per te.

    
risposta data 09.12.2015 - 16:29
fonte
3

La sicurezza di tutto è sempre in uno stato di cambiamento. 40 anni fa l'algoritmo DES era anche considerato ampiamente sicuro, ma l'aumento della velocità di elaborazione lo ha reso vulnerabile con una quantità piuttosto limitata di hardware dedicato.

30 anni fa l'algoritmo Unix Crypt (anch'esso basato su DES) era considerato abbastanza lento da generare password con hash per essere sicuro. Adesso è obsoleto.

Più algoritmi di hashing della password moderni come bcrypt sono progettati per avere una difficoltà variabile per tenere conto dell'aumento della velocità di elaborazione. Così come aumenta la potenza di calcolo, la difficoltà dell'algoritmo può essere aumentata per tenere il passo. È semplicemente improbabile che la potenza di calcolo grezza che abbiamo visto negli ultimi 40 anni possa rendere obsoleto bcrypt.

La sicurezza esiste all'interno di un contesto e il contesto cambia continuamente. Tuttavia, possiamo solo tenere conto dei cambiamenti che possiamo prevedere. Gli aumenti della potenza di calcolo sono cambiamenti prevedibili. Non possiamo tuttavia pianificare una rottura dell'algoritmo (come è successo con MD5).

Il punto è che qualsiasi sicurezza potrebbe essere potenzialmente rotta in qualsiasi momento. La sicurezza non è mai garantita.

    
risposta data 09.12.2015 - 16:53
fonte
2

Risposta breve no.

La maggior parte dei crittosistemi utilizzati oggi, comprese le funzioni di hash, sono sicuri solo contro un utente malintenzionato che ha una potenza di calcolo limitata. Possono essere tutti sconfitti usando la forza bruta, ma ci vorrà molto molto tempo per realizzarlo.

Ma è davvero utile provare a infrangere un codice se ci vogliono più di 100 anni di calcolo intenso ed esteso?

    
risposta data 09.12.2015 - 16:19
fonte
2

Once computers become faster, then these will be no better than md5.

Saranno comunque migliori ma forse non sufficientemente migliori.

Fondamentalmente un utente malintenzionato blocca (correttamente salato) gli hash delle password prendendo le password possibili e eseguendole attraverso la funzione di controllo della password. Quindi

Tempo di crack della password hash = (tempo di controllare una password con un hash) * (il numero di password che l'utente malintenzionato deve provare)

So I wonder, is it even possible to have a hash function that is secure, irrespective of the time it takes to execute?

No.

    
risposta data 09.12.2015 - 21:36
fonte

Leggi altre domande sui tag