Archiviazione password - Auto crittografia vs Hashing?

Quello che stai facendo qui è in effetti la definizione di una funzione di hash: data una funzione di crittografia Encrypt (K, M) dove K è la chiave e M è il testo in chiaro da cifrare, tu definisci Hash (P) = Encrypt (P, P). Quindi stai inventando una nuova funzione crittografica.

Innanzitutto, per l'hashing della password, non hai bisogno di alcuna vecchia funzione di hash, perché deve essere resistente al tentativo di forza bruta, dove l'utente malintenzionato indovina quale potrebbe essere la password, calcola Hash (indovina) e confronta il risultato con l'hash memorizzato. Qualunque algoritmo di hash tu faccia, devi rinforzarlo per includere il sale (in modo che gli hacker debbano crackare ciascun hash singolarmente anziché chiudere tutti gli account contemporaneamente e far cadere le password più deboli) e rendere la funzione hash lenta (perché fa male l'attaccante, che ha bisogno di fare molte supposizioni sbagliate, più del difensore, che per lo più verificherà i tentativi corretti). Vedi Come fare in modo sicuro le password di hash? per una spiegazione più dettagliata.

Puoi costruire una funzione hash lenta e salata da una normale funzione di hash, con una costruzione come SSH (P, S) = Hash (Hash (... Hash (P + S) ...)) (dove P + S è la concatenazione ). Questo non è necessariamente il modo migliore per farlo - ad esempio, una buona funzione di hashing della password per gli usi tipici dovrebbe richiedere molta memoria, perché i server hanno molta più memoria di hardware specializzato per cracking delle password. Ma è un buon inizio.

Il problema rimane se Hash (P) = Encrypt (P, P) è una buona funzione di hash. Questo non è automatico; fai attenzione che alcune analisi della sicurezza degli algoritmi crittografici si basano sulla chiave e il testo in chiaro è indipendente.

Una delle maggiori difficoltà è che le dimensioni della chiave nella maggior parte degli algoritmi di crittografia sono strongmente limitate, spesso costanti. Ad esempio, l'algoritmo di crittografia standard AES accetta solo tre dimensioni di chiave (8, 12 o 16 byte). Se la password (più sale) è troppo corta, puoi applicarla con un carattere non valido, ma cosa puoi fare se è troppo lungo? Il solito modo di usare una chiave basata su materiale più lungo della dimensione della chiave è ... applicare una funzione di hash (accettando una lunghezza di input arbitraria) al materiale.

Se vuoi ricavare una funzione hash da un algoritmo di crittografia, c'è in realtà un modo più semplice: invece di Hash (P) = Encrypt (P, P), definisci Hash (P) = Encrypt (P, 0), cioè crittografare un blocco di testo in chiaro a zero zeri (o qualche altro blocco di testo in chiaro noto). Questo è ciò che funzione di hashing della password Unix originale ha . Il vantaggio di questo approccio rispetto a Encrypt (P, P) è che è possibile trarre vantaggio dalle analisi esistenti dell'algoritmo: gli algoritmi di crittografia sono progettati per resistere agli attacchi con testo in chiaro. La limitazione con la password e la dimensione del sale rimane.

Le proprietà che le persone cercano quando memorizzano le password è quella di rendere il processo tedioso e lento per cercare di indovinare il testo originale, ma deve essere relativamente veloce quando lo si fa una volta nel software.

Inoltre, non vuoi che due utenti utilizzino la stessa password per generare lo stesso testo cifrato. Per far fronte a questo è necessario un sale in caso di hashing o un IV in caso di auto crittografia.

Come Herr K ha già menzionato, se hai una password devi derivarne una chiave per poter cifrare la password. Quello che usi normalmente è PBKDF2. Fondamentalmente utilizzato anche per l'hashing delle password. Quindi, eseguendo la crittografia automatica, si costruisce fondamentalmente un altro livello su PBKDF2.

Questo aggiunge sicurezza? Non proprio. Ci sono modi migliori, come aumentare il numero di round nella funzione PBKDF2 piuttosto che creare un livello di self encrypting in cima.

Ci sono funzioni migliori che in realtà sono costruite su algoritmi crittografici simmetrici come bcrypt. bcrypt è costruito su Blowfish. Quindi forse dovresti andare con bcrypt visto che è stato controllato nel corso degli anni.

Si noti che il famoso crittografo Tom Leek una volta disse:

Hashing is the proper framework for password storage (where, in fact, the password is not stored, only a password verification token). However, growing home-made hash functions is known to be hard; when cryptographers want to build a hash function, they take a lot of time because they need to be sure that the function is secure, and you cannot know that just by looking at it.

Pensiero molto interessante.

Ma qui abbiamo un problema, gli hash regolari hanno sempre le stesse dimensioni, il tuo hash avrà dimensioni diverse a seconda dell'input.

Quindi può essere considerato meno sicuro di un normale hash.

Definizione della funzione hash:

A hash function is any function that can be used to map digital data of arbitrary size to digital data of fixed size (...)

L'idea di utilizzare la password come chiave in una crittografia è in realtà abbastanza simile a come vengono archiviate le password.

Uno dei primi approcci all'archiviazione delle password era basato sull'utilizzo di DES con la password utilizzata come chiave. Il sale è servito come testo in chiaro e il testo cifrato è servito come valore hash.

Per molti motivi questo approccio è considerato obsoleto e insicuro in questi giorni, ma le parti positive di tale approccio sono presenti nei nuovi hashing delle password.

Problemi con l'approccio basato su DES:

• Solo 12 bit di sale. Non ho idea del motivo, dal momento che non sembra esserci alcuna ragione tecnica per cui non avrebbe potuto utilizzare la dimensione completa del blocco a 64 bit come sale.
• Solo 8 caratteri di password. Il modo in cui DES è strutturato è costituito da 8 parole di 7 bit ciascuna. L'utilizzo di una password da 8 byte come tasto DES sta semplicemente ignorando il bit più significativo di ogni byte. Questo significa 56 bit di chiave, e qualsiasi carattere oltre i primi 8 è stato silenziosamente ignorato.

Se osserviamo come funzionano MD5, SHA1 e SHA2, è abbastanza simile a un codice a blocchi. Ogni blocco di dati da sottoporre a hash viene espanso in modo molto simile a come una chiave di crittografia viene espansa in una pianificazione chiave per un codice a blocchi. Quello che succede allora è il seguente:

Una costante (chiamata IV) viene crittografata con il primo blocco di dati usato come chiave, quindi il testo cifrato e il testo normale vengono sommati. Il risultato dell'aggiunta viene passato al turno successivo. Il prossimo blocco di dati viene quindi utilizzato come chiave per crittografare l'output del passaggio precedente e vengono aggiunti di nuovo testo e testo cifrato. Questo procede fino alla fine dei dati + padding.

In quanto tali, entrambi gli approcci useranno la password come chiave in un codice a blocchi, ma l'input per quel codice a blocchi non è la password.

Tutto sommato non c'è nulla di fondamentalmente rotto nel criptare una password usando se stessa come chiave per ottenere un hash della password. Ma il diavolo è nei dettagli, e fino a quando i dettagli non saranno chiaramente specificati, nessuno può dire se c'è una debolezza in esso. In particolare avere un sale con sufficiente entropia e supportare password di lunghezza arbitraria sono due aspetti importanti che devono essere supportati per avere la possibilità di abbinare la sicurezza dei moderni hash delle password.

Quando si esegue la crittografia, è necessario generare un KEY da una passphrase, che in questo caso sarebbe la propria password. Dovresti eseguire la tua password tramite una funzione di derivazione della chiave come PBKDF2 che si avvicinerebbe effettivamente a un hash.

Quindi fondamentalmente IMHO è interessante ma non credo sia necessario in termini di sicurezza.