L'hashing delle password "busy-work" deve essere crittograficamente sicuro

7

Tutti i moderni schemi di hashing delle password sono deliberatamente progettati per includere una quantità enorme di "lavoro occupato", per limitare la velocità con cui un utente malintenzionato sarebbe in grado di eseguire tentativi di hashing della password. Inoltre, un obiettivo nei nuovi schemi è quello di ridurre la quantità con cui l'hardware per scopi speciali può essere reso più efficiente rispetto all'hardware di costo simile. Se una "unità di lavoro" in ciascuno dei diversi algoritmi è definita come la quantità di lavoro che potrebbe essere eseguita al secondo per dollaro di hardware che è stato ottimizzato per tale attività, l'obiettivo è di massimizzare il numero di unità di lavoro che possono essere fatte in un periodo di tempo accettabile utilizzando l'hardware di produzione. Poiché le macchine commodity si differenziano per l'efficienza con cui possono eseguire varie operazioni, tuttavia, ciò suggerirebbe che algoritmi diversi sarebbero ottimali su diverse macchine di produzione. Ad esempio, sebbene sia preferibile che gli algoritmi siano GPU-ostili se le macchine di produzione non dispongono di GPU, su piattaforme di produzione che possono utilizzare una GPU sarebbe meglio disporre di un algoritmo occupato per la GPU.

Dato l'algoritmo di hashing della password:

hash = secureHash(password, salt)
Using one or more forms of busywork:
  busyResult = busyWork(hash, params)
  hash = secureHash(hash, busyResult, extraSalt)

Se si presume che secureHash abbia tutte le proprietà necessarie per un hash sicuro, la sicurezza complessiva dipenderebbe da eventuali proprietà crittografiche delle funzioni busyWork utilizzate oltre al fatto che i loro output non sono calcolabili senza eseguire una certa quantità di lavoro? In caso contrario, sarebbe ragionevole favorire diversi tipi di lavoro occupato su diversi ambienti di produzione, se:

  1. Ogni record di password includeva un elenco delle forme di occupato che erano state utilizzate per crearlo, insieme ai parametri appropriati.

  2. Ogni ambiente di produzione sarebbe in grado di eseguire tutte le forme di lavoro occupato, anche se non in modo efficiente in modo efficiente.

  3. In caso di modifiche dell'hardware che richiederebbero l'utilizzo dell'algoritmo della password corrente più a lungo dell'ideale, l'hash della password memorizzata dell'utente potrebbe essere aggiornato in modo trasparente per utilizzare il nuovo algoritmo al successivo accesso dell'utente (l'utente non deve saperlo ciò avveniva).

Cercare di progettare un algoritmo di hash sicuro per ogni diverso sistema di sistema che è stato ottimizzato attorno alle precise abilità di quel sistema sarebbe difficile. Se, tuttavia, il requisito fosse più debole, era solo necessario dimostrare che l'algoritmo busywork era vicino al mezzo più veloce per produrre un determinato output su un determinato sistema e che ogni diverso valore hash inserito nell'algoritmo avrebbe probabilmente produrre output diversi (non è difficile da fare se l'output potrebbe essere molto più grande dell'input), sembrerebbe che produrre algoritmi ottimizzati per piattaforme diverse sarebbe molto più semplice.

Domanda principale: Se la funzione secureHash è buona, e il tempo richiesto per almeno alcune delle funzioni di occupato-lavoro non può essere ridotto efficacemente, ci sarebbe un modo in cui un una scarsa funzione di occupato-lavoro potrebbe compromettere la sicurezza, oltre a prendere tempo lontano dalle migliori funzioni di lavoro occupato?

    
posta supercat 28.09.2014 - 21:17
fonte

2 risposte

2

Does password-hashing “busy-work” need to be cryptographically secure

Sì. Ne hai bisogno per usare un algoritmo standard per assicurarti che non ci siano scorciatoie disponibili per il "lavoro occupato". Dai un'occhiata alla risposta di Thomas Pornin .

Inserting the salt (yes, it must be talked about), and iterating the function at the same time, is a bit more tricky than what it usually appears. In particular, a hash function such as SHA-256 is not exactly a "random-oracle-like" function; it exhibits some internal structure. Any homemade construct could hit one of those fine details from which deadly weaknesses may emerge.

Making sure that you did it right is difficult, just like building any cryptographic algorithm. That's where bcrypt is better than any homemade construct: bcrypt has been published and in use and presumably inspected for flaws by many people over quite some time. This is basically the only hard measure of security that you can get in cryptography. The generic advice of "do not define your own algorithms" applies here too.

Nella tua affermazione:

If the secureHash function is good, and the time required for at least some of the busy-work functions cannot be effectively reduced, would there be any way in which a poor busy-work function could compromise security, other than by taking time away from the better busy-work functions?

Prendendo tempo è buono, anche se se esistono scorciatoie il tempo speso sarebbe meglio spendere per un metodo "provato e testato" di iterare l'algoritmo di hashing. Se il metodo collaudato aggiungerà effettivamente 10 bit di entropia con 1024 iterazioni, non si vuole che la funzione "scarso lavoro occupato" sia in grado di essere scorciatoia, quindi non viene aggiunta alcuna entropia equivalente aggiuntiva. Questo aggiunge tempo per il tuo sistema, ma nessuno per un utente malintenzionato. Una buona funzione di hash iterata dovrebbe aggiungere più tempo per l'attacker in quanto necessiterà di ulteriori ipotesi rispetto a quelle di un utente valido.

Mi rendo conto che la tua domanda è sulla falsariga di "supponiamo che l'hacker abbia il modo più veloce di produrre un hash", tuttavia sul mio hardware di produzione voglio "il metodo più veloce per creare un hash sicuro" da utilizzare per ogni piattaforma . In questo caso potresti avere diversi algoritmi per macchine diverse, ma dovresti usare quelli standard (bcrypt, scrypt, PBKDF2) e sarai in balia del più debole se un hacker ha ottenuto il tuo database delle password.

Nel tuo commento a una risposta precedente:

In most crypto functions, the assumption is that the attacker won't have the parameters necessary to use the crypto function in the forward direction and will thus have to reverse it and the goal is to maximize the difference in speed between the reverse and forward directions. Adding insecure stuff will slow down the forward direction, but probably won't affect the reverse direction as much.

Una funzione di hash crittografica dovrebbe essere praticamente impossibile da invertire. Un utente malintenzionato quando tenta di craccare un hash eseguirà infatti le sue ipotesi usando lo stesso algoritmo che hai usato, quindi andrà nella "direzione avanti" per vedere se ha una corrispondenza. Non dovresti dare per scontato che il tuo "busy-work" o l'algoritmo di hashing siano segreti - supponi che l'unico segreto che l'hacker non sa sia la password. L'unica volta in cui le cose si trovano in una "direzione inversa" è quando hanno un arcobaleno pre-calcolato o una tabella hash: se hai un sale abbastanza strong, questo fermerà questo vettore di attacco.

Quindi sembra che ci sia un difetto nel tuo obiettivo di rendere una funzione di hash rapida da eseguire e difficile da invertire. Dovrebbe essere lento da eseguire e impossibile da invertire. L'unico "inversione" che dovresti tentare di contrastare è quello dei tentativi ripetuti facendo in modo che l'attaccante faccia più lavoro per ipotesi.

    
risposta data 17.01.2015 - 19:17
fonte
1

È in gran parte una questione di semantica ... Crypto vuole assicurarsi che il tempo necessario per romperlo (indovinando qualche valore) sia il più ampio possibile. "Prendendo tempo" significa che l'attaccante può violare la sicurezza più rapidamente. - Cioè, tutto il criptato in uso può essere "spezzato" dato il tempo infinito (es .: "semplicemente" indovina una chiave privata).

Se il tuo "povero lavoro occupato" è semplicemente "aggiungi 10 al numero X un miliardo di volte", l'attaccante lo ridurrà a "aggiungere 10 miliardi a X", rimuovendo ogni utilità.

    
risposta data 01.12.2014 - 16:11
fonte

Leggi altre domande sui tag