Esiste uno standard per l'utilizzo di PBKDF2 come hash della password?

Question

Unisciti a me nella lotta contro gli hash delle password deboli.

Un hash della password PBKDF2 deve contenere il salt, il numero di iterazioni e l'hash stesso, quindi è possibile verificarlo in seguito. Esiste un formato standard, come {SSHA} di RFC2307, per gli hash delle password PBKDF2? BCRYPT è ottimo ma PBKDF2 è più facile da implementare.

Apparentemente, non ci sono specifiche. Quindi ecco le mie specifiche.

>>> from base64 import urlsafe_b64encode 
>>> password = u"hashy the \N{SNOWMAN}" 
>>> salt = urlsafe_b64decode('s8MHhEQ78sM=') 
>>> encoded = pbkdf2_hash(password, salt=salt) 
>>> encoded 
'{PBKDF2}1000$s8MHhEQ78sM=$hcKhCiW13OVhmLrbagdY-RwJvkA=' 

Aggiornamento: http://www.dlitz.net/software/python-pbkdf2/ definisce una sostituzione crypt(). Ho aggiornato la mia piccola speculazione in modo che corrisponda alla sua, eccetto che inizia con $p5k2$ anziché {PBKDF2}. (Ho bisogno di migrare da altri SCHEMES in stile LDAP).

Questo è {PBKDF2}, il numero di iterazioni in esadecimale minuscolo, $, il sale urlsafe_base64 codificato, $, e l'uscita urlsafe_base64 PBKDF2 codificato. Il sale dovrebbe essere a 64 bit, il numero di iterazioni dovrebbe essere almeno 1000 e il PBKDF2 con l'output HMAC-SHA1 può essere di qualsiasi lunghezza. Nella mia implementazione sono sempre 20 byte (la lunghezza di un hash SHA-1) per impostazione predefinita.

La password deve essere codificata in utf-8 prima di essere inviata tramite PBKDF2. Nessuna parola su se dovrebbe essere normalizzato in NFC di Unicode.

Questo schema dovrebbe essere dell'ordine di iterations volte più costoso per la forza bruta di {SSHA}.

Answer 1

Esiste una specifica per i parametri (salt and iterations) di PBKDF2, ma non include l'hash. Questo è incluso in PKCS #5 version 2.0 (vedi Appendice A.2). Alcune piattaforme hanno il supporto integrato per codificare e decodificare questa struttura ASN.1.

Poiché PBKDF2 è in realtà una funzione di derivazione chiave, non ha senso che specifichi un modo per raggruppare l'hash (che in realtà è una chiave derivata) insieme ai parametri di derivazione — in uso normale, la chiave deve rimanere segreta e non viene mai memorizzata.

Ma per l'utilizzo come hash della password unidirezionale, l'hash può essere memorizzato in un record con i parametri, ma nel proprio campo.

Answer 2

Mi unirò a voi nella lotta contro gli hash deboli.

OWASP dispone di una scheda di memorizzazione password (https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet) con alcune indicazioni; raccomandano 64.000 iterazioni PBKDF2 al minimo a partire dal 2012, raddoppiando ogni due anni (ovvero 90.510 nel 2012).

Si noti che la memorizzazione di un sale per userid a lungo termine crittograficamente casuale è sempre di base.

Si noti che avere un numero di iterazioni ampiamente variabile per utente e memorizzare il numero di iterazioni insieme al sale aggiungerà un po 'di complessità al software di cracking e potrebbe aiutare a impedire determinate ottimizzazioni. Ad esempio, "bob" viene crittografato con iterazioni 135817, mentre "alice" usa 95.121 iterazioni, ovvero un minimo di (90510 + RAND (90510)) per il 2013.

Nota anche che tutto ciò è inutile se gli utenti sono autorizzati a scegliere password deboli come "password", "Password1!"," P @ $$ w0rd "e" P @ $$ w0rd123 ", tutti elementi che verranno trovati dal dizionario basato su regole molto rapidamente (quest'ultima è semplicemente" password "con le seguenti regole: prima lettera maiuscola, 1337-speak, aggiungi un numero di tre cifre alla fine) Prendi un elenco di dizionari di base (phpbb, per una buona e piccola lista di parole d'inizio) e applica regole come questa, e creerai molte password in cui le persone provano trucchi "intelligenti"

Pertanto, quando si controllano le nuove password, non applicare solo "Tutte e quattro le cifre in alto, in basso, numero, cifre, almeno 11 caratteri", poiché "P @ $$ w0rd123" è conforme a questa regola apparentemente molto dura, invece, usa quella lista di base del dizionario per vedere se le regole di base lo infrangono (è molto più semplice che provare effettivamente una crepa - puoi minuscole la tua lista e la loro parola, e poi scrivi semplicemente il codice come " se gli ultimi 4 caratteri sono un anno comune, chec k tutti tranne gli ultimi quattro caratteri rispetto alla lista di parole ", e" se gli ultimi 3 caratteri sono cifre, controllare tutti gli ultimi 3 caratteri contro la lista di parole "e" controllare tutti gli ultimi due caratteri contro la lista di parole "e" De- 1337 la password - gira @ in a, 3 in e, e così via, quindi verificala contro il vocabolario e prova anche quelle altre regole. "

Per quanto riguarda le passphrase, in generale è una grande idea , in particolare se alcuni altri personaggi sono aggiunti al centro delle parole, ma se e solo se sono abbastanza lunghi, dal momento che stai rinunciando a molte combinazioni possibili.

Si noti che le macchine moderne con GPU sono fino a decine di miliardi di iterazioni hash (MD5, SHA1, SHA-256, SHA-512, ecc.) Al secondo, anche nel 2012. Per quanto riguarda la combinazione di parole "corretta "password di tipo batteria a ferro di cavallo", questa è nella migliore delle ipotesi una password molto modesta. Sono solo 4 parole in lettere minuscole in inglese di lunghezza pari o inferiore a 7 con spazi. Quindi, se andiamo a cercare le password in stile XKCD con una stima di 18 miliardi, un secondo piccolo dizionario inglese americano ha: 6k parole di lunghezza 5 o meno 21k parole di lunghezza 7 o meno 36k parole di lunghezza 9 o meno 46k parole di lunghezza 11 o meno 49k parole di lunghezza 13 o meno

Con uno stile passphrase XKCD, e senza preoccuparsi di filtrare le parole per popolarità ("corretta" contro "la sedia di" contro "dumpier" contro "emorragie") abbiamo 21k^4, che è solo circa 2E17 possibilità. Con l'impostazione da 18 miliardi/sec (una singola macchina con 8 GPU se ci troviamo di fronte a una singola iterazione SHA1), sono circa 4 mesi per cercare esaurientemente lo spazio delle chiavi. Se avessimo dieci configurazioni di questo tipo, sono circa due settimane. Se escludiamo parole improbabili come "Dumpier", è molto più veloce per un primo passaggio veloce.

Ora, se ottieni parole da una "enorme" linux listlist inglese americana, come "Balsamina" o "Calvinistically" (entrambe scelte usando la funzione "vai a riga", allora avremmo 30k parole lunghezza 5 o meno 115k parole di lunghezza 7 o meno 231k parole di lunghezza 9 o meno 317k parole di lunghezza 11 o meno 362k parole di lunghezza 13 o meno

Anche con il limite massimo di 7 lunghezze, con questo enorme dizionario come una base e parole scelte a caso, abbiamo 115k^4 ~ = 1.8E20 possibilità, o circa 12 anni se l'impostazione è mantenuta aggiornata (raddoppio di potenza ogni 18 mesi) .Questo è estremamente simile a un 13 carattere, minuscolo + password solo numero. "300 anni" è ciò che la maggior parte delle stime ti dirà, ma non tengono conto della Legge di Moore.