Per archiviare in modo sicuro una password, è meglio memorizzarla come hash usando una funzione di hashing progettata per essere lenta come bcrypt . L'obiettivo è quello di superare gli attacchi brute force.
Ci sono dei codici abbastanza lenti da impedire attacchi di forza bruta? Sono particolarmente interessato all'archiviazione delle chiavi private SSH. Un attacco di forza bruta funzionerebbe se la mia passphrase fosse di soli 8 caratteri?
Molti algoritmi di crittografia sono già relativamente lenti e giudicare il successo è anche molto più difficile. Quando si tenta di determinare l'input per un hash, si conosce l'output desiderato. Tuttavia, quando si tenta di crackare la crittografia, in genere non si conosce il testo in chiaro desiderato, anche se lo si fa, il potenziale spazio di input è generalmente molto, molto, molto più grande.
Ogni cifra di una password vale solo circa 7 bit di entropia, anche se scelta idealmente a caso. Anche la parte bassa di una chiave simmetrica standard utilizza generalmente 128 bit di entropia. La velocità dell'hash non sarebbe molto importante se tutti usassero password di 18 caratteri veramente casuali. Inoltre, il testo normale che è necessario raggiungere è generalmente sconosciuto all'attore e gli algoritmi di crittografia in genere operano un po 'più lentamente in quanto devono eseguire operazioni più complicate su un set di dati più lungo.
Quindi, in un certo senso, no, non ci sono algoritmi progettati per essere specificamente lenti come obiettivo di progettazione, ma non hanno bisogno di essere come il livello di sicurezza fornito e la normale velocità dell'algoritmo non bisogno di essere rallentato per essere pratico. Un attacco di forza bruta contro una chiave ben scelta su un algoritmo di crittografia a 128 bit privo di vulnerabilità sistematiche richiederebbe già più tempo di quello che il nostro sole brucerà, per non parlare delle chiavi a 256 bit (che non verrebbero eseguite sull'hardware corrente prima della morte termica) dell'universo). Andare più lentamente semplicemente non è necessario.
Se dovessi utilizzare una funzione di derivazione della chiave per una chiave derivata da password, sarebbe necessario essere lento, ma non vorresti rendere la decrittazione stessa lenta in quanto sarebbe inefficiente.
Come per la memorizzazione della chiave privata SSH, dipenderebbe interamente dall'implementazione della funzione di derivazione della chiave, non dalla velocità dell'algoritmo di crittografia, ma suggerirei probabilmente almeno 10 caratteri se si desidera che resista strongmente alla forzatura bruta anche per una derivazione della chiave ragionevolmente lenta (non sono sicuro di cosa stia utilizzando la chiave SSH, e può variare a seconda del client.)
Per la maggior parte, no. I cifrari sono progettati per essere il più rapidi possibile fornendo al contempo un buon livello di sicurezza in modo da poter crittografare i dati in modo rapido e semplice. Tuttavia, questa proprietà li rende dannosi per la crittografia della password, quindi perché hai cose come bcrypt che li rallentano iterando l'algoritmo sulla password un gran numero di volte.
Ora, c'è stata un'eccezione che ho riscontrato circa un decennio fa che il design era lento. L'autore l'ha progettato in questo modo perché non credeva che gli algoritmi veloci fossero sicuri. Anche se è stato generalmente considerato poco pratico dal momento che richiederebbe molto tempo per crittografare i dati significativi e il design ha impedito che venisse utilizzato in un ambiente di streaming, potrebbe benissimo essere una buona base per un algoritmo di hashing della password unidirezionale presumendo che il progetto sia crittograficamente sicuro.
Rendere un codice lento non è un obiettivo di progettazione saggio. Spiegherò perché dopo, ma prima: Bcrypt. Lo scopo di Bcrypt è di estendere un input di bassa entropia a un output più lungo di una funzione a senso unico. Bcrypt è progettato con le password in mente. Le password in genere hanno una bassa entropia (< 2 30 ), ma se non lo facessero, Bcrypt potrebbe essere sostituito con una normale funzione di hash crittografica. Una ragione per cui non è necessario rallentare i cipher è perché è facile generare chiavi ad alta entropia. Non è fattibile cifrare forti cifrari con chiavi grandi.
Consente di confrontare AES-128 con il codice ipotetico BFT-256. (Chiamato come HAL / IBM.) BFT è un milione di volte più veloce di AES-128. Sarebbe più semplice forzare la chiave assumendo che AES-128 offra 128 bit di sicurezza e BFT-256 offra 256 bit di sicurezza? No perché il cifrario con una chiave più grande richiede la forza bruta 2 128 volte tante chiavi anche se ciascuna crittografia può essere eseguita 2 20 volte più veloce. 2 256-20 > 2 128 .
Infine, se qualcuno volesse veramente rallentare una cifra qui ci sono alcuni esempi di cosa potrebbero fare. Potrebbero aumentare il numero di round in un codice a blocchi. Tuttavia, ciò aumenta la quantità di tempo che la crittografia impiega in modo lineare per le persone con o senza la chiave. L'espansione dello spazio chiave aumenta la quantità di tempo impiegato per forzare una chiave in modo esponenziale, facendo poca differenza sul tempo di crittografia in base all'algoritmo. In secondo luogo, si potrebbe usare una chiave segreta e un contatore per costruire un codice lento da Bcrypt nello stesso modo in cui lo si può fare con SHA e altre funzioni di hash. Tuttavia, si spera che entrambe queste soluzioni sembrino sciocche ora.
Inoltre, non c'è nemmeno abbastanza energia per incrementare un contatore 2 256 volte anche se tutta l'energia prodotto da una supernova potrebbe essere catturato e i codici impiegano ancora più energia e più tempo di un'operazione di incremento.
Alcune funzioni di hashing (presumibilmente intendevi hash, non cifrario, dato che stai parlando di hashing delle password) sono più lente di altre. Ad esempio, l'implementazione CubeHash originale di Bernstein è relativamente lenta e DJB ha pubblicizzato le sue scarse prestazioni come punto vendita. Nessuno lo ha davvero comprato, però.
Un grande sforzo industriale deve essere dedicato al perfezionamento e alla messa in sicurezza di una singola funzione crittografica, quindi la funzione deve funzionare bene su tutta la linea. Inoltre, oltre alle password di hashing, le funzioni di hash vengono utilizzate anche per la verifica dei file e la firma dei messaggi al volo.
Una funzione hash a funzionamento lento è invalicabile in casi che richiedono alte prestazioni, ma un hash di operazione rapida può essere rallentato semplicemente eseguendolo iterativamente, come accade in PBKDF2 e algoritmi simili di rafforzamento hash. Con questo in mente, un hash veloce è universalmente più utile e quindi è più probabile che sia ben controllato e ampiamente distribuito.
Leggi altre domande sui tag encryption ssh key-management