Qual è il motivo specifico per preferire bcrypt o PBKDF2 su SHA256-crypt negli hash delle password?

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

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

Vedi questa risposta per alcune discussioni su bcrypt vs PBKDF2. Sebbene SHA-256-crypt non sia PBKDF2, è abbastanza simile nel suo comportamento delle prestazioni sulla GPU, quindi si applicano le stesse conclusioni.

Il caso per SHA-512 è un po 'meno chiaro perché le GPU esistenti sono molto più adatte all'uso di numeri interi a 32 bit rispetto a 64-bit e SHA-512 utilizza principalmente operazioni a 64-bit. Ci si aspetta comunque che la moderna GPU permetta più hash al secondo della CPU (per un dato budget) con SHA-512-crypt, che punta ancora su bcrypt come 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 round o fattore di lavoro, uno dei due può richiedere più tempo dell'altro, ma vorrei puntare a quello che progettato è lento. (se il carico del server è un problema, il fattore di lavoro è regolabile)

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

Lo SHA multi-round 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 cicli che l'hardware di produzione può completare per millisecondo.

Sebbene entrambi gli algoritmi possano essere implementati in linguaggi di alto o basso livello o in un ibrido; in BCrypt le opzioni disponibili indicano che sei più propenso ad atterrare su un'implementazione efficiente . (ti mette in un campo di gioco più uniforme con l'attaccante)

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

scrypt (con un fattore di lavoro abbastanza buono) ha l'ulteriore vantaggio di avere requisiti RAM / di memoria aggiuntivi (non solo CPU), rendendolo più resistente a GPU di 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 sono praticamente equivalenti a questo riguardo .

Nota: sto osservando questa domanda dopo che è stata apportata questa modifica e prendendo in considerazione:

Note: I specifically mean the multi-round password hashes described by the linked documents and marked with the codes $5$ and $6$ in crypt hashes, not a single round of the plain SHA256 or SHA512 hash functions.

Osservando il lungo algoritmo a 22 passaggi in questo link che hai fornito , preferirei lancia una domanda in giro: perché preferiresti usare questo invece di PBKDF2 con HMAC-SHA2? Perché, almeno come presentato:

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

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

11. For each bit of the binary representation of the length of the
    password string up to and including the highest 1-digit, starting
    from to lowest bit position (numeric value 1):

    a) for a 1-digit add digest B to digest A

    b) for a 0-digit add the password string

    NB: this step differs significantly from the MD5 algorithm.  It
    adds more randomness.

Aggiunge più casualità? Come fa questo? Perché questo passo esiste, SHA-2 non sta aggiungendo casualità sufficiente? Se SHA-2 non è abbastanza casuale, perché usarlo in primo luogo? E questo passo non introduce nell'algoritmo branching dipendente dal segreto , sollevando il domanda di possibili attacchi a tempo contro di essa?

Non sto affatto dicendo che gli algoritmi che colleghi non sono sicuri. È solo 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 simili a quello che avresti se avessi srotolato un'implementazione PBKDF2-HMAC-SHA2, ma con una complessità aggiuntiva il cui scopo non capisco;
• Così almeno come presentato in quei documenti , trovo più difficile acquisire confidenza sul loro design di quanto non faccia per PBKDF2.

EDIT: Dopo aver scritto tutto ciò, sono andato a fare un po 'di ricerche su questo algoritmo per cercare di capirlo meglio. Innanzitutto, dalla "descrizione" e " specifica " collegamenti, apprendiamo che l'algoritmo è stato derivato da un vecchio MD5-based apportando modifiche relativamente minori.

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

MD5 crypt hashes the password and salt in a number of different combinations to slow down the evaluation speed. Some steps in the algorithm make it doubtful that the scheme was designed from a cryptographic point of view—for instance, the binary representation of the password length at some point determines which data is hashed, for every zero bit the first byte of the password and for every set bit the first byte of a previous hash computation.

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

Bene, una delle caratteristiche di bcrypt è che è un algoritmo molto lento. Questa lentezza offre un'ulteriore sicurezza per gli attacchi di forza bruta. Ma per la stessa ragione, potrebbe non essere la soluzione migliore, ad esempio per i server web di grande utilizzo, perché qui una macchina molto carica dovrà fare un calcolo pesante su ogni accesso.

Ma fintanto che il tuo sistema può accettarlo, quel tempo in più disturba gli aggressori di forza bruta.

La stessa famiglia SHA-2 non è necessariamente cattiva. Di progettazione, non ci sono davvero difetti di sicurezza che rendono preferibile 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 quantità decente di memoria da calcolare. Oltre a tutta questa memoria, e in gran parte a causa del bisogno di tanta memoria, scrypt richiede molto tempo computazionale rispetto a SHA. Questa risposta dal sito BitCoin Stack Exchange riassume piuttosto bene i vantaggi dello scrypt: Quali caratteristiche di scrypt () rendono Tenebrix resistente alle GPU? In sostanza, scrypt è progettato per essere lento e ad alto consumo di memoria. Alle GPU non piace. Le GPU in genere non hanno la capacità di memoria per memorizzare tutta la memoria necessaria per il calcolo scrypt senza dover ricorrere ai metodi di blocco dell'esecuzione ( dove la GPU blocca tutti i thread perché può recuperare solo i valori dalla memoria condivisa time ), e quindi le GPU non possono fornire grandi vantaggi alle CPU in termini di tempo di elaborazione. Bcrypt è simile.

Bcrypt è provato e true per l'hashing della password. È in giro da 17 anni e continua a funzionare. Tuttavia, un giorno, la tecnologia GPU avanzerà al punto in cui è in grado di calcolare bcrypt più velocemente e in modo più efficiente di una CPU. La tecnologia è in continua evoluzione e sviluppo, quindi accadrà alla fine. Quando quel giorno arriverà, bcrypt non sarà più una grande scelta per l'hash delle password, e crittografi e esperti di sicurezza dovranno sostituire bcrypt con un algoritmo simile che è più lento e richiede più memoria rispetto al bcrypt esistente. Forse quello sarà scrypt, ma chi dirà. Quindi, perché SHA è disapprovato?

SHA è generalmente scoraggiato non a causa di problemi di sicurezza, ma a causa della velocità e della sua capacità di essere implementato su una GPU. Qualcuno con macchine illimitate / potenza computazionale potrebbe crackare qualsiasi tipo di algoritmo di hash, sia esso SHA, bcrypt o scrypt, ma questo è teorico. In pratica, un utente malintenzionato non avrà un numero illimitato di macchine per provare a far crollare gli hash e, di conseguenza, più è possibile rallentare quell'attaccante, più sarà difficile per loro craccare una password. C'è un limite di budget per tutto e il cracking delle password non fa eccezione. L'utente malintenzionato può crackare solo le password alla velocità consentita dal loro budget. ( La migliore tecnologia che possono acquistare nel loro budget, il costo per eseguire quella tecnologia (ad esempio, i costi elettrici), ecc. ) Naturalmente, potresti implementare più turni di SHA per rallentare gravemente un attaccante , ma perché non usare solo bcrypt a quel punto? Tra l'altro, 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à immutato, fino al punto che la tecnologia GPU consente di calcolare in modo efficiente bcrypt. Pertanto, bcrypt è la scelta preferibile laddove possibile, non perché SHA sia insicuro, ma perché SHA è troppo efficiente dal punto di vista computazionale.