Nesting bcrypt + PHPass per migliorare la sicurezza dell'archiviazione delle password nei software legacy?

L'involucro unico di PHPass in bcrypt dovrebbe in effetti fornire una significativa resistenza alla bruteforce offline. Come ho commentato sopra, usando i fattori di lavoro predefiniti, hashcat può crackare PHPass fallback md5crypt-style PHPass circa 500 volte più velocemente di bcrypt.

Riutilizzare il sale PHPass interno per l'uso con il bcrypt esterno sembra ragionevole. (Sicuramente sembra migliore di un sale statico!) I tuoi vecchi pacchetti bcrypt non saranno abbastanza casuali - ma solo non casuali relativi all'hash di PHPass interno che non è ancora noto al attaccante .

Poiché ogni bcrypt e PHPass sono ancora salati casualmente rispetto a tutti gli altri hash del loro tipo, la distribuzione di sali fornisce ancora un'ampia resistenza alla forza bruta che i sali dovrebbero avere.

Non riesco a pensare a un modo in cui conoscere il PHPass in anticipo potrebbe fornire ulteriori vantaggi all'attaccante. E anche se fornisce un vantaggio lieve , sarà quasi certamente superato dal costo più elevato di cracking bcrypt.

Inizialmente intendevo chiudere questo come duplicato di " perché-is-hashing-a-password-con-multiple-hash-funzioni-inutili " tuttavia si ha un caso leggermente più complesso in quanto si dispone già di un database di password con hash.

Se ritieni che il tuo meccanismo di hashing esistente sia insufficiente rispetto a quello necessario per eseguire la migrazione a una soluzione migliore. Ciò significa che è necessario essere in grado di discriminare tra la vecchia e la nuova rappresentazione, eseguire i meccanismi di verifica in parallelo e convertire il testo chiaro dalla vecchia rappresentazione al nuovo. E l'unica volta che ottieni il testo chiaro è quando qualcuno accede.

Sebbene PHPPass sia piuttosto lungo nel dente, usa blowfish (e bcrypt è basato su blowfish). Quindi forse non stai migliorando la sicurezza quanto pensi.

Direi che se ti allontani da phpass vorrai rimuoverlo il più possibile dalla tua base di codice. Potrei suggerire di sostituire prima tutti i phpass con la versione briptata di essi, quindi sostituire l'hash phpass con l'hash bcrypt la prossima volta che un utente effettua l'accesso. Per supportare gli utenti che accedono per la prima volta dallo switch, dovresti anche controllare se il phpass corrisponde.

Quindi qualcosa come la seguente. Ovviamente sto usando pseudo codice in quanto la funzione non è chiamata "bcrypt".

if bcrypt(phpass($supplied_password)) == $storred_password;
    $storred_password = bcrypt($supplied_password);
    login();
if bcrypt($supplied_password) == $storred_password;
    login();

In questo scenario, stai lentamente migrando allo schema della nuova password, ma quello vecchio è ancora supportato.

Se esiste una vulnerabilità in phpass come una perdita di memoria o qualcosa di pazzesco, non lo si utilizza affatto nella maggior parte delle password in quanto gli utenti accedono.

Quello che stai facendo è essenzialmente una espansione chiave . Ma phpPass lo fa già (come bcrypt ), quindi quello che stai facendo realmente da un punto di vista della sicurezza sta aumentando (leggermente) la sicurezza aggiungendo un round in più, niente di più.

Potrebbero esserci alcune vulnerabilità di implementazione in phpPass che potrebbero portare alla divulgazione delle chiavi (ad esempio non disinfettando i buffer di memoria), ma le possibilità di sfruttamento sembrano ridotte.

Tutto sommato, direi che non diminuisci la sicurezza, anche se probabilmente non aumenti significativamente.

Anche così, potrebbe essere utile seguire un metodo di migrazione del database. Ad esempio aggiungendo un campo alla tabella utente per contenere un hash di bcrypt puro (o NULL). Se è NULL, viene utilizzato l'algoritmo phpPass e, se la password viene convalidata, viene generato il campo bcrypt. Puoi monitorare la percentuale di campi hash pieni di bcrypt per vedere come procede la migrazione. E puoi azzerare l'hash phpPass di alcuni utenti migrati al test per verificare che tutto funzioni quando si è in bcrypt da solo (se il sistema è progettato in modo pulito questo è superfluo, ma è comunque bello poter mostrare uno scenario Happy Day al CEO: una tabella con coperture del codice non la riduce tanto.