SHA-512 unix password. Quanto sono sicuri quegli hash, davvero?

Le cifre che citi riguardano il numero di password provate al secondo. Poiché questa funzione di hashing della password è salata, gli autori di attacchi non possono attaccare più di una password con hash alla volta; allo stesso modo, non saranno in grado di costruire e riutilizzare tabelle precalcolate ("tavole arcobaleno"). Inoltre, la funzione è configurabile con un numero di iterazioni ("round") in modo che tu possa adattarlo a un compromesso tra la quantità di CPU che sei disposto a spendere per ogni verifica della password e la quantità di CPU che vuoi attaccante da spendere per ogni tentativo di cracking. Se raddoppi il numero di round, rendi il lavoro due volte più difficile per tutti, hai incluso.

Il numero predefinito di round (5000) era pensato per essere sopportabile sui computer medi di quel tempo; i PC recenti sono più veloci e aumentare il numero di round per la tua macchina sarebbe una buona idea.

Ciononostante, gli attaccanti possono usare hardware speciale, in particolare GPU, per ottenere una spinta. L'aumento dipende da come la funzione è calcolata internamente. SHA-512 consiste in molte operazioni aritmetiche a 64 bit, e le GPU non sono del tutto a loro agio, quindi la spinta ottenuta con una GPU (rispetto alla CPU generica, con lo stesso budget) non è così alta come sarebbe con SHA-256 (che utilizza solo operazioni a 32 bit). Tuttavia, si prevede che una GPU sarà una dozzina di volte più veloce di una CPU nel tentativo di decifrare le password. Le cifre esatte dipendono molto dalla CPU e la GPU usata, ma sì, è possibile un accelerazione di 100x (sospetto che tu sottovaluti la tua CPU, però: è multicore, e, inoltre, ha alcune abilità di calcolo parallelo intrinseche con SSE2 o AVX registri).

Altre funzioni si basano su più operazioni di accesso alla memoria che rendono l'attività più difficile per una GPU, ad es. bcrypt e scrypt. Vedi questa risposta per molte informazioni sull'hash della password, e quello per un trattamento specifico di bcrypt contro PBKDF2 (ai fini della discussione qui, PBKDF2 è paragonabile alla funzione% dicrypt() di Unix di cui stiamo parlando).

In ogni caso, la difesa corretta non è quella di avere una password debole. Se la tua password è # 11500 nella lista degli attaccanti, allora è molto debole. Una password ragionevole ha almeno 30 bit di entropia, quindi in media l'attaccante dovrà provare 500 milioni di loro prima di craccarlo. A 11500 al secondo, hai qualche ora prima di te. Con un po 'più di memoria, puoi ottenere più di 40 bit di entropia e trasformare questa "poche ore" in "diversi anni ".

Vedi questa domanda per le discussioni su entropia della password. Inoltre, ricorda che l'hashing della password è una seconda linea di difesa che entra in azione solo quando si è già verificata una violazione parziale: in un contesto Unix, non si suppone che /etc/shadow sia leggibile da utenti non root, per non parlare di client esterni. Quindi non preoccuparti troppo dell'hash delle password e concentrati sul non permettere l'iniezione SQL o il buffer overflow.

I numeri sono corretti.

Il punto principale qui è che sia MD5 che SHA sono pensati per essere veloci. Sono destinati al controllo del contenuto che deve essere il più veloce possibile. E i computer moderni hanno anche le proprie istruzioni per calcolarli sull'hardware.

La più grande differenza tra MD5 e SHA512 è lo spazio delle chiavi e la probabilità di una collisione degli hash in SHA512 è minore di un margine piuttosto ampio rispetto a MD5. Vedi le vulnerabilità MD5 Collision .

Lo spazio delle chiavi non ha un ruolo particolarmente importante nella sicurezza della tua password.

Per sicurezza crittografica dovresti utilizzare una funzione lenta come scrypt.

E per rispondere alla tua altra domanda:

Or does it mean on average, 11,500 user accounts can be cracked per second? Now that would be truly impressive.

Bene, il "cracking" dipende dalle password e dal fatto che i sali siano usati o meno.

Il numero indica "quanti hash possono questa cosa al secondo".

Quindi se non hai sale e il cracker trova che il 5000 round hash per il testo in chiaro 'foobar' è 'abc123def' può quindi controllare se questo hash è stato trovato nel file / etc / shadow. Il problema di non avere sale è che due utenti diversi potrebbero avere la stessa password e entrambi verrebbero scoperti contemporaneamente poiché i loro hash sarebbero uguali.

Quando usi password salate, l'utente malintenzionato non può utilizzare le tabelle arcobaleno precalcolate, ma deve attaccare ogni utente separatamente con il suo propri sali.

Credo che c / s in questo caso significhi calcoli / secondo. Quando viene utilizzato un sale, è necessario ricalcolare tutto per ogni singolo hash. Se non si utilizza sale, è possibile calcolare tutto in una volta.

Ecco una tabella dei benchmark recenti su diverse GPU. Come puoi vedere quei numeri sono altrettanto alti (so che SHA-512 non è lì ma dovrebbe darti un'indicazione). Quella è la quantità di hash calcolati per hash. Se aggiungi round, allora hai bisogno di ogni round count come un singolo calcolo hash. Sempre più persone si stanno muovendo verso Bcrypt e Scrypt che sono stati progettati per essere piuttosto ostici da eseguire su una GPU poiché richiedono una notevole quantità di memoria. Scrypt è anche meglio di Bcrypt, ma mi piacerebbe fare riferimento a questa risposta qui Gli esperti di sicurezza consigliano bcrypt per l'archiviazione delle password?

Ora la GPU più veloce in quella lista può calcolare circa 2 656 000 000 hash al secondo (non crack, calcolare!). Una normale password ASCII può contenere 95 caratteri (ASCII ha solo 95 caratteri stampabili). Per calcolare la quantità di possibili caratteri e supponendo che normalmente una password sia di circa 8 caratteri, arriviamo a 95^8 = 6.6 quadrillion ( 6 634 204 312 890 625 ) possibilità. Per craccarli tutti, se usano 5000 round arriviamo a: 2 656 000 000/5000 = 531 200 c/s . che è significativamente inferiore al tuo esempio, ma supponiamo che stiano utilizzando una farm GPU e che possano effettivamente calcolare a 11 500 000 c/s a 5000 round. Veniamo a 6.6 quadrillion/11 500 000 = 573 913 043 secondi per calcolare tutti gli hash.

Ci sono 3600 secondi in un'ora, 24 ore in un giorno quindi: 573 913 043 seconds / (24 * 3600) = 6642 days . Sono ancora 18 anni (!) Da molto tempo per decifrare quelle password e stiamo solo considerando ASCII che non ha tanti caratteri speciali. Getta un po 'di sale e le cose vanno più piano. Rendi la password lunga un carattere e diventa 100 volte più lenta. Rendilo più lungo di 12 caratteri (che consiglio sempre di usare come minimo per account amministrativi come root) e beh questo è 540 sextillion per te. Quindi anche

Prenderò una pugnalata nel rispondere alla domanda sottolineando che hash e sale dovrebbero essere in un file che è molto ben custodito dal sistema operativo.

Una politica di sicurezza ragionevole dovrebbe limitare le richieste di autenticazione in entrata a una percentuale che non può consentire più di, ad esempio, 100 tentativi di immissione della password al giorno.

Se l'attaccante possiede i tuoi contenuti di /etc/shadow , è necessario avere cose più grandi di cui preoccuparsi. Normalmente sarebbe una situazione forzata estremamente .

Questo è probabilmente il motivo per cui troppe persone sono eccessivamente preoccupate della configurazione degli schemi di hashing delle password a prova di proiettile: non rivelare l'hash e il sale. Se esiste il rischio di farlo, abort . Dovrebbe funzionare bene anche per quel vecchio materiale MD5; è solo che con quello, l'hash, se compromesso, è molto più rivelatore.

Potrei sbagliarmi su questo punto, questo è abbastanza importante (come in cripto tutti i bit devono funzionare bene o è tutto inutile), considero solo la sicurezza di qualcosa come SSL per essere un po 'più in alto nella lista delle priorità .

Detto questo, il mio esempio di vita reale è che sto distribuendo la password di root iniziale della mia macchina su HTTP a causa di limitazioni con il supporto di avvio del programma di installazione. Perché non lo faccio in un modo più sicuro? Perché sono pazzo del genere.

La soluzione? Crea una password dannatamente lunga e cambialo dopo che la macchina è arrivata online. Ciò riduce le possibilità di successo di un attacco a zero.

In realtà non riesco a vedere un modo semplice per aggirare il problema utilizzando una crittografia basata su scrypt per esempio, che è molto lento da attaccare: è necessario impostare una password di root per poter accedere in ordine essere in grado di digitare la passphrase di crittografia di scrypt. Quindi, potrebbe non essere possibile finché il sistema operativo non viene fornito con un modulo di crittografia che lo supporta.

Vedo la possibilità di ottenere la nuova macchina per compilare scrypt da sola e impostare automaticamente un livello di autenticazione separato basato su quello. Ci saranno sicuramente molti pezzi per sbagliare con un simile sforzo.

(Intendo, comunque, impacchettare una chiave privata SSH crittografata con scrypt in modo che possa essere al sicuro per un periodo un po 'più lungo dell'hash della password)