Il motivo principale per utilizzare una specifica funzione di hashing della password è rendere la vita più difficile agli attaccanti o, più precisamente, impedire loro di semplificarsi la vita (rispetto a quella del difensore). In particolare, l'attaccante potrebbe voler calcolare più hash al secondo (ovvero provare più password al secondo) con un determinato budget utilizzando una GPU.

SHA-256, in particolare, beneficia molto dell'implementazione su una GPU. Pertanto, se utilizzi SHA-256-crypt, gli aggressori saranno più avvantaggiati rispetto a bcrypt, che è difficile da implementare in modo efficiente in una GPU.

Vedi questa risposta ​​a > per qualche discussione su bcrypt vs PBKDF2. Sebbene SHA-256-crypt non sia PBKDF2, è abbastanza simile nel comportamento delle prestazioni su GPU, quindi si applicano le stesse conclusioni.

Il caso per SHA-512 è un po 'meno chiaro perché le GPU esistenti sono molto migliori utilizzando numeri interi a 32 bit rispetto a 64 bit e SHA-512 utilizza principalmente operazioni a 64 bit. Si prevede ancora che la GPU moderna consenta più hash al secondo rispetto alla CPU (per un dato budget) con SHA-512-crypt, che ancora una volta indica bcrypt come la scelta migliore.

La famiglia di hash SHA-2 è stata progettata per essere veloce. BCrypt è stato progettato per essere lento. Entrambi sono considerati robusti. Con un numero sufficiente di giri o fattore di lavoro, uno dei due può richiedere più tempo dell'altro, ma preferirei quello che è stato progettato per essere lento. (se il carico del server è un problema, il fattore di lavoro è regolabile)

Inoltre, preferirei BCrypt perché di solito è un'implementazione compilata (C o C ++).

Il multi -round SHA può essere facilmente implementato in un linguaggio di alto livello, almeno per l'iterazione, se non anche per l'hash stesso. I linguaggi di alto livello sono meno efficienti per le operazioni matematiche di base riducendo il numero di round che l'hardware di produzione può completare per millisecondo.

Sebbene entrambi gli algoritmi possano essere implementati in linguaggi di alto o basso livello o ibridi; in BCrypt le opzioni disponibili indicano che hai maggiori probabilità di ottenere un'implementazione efficiente . (ti mette in condizioni di parità con l'attaccante)

Per quanto riguarda il tuo esempio specifico dal file / etc / shadow , probabilmente sei solo su un livello basso ( efficienti) in entrambi i casi. (SHA o BCrypt) In questo esempio ti suggerirei di consultare la documentazione del sistema operativo per ottimizzare i round (fattore di lavoro) in base alla velocità dell'hardware -vs- quanto forte vorresti fosse l'hash .

scrypt (con un fattore di lavoro abbastanza grande) ha il vantaggio aggiuntivo di avere requisiti aggiuntivi di RAM / memoria (non solo CPU), rendendolo più resistente alla GPU rispetto a SHA, BCrypt o PBKDF2.

Modifica: grazie a Thomas per aver sottolineato che BCrypt è più resistente alla GPU di SHA-2 e che SHA-2 e PBKDF2 lo sono praticamente equivalente in questo senso.

Nota. Sto esaminando questa domanda dopo che è stata apportata questa modifica e ne ho tenuto conto:

Nota: Intendo specificamente gli hash delle password multi-round descritti dai documenti collegati e contrassegnati con i codici $ 5 $ e $ 6 $ negli hash crypt, non un singolo round delle semplici funzioni hash SHA256 o SHA512.

Guardando il lungo algoritmo in 22 passaggi in questo link che hai fornito, preferisco fare una domanda: perché preferiresti usarlo invece di PBKDF2 con HMAC-SHA2? Perché, almeno come presentato:

• La definizione di PBKDF2 sembra molto più semplice. Questo perché è più modulare: rimanda la maggior parte del suo lavoro a un esternamente- funzione pseudo-casuale fornita. Questo è normalmente istanziato con HMAC, che a sua volta rimanda la maggior parte del suo lavoro a una funzione hash esterna come SHA-1 o SHA-2.
• Ciò significa che la sicurezza di PBKDF2 dovrebbe essere più facile da analizzare.

Al contrario, l'algoritmo nel documento che fornisci elenca un sacco di passaggi la cui motivazione è più difficile da capire. Ad esempio:

  11. Per ogni bit della rappresentazione binaria della lunghezza della stringa della password fino alla cifra più alta inclusa, a partire dalla posizione del bit più bassa (valore numerico 1): a) per una cifra 1 aggiungi digest B a digest A b ) per una cifra di 0 aggiungere la stringa della password NB: questo passaggio differisce notevolmente dall'algoritmo MD5. Aggiunge più casualità.  

Aggiunge più casualità? Come lo fa? Perché questo passaggio esiste? SHA-2 non aggiunge sufficiente casualità? Se SHA-2 non è abbastanza casuale, perché usarlo in primo luogo? E questo passaggio non introduce ramificazioni dipendenti dal segreto nell'algoritmo, sollevando la questione di possibili attacchi temporizzati contro di esso?

Non sto affatto dicendo che gli algoritmi che colleghi non siano sicuri. È proprio questo:

• Il fattore di lavoro che introducono si riduce alla stessa cosa che farebbe PBDKF2 - HMAC-SHA2 (un gran numero di iterazioni SHA2);
• Sembrano molto sostanzialmente simili a quello che avresti se hai srotolato un'implementazione PBKDF2-HMAC-SHA2, ma con ulteriore complessità di cui non capisco lo scopo;
• Quindi almeno come presentato in quei documenti , lo trovo più difficile per acquisire fiducia sul loro design rispetto a me per PBKDF2.

EDIT: Dopo aver scritto tutto questo sono andato a fare un po 'di ricerca su questo algoritmo per cercare di capirlo meglio. Innanzitutto, dai link "descrizione" e "specifica" della domanda, apprendiamo che l'algoritmo è stato derivato da un vecchio algoritmo basato su MD5 apportando modifiche relativamente minori.

Questo vecchio algoritmo basato su MD5 appare quello che Poul-Henning Kamp scrisse per FreeBSD-2.0 nel 1994, che non considera più sicuro. Nel primo collegamento (dove racconta la storia della funzione), menziona che anche glibc ha adottato la sua funzione. Si collega anche al documento di Provos e Mazières del 1999 su bcrypt e afferma che ha espresso una certa disapprovazione e, stranamente, hanno evidenziato lo stesso passaggio che ha attirato la mia attenzione sopra:

MD5 crypt esegue l'hashing della password e sale in una serie di combinazioni diverse per rallentare la velocità di valutazione. Alcuni passaggi dell'algoritmo fanno dubitare che lo schema sia stato progettato da un punto di vista crittografico: ad esempio, la rappresentazione binaria della lunghezza della password a un certo punto determina quali dati vengono sottoposti ad hashing, per ogni bit zero il primo byte della password e per ogni bit impostato il primo byte di un calcolo hash precedente.

Ma penso che questo spieghi la motivazione delle nuove funzioni di cui chiedi: sono una modifica minima di una vecchia funzione che precede la maggior parte delle moderne funzioni di hash delle password, il cui design è stato messo in discussione ma probabilmente non lo è fondamentalmente rotto, solo inutilmente complesso.

La stessa famiglia SHA-2 non è necessariamente cattiva. In base alla progettazione, non ci sono davvero difetti di sicurezza che rendano preferibili bcrypt o scrypt. Tuttavia, il problema che molti esperti di sicurezza hanno con SHA è che è troppo veloce e non richiede molta memoria. In confronto, una funzione di hashing come scrypt è molto più lenta e costosa, per così dire.

Scrypt richiede una discreta quantità di memoria per il calcolo. Oltre a tutta questa memoria, e in gran parte a causa del bisogno di così tanta memoria, scrypt richiede molto tempo di calcolo rispetto a SHA. Questa risposta dal sito BitCoin Stack Exchange riassume i vantaggi di scrypt piuttosto bene: Quali caratteristiche di scrypt () rendono Tenebrix resistente alla GPU? In sostanza, scrypt è progettato per essere lento e ad alta intensità di memoria. Alle GPU non piace. Le GPU generalmente non hanno la capacità di memoria per archiviare tutta la memoria necessaria per il calcolo dello scrypt senza dover ricorrere a metodi di blocco dell'esecuzione ( dove la GPU blocca tutti i thread perché può solo recuperare i valori dalla memoria condivisa uno alla volta time ), e quindi le GPU non possono fornire alcun grande vantaggio rispetto alle CPU in termini di tempo di elaborazione. Bcrypt è simile.

Bcrypt è provato e vero per l'hashing delle password. Esiste da 17 anni e fa ancora il suo lavoro. Tuttavia, un giorno, la tecnologia GPU avanzerà al punto in cui sarà in grado di calcolare bcrypt in modo più veloce ed efficiente di una CPU. La tecnologia è in continua evoluzione e sviluppo, quindi alla fine accadrà. Quando arriverà quel giorno, bcrypt non sarà più un'ottima scelta per l'hashing delle password, e crittografi ed esperti di sicurezza dovranno sostituire bcrypt con un algoritmo simile che è più lento e richiede più memoria del bcrypt esistente. Forse sarà scrypt, ma chi lo può dire. Allora, perché SHA è disapprovato?

SHA è generalmente scoraggiato non a causa di falle di sicurezza, ma a causa della velocità e della sua capacità di essere implementato su una GPU. Qualcuno con macchine / potenza di calcolo illimitate potrebbe decifrare qualsiasi tipo di algoritmo di hashing, che sia SHA, bcrypt o scrypt, ma questo è teorico. In pratica, un utente malintenzionato non avrà un numero illimitato di macchine su cui provare a decifrare gli hash e, di conseguenza, più puoi rallentare quell'attaccante, più difficile sarà per lui decifrare una password. C'è un limite di budget per tutto e il cracking delle password non fa eccezione. L'aggressore può decifrare le password solo alla velocità consentita dal budget. ( La migliore tecnologia che possono acquistare nei limiti del loro budget, il costo per eseguire tale tecnologia (ad esempio, i costi elettrici), ecc. ) Ovviamente, potresti implementare più round di SHA per rallentare gravemente un aggressore , ma perché non usare semplicemente bcrypt a quel punto? Tra le altre cose, con l'avanzare della tecnologia GPU nel prossimo futuro, sarà necessario aggiungere sempre più round / iterazioni ai calcoli SHA per rallentarlo fino al punto in cui è più lento di bcrypt. Tuttavia, con l'avanzare della tecnologia GPU, bcrypt rimarrà senza fasi, fino al punto che la tecnologia GPU consente di calcolare bcrypt in modo efficiente. Pertanto, bcrypt è la scelta preferibile ove possibile, non perché SHA non sia sicuro, ma perché SHA è troppo efficiente dal punto di vista computazionale.

Bene, una delle caratteristiche di bcrypt è che è un algoritmo molto lento. Questa lentezza offre una sicurezza aggiuntiva per gli attacchi di forza bruta. Ma per lo stesso motivo, potrebbe non essere la soluzione migliore, ad esempio per i server web molto utilizzati, perché qui una macchina altamente carica dovrà eseguire quei calcoli pesanti su ogni accesso.

Ma finché il tuo sistema può accettarlo, quel tempo aggiuntivo in realtà disturba gli aggressori di forza bruta.