So che le migliori opzioni da utilizzare per memorizzare le password sono bcrypt / PBKDF2 / scrypt.
Tuttavia, supponiamo di dover controllare un sistema e usa SHA-512 con sale. È "bello"? O è una vulnerabilità che deve essere affrontata, anche se il tuo sito è un forum di discussione?
Naturalmente, se è debole, deve essere indirizzato, perché le password degli utenti possono essere utilizzate anche su altri siti. La domanda è - è troppo debole per non tollerarlo come una possibilità.
However, suppose you have to audit a system and it uses SHA-512 with salt. Is that "fine"? Or it is a vulnerability that must be addressed, even thought your site is a discussion forum?
Supponendo che si tratti di un nome per utente di lunga durata crittogena e la tua verifica non deve seguire regole normative o legali particolari, quindi suggerirei un po 'di matematica.
È un forum di discussione, quindi presumo che gli utenti non debbano mai cambiare le loro password. Pertanto, le domande di base sono:
Abbiamo l'equazione di base: - Tempo medio di sicurezza * 2 = Tempo di esaurimento spazio chiave
Utilizziamo le seguenti equazioni utili:
Quindi, se prendiamo questo esempio:
Abbiamo il risultato:
Se andiamo dall'altra parte, abbiamo:
Quindi otteniamo:
Nota che se avessi 1.000 utenti, sarebbe:
Ora, se si presume che gli utenti selezionino password di 8 caratteri crittograficamente casuali, usando maiuscole, minuscole e numeri (buona fortuna!):
Prima scegli i numeri che hanno senso, poi fai i conti. La risposta sarà ovvia dopo.
No, stai risolvendo il problema sbagliato.
Il passaggio da SHA-1 o SHA-256 a SHA-512 non rende il crack hash decisamente più difficile. Gli hash in genere non vengono invertiti per mezzo di alcune proprietà matematiche dell'algoritmo, pertanto l'avanzamento dell'algoritmo non modifica molto la sicurezza.
Invece, gli hash sono forzati brutalmente usando una tecnica di "supposizione e controllo" . Indovina una password, calcola l'hash e poi controlla se hai indovinato. E ripeti e ripeti e ripeti fino a quando non lo ottieni.
Quindi il modo per rallentare l'attaccante è rallentare il processo di hashing. Se occorre più tempo per controllare ogni singola password, l'autore dell'attacco non può indovinarne altrettanti. E in questo caso, SHA-512 non è notevolmente più lento di SHA-256 o SHA-1 o MD5. Quindi non stai aggiungendo alcuna sicurezza.
Invece, il fil rouge tra tecniche come bcrypt, PBKDF2 e scrypt, è che tutti eseguono la funzione di hashing più e più volte, migliaia di volte per una sola ipotesi. Quindi, supponiamo che un sito utilizzi PBKDF2 a 10.000 iterazioni: ciò significa che l'utente malintenzionato deve dedicare più tempo e risorse a una singola ipotesi, come altrimenti dovrebbe fare su un intero dizionario di 10.000 password. Rallentando l'attaccante, limiti il numero di password che alla fine è in grado di indovinare, e quindi diminuisci la probabilità che alla fine indovini correttamente.
Molte installazioni personalizzano la loro configurazione per adattarsi all'hardware esistente. Ad esempio, LUKS utilizza un minimo di 1000 iterazioni, o comunque molti impieghi per consumare 1/8 di secondo, quale è più lungo.
Temo che non sia possibile rispondere se questo è "buono" o meno rispetto a un audit, senza il contesto dell'organizzazione che sta svolgendo il controllo. Un livello di rischio che va bene per una società potrebbe essere del tutto inaccettabile per un altro.
In termini di specifiche tecniche della tua domanda. Supponendo che tu stia utilizzando SHA-512 con sale per utente, questo può essere considerato valido a seconda delle minacce che affronti e dell'impatto di una violazione. È decisamente meglio di MD5 non salato, ma ovviamente non è buono come bcrypt / PBKDF2 / scrypt.
Sarebbe relativamente resistente a cose come gli attacchi da tavolo arcobaleno ma non resistente (come dice @terrychia) ad un attaccante dedicato con strutture di cracking assistito hardware e tempo da spendere.
Quindi, se va bene per te, puoi decidere se ti aspettavi che quel tipo di attaccante colpisse il sito e quale livello di impatto avrebbe avuto una violazione.
Se, ad esempio, una violazione ti costerebbe 1 milione di dollari in perdite dirette / indirette, allora sarebbe una cattiva idea affidarsi a una configurazione che è riconosciuta come non ideale.
Tuttavia, se una violazione ti costerebbe $ 100, è probabile che il tempo di sviluppo necessario per implementare la correzione non varrà la pena.
No, non va bene.
Plain SHA512 può essere rinforzato a velocità piuttosto elevate usando cose come GPU / FPGA / ASIC. Se c'è una possibilità di risolverlo, cambialo definitivamente per usare qualcosa come bcrypt, scrypt o pbkdf2.
Leggi altre domande sui tag passwords