Puoi alimentare vecchi hash non salati a una funzione PBKDF salata per aumentare la sicurezza?

Question

Puoi alimentare vecchi hash non salati a una funzione PBKDF salata per aumentare la sicurezza?

#1 da (2 voti)
#2 da (1 voti)

5

Supponiamo che BigBusiness ™ Inc. Ltd. abbia creato un servizio Web nel 1995, memorizzando le proprie password utente utilizzando una tecnologia all'avanguardia: hash md5 non salati. Ora capiscono che questa è stata probabilmente una cattiva idea e vogliono aumentare la sicurezza dei propri utenti in caso di violazione senza forzare una reimpostazione della password su tutti. Quindi decidono di memorizzare PBKDF2(old_hash, individual_salt) invece.

Questa è una buona strategia o ha degli svantaggi?

passwords hash salt

posta Fritz 23.09.2016 - 18:23

fonte

2 risposte

Leggi altre domande sui tag passwords hash salt

ProtonMail: Non sarebbe meglio se ogni utente avesse la propria chiave privata? Il montaggio di una partizione LUKS lo autentica?

score 2 · Answer 1

Bene, suggerirei BCrypt su PBKDF2.

Detto questo, la soluzione dovrebbe essere duplice.

Per proteggere immediatamente il sistema, sì la soluzione è buona. Considera MD5 come password di input, e disponi di sale per utente come suggerisci.
Suggerirei di migrare MD5 fuori dall'immagine. (a meno che non si tratti di un'applicazione strettamente legacy)

La prossima volta che l'utente effettua l'accesso, la tua applicazione avrà accesso alla password unshed e avrà la possibilità di aggiornare l'hash con una che salta il passo MD5. Dovrai avere un indicatore sull'account se questo è stato completato.

Vorrei anche raccomandare Pepper in sospeso alla password di input (o MD5) come ulteriore precauzione di sicurezza.

BCrypt ha una lunghezza massima per le password, quindi è meglio inserire prima la password di input combinata con Pepper in un hash SHA-256. Non sono sicuro che PBKDF2 abbia questo limite. Alla fine potresti un giorno utilizzare un hash ancora più recente che non ha nemmeno questo limite.

Sapete, in realtà, la migrazione da MD5 non è probabilmente necessaria, ma sbarazzarsi di MD5 sarebbe la soluzione ideale per la migliore resistenza alle collisioni e sembra solo un design più pulito.

score 1 · Answer 2

Come dice George, questo sistema va bene per ora (supponendo che tu usi buoni sali e un buon numero di iterazioni per PBKDF2). Tuttavia, è necessario aggiungere flessibilità al sistema per tenere conto degli aggiornamenti futuri dell'algoritmo di verifica della password. Sebbene il tuo schema attuale abbia il vantaggio di poter aggiornare la sicurezza del verificatore di password senza la password effettiva, è comunque consigliabile avere un valore che ti permetta di vedere quale sia l'algoritmo per un determinato verificatore.

Potresti aver bisogno di questo:

Se esegui un aggiornamento del verificatore che non può essere fatto basandosi solo sul vecchio verificatore, non sarai in grado di elaborare ogni password finché l'utente non effettua l'accesso, quindi avrai alcuni verificatori di password che utilizzano il nuovo algoritmo e alcuni ne usano uno più vecchio.
Se è necessario ripristinare da un backup, è opportuno che il codice di autenticazione sia in grado di riconoscere e supportare i verificatori legacy. Ti evita di dover garantire che tu stia utilizzando la versione corretta della tua base di codici con cui abbinare quando è stato eseguito il backup del DB di autenticazione.