Incremento del fattore di lavoro delle funzioni di hash nel tempo

8

Per molto tempo le funzioni hash hanno richiesto un fattore di lavoro per mantenere l'operazione "lenta" quanto basta per proteggere le singole password in caso di perdita di un database. Bcrypt e PBKDF2 sono esempi notevoli.

Sono anche a conoscenza del fatto che "Non rotolare le tue" quando si tratta di sicurezza, ma è facile immaginare una situazione che nel tempo il fattore di lavoro del tuo schema di hashing delle password diventa troppo veloce a causa dell'aumento dell'hardware. Si potrebbe anche immaginare una situazione in cui i proprietari del database aggiornano il proprio hardware e quindi un fattore di lavoro più elevato è adatto rispetto a quello che veniva utilizzato prima dell'aggiornamento dell'hardware per garantire una maggiore sicurezza per password.

Il problema si presenta con la necessità di "re-hash" una password, perché non si desidera archiviare un testo in chiaro o addirittura una password crittografata in un database, in modo che il sistema non abbia modo di accedere nuovamente alla password affinché il cambio di bozze cambi il fattore lavoro. Per risolvere questo problema, è sufficiente eseguire questa operazione di reinghing quando un utente esegue l'accesso. Ogni volta che l'utente accede alla password in chiaro è già disponibile per il sistema, in una verifica hash riuscita della password il sistema può controllare il precedente fattore di lavoro associato l'hash della password (facile da fare in bcrypt) e se è inferiore al fattore di lavoro standard selezionato dagli operatori di sistema, la password in chiaro viene rehashed e archiviata con il nuovo fattore di lavoro e il nuovo salt. Le sessioni non devono essere reimpostate poiché viene utilizzata la stessa password di prima, solo un fattore di lavoro e sale diversi.

Oltre alla password in chiaro in memoria per un tempo leggermente più lungo durante la verifica della password e un tempo maggiore nella verifica della password ogni volta che viene emesso un aumento del fattore di lavoro, non riesco a trovare alcun errore di questo modello. Ci sono dei difetti di sicurezza che mi sono persi?

    
posta Seth M. Larson 07.04.2016 - 16:03
fonte

2 risposte

4

Sembra che tu l'abbia riassunto piuttosto bene.

L'unico inconveniente che posso pensare sono gli utenti inattivi nel tuo sistema - continueranno ad avere un precedente fattore di lavoro perché potrebbero non accedere mai più, o potrebbero non avere la possibilità di accedere prima della prossima violazione, ovvero il loro archivio la password è più vulnerabile agli attacchi. Poiché il fattore di lavoro è visibile all'interno dei dati memorizzati, l'utente malintenzionato potrebbe sapere quali utilizzano la vecchia impostazione (sebbene non conoscano l'entropia relativa all'interno di ciascuna password).

Per evitare ciò, è possibile disabilitare regolarmente l'account per il quale non è stato effettuato il login per circa 6 mesi, cancellando la password allo stesso tempo. Se devono effettuare il login in un momento futuro, possono semplicemente passare attraverso la funzionalità della password dimenticata per abilitare una nuova password da impostare e memorizzare con il nuovo fattore di lavoro.

    
risposta data 07.04.2016 - 16:41
fonte
3

Un punto chiave è che hai gli hash delle password nel tuo database in modo da non dover re-hash la password. Diciamo che li hai cancellati (correttamente, con sale ect.) N volte. Per raddoppiare il tuo fattore di lavoro puoi ripetere l'hash N più volte nel database. E poi applicare questo stesso rehash ai login in futuro. Vedi link e È possibile aumentare il costo di BCrypt o PBKDF2 quando è già calcolato e senza la password originale? per ulteriori dettagli.

    
risposta data 07.04.2016 - 16:50
fonte

Leggi altre domande sui tag