Utilizzare BCRYPT per l'hashing della password sul lato client

È proprio il contrario, BCrypt non cripta la password con una chiave segreta, piuttosto usa la password come chiave per crittografare un testo conosciuto. Nel setup in cui viene generata la chiave, utilizza sia salt che la password (variabile EksBlowfishSetup.key ), per generare una chiave (variabile bcrypt.state ) utilizzata per la crittografia.

bcrypt(cost, salt, input)
    state \gets EksBlowfishSetup(cost, salt, input)
    ctext \gets "OrpheanBeholderScryDoubt" //three 64-bit blocks
    repeat (64)
        ctext \gets EncryptECB(state, ctext) //encrypt using standard Blowfish in ECB mode
    return Concatenate(cost, salt, ctext)

EksBlowfishSetup(cost, salt, key)
    state \gets InitState()
    state \gets ExpandKey(state, salt, key)
    repeat (2cost)
        state \gets ExpandKey(state, 0, key)
        state \gets ExpandKey(state, 0, salt)
    return state

BCrypt può essere visto come crittografato con il lancio della chiave.

Bcrypt non è reversibile. Puoi usarlo sia lato client che lato server.

La chiave non è statica, ma dipende dalla password, generata dalla chiamata di funzione EksBlowfishSetup(cost, salt, input) . Il testo in chiaro è conosciuto e pubblico, il suo "OrpheanBeholderScryDoubt" . Se si desidera recuperare la chiave, è necessario montare un attacco noto-testo in chiaro su blowfish 64 volte , che è molto difficile, e quindi avresti solo la chiave e non la password.

Wikipedia fornisce una panoramica pseudocodice dell'algoritmo bcrypt :

 bcrypt(cost, salt, input)
     state ← EksBlowfishSetup(cost, salt, input)
     ctext ← "OrpheanBeholderScryDoubt" //three 64-bit blocks
     repeat (64)
         ctext ← EncryptECB(state, ctext) //encrypt using standard Blowfish in ECB mode
     return Concatenate(cost, salt, ctext)

Modificato per aggiungere: si scopre che quello che ho scritto è corretto, ma non è una risposta alla domanda che è stata posta. Mi scuso.

Qualunque cosa tu invii dal client al server è la password, sia che sia stata sottoposta a hash, a fette oa cubetti. Un hash della password sul client non è più sicuro della stessa stringa, senza alterazione. Se viene intercettato, può essere utilizzato per un attacco di replay in entrambi i casi.

L'importante è assicurarsi che la password sia trasmessa crittografata , ad es. con SSL / TLS.

Dai un'occhiata a questo per una spiegazione più completa: link

Non è chiaro quale lingua stai usando, ma nel PHP più recente rendono tutto più semplice avendo a disposizione una funzione di hash incorporata che può tenere conto della crittografia più recente e migliore. C'è una funzione di verifica per testare l'hash. C'è anche una funzione rehash che può tenere conto delle modifiche future, in modo tale che i vecchi hash possano essere aggiornati e comunque verificati. Data la corretta implementazione, questo dovrebbe occuparsi della maggior parte dei problemi che potresti incontrare. Tuttavia, come sottolinea Jeff-Inventor ChromeOS, la maggior parte degli usi di un hash non richiede molto più di un semplice algoritmo. Dipende dai tuoi bisogni e quanto sei disposto a sacrificare la sicurezza sul tempo di elaborazione / potenza.

È prassi comune utilizzare qualsiasi algoritmo di hash, come SHA-2 sul client. Per una sicurezza leggermente maggiore, è possibile utilizzare un hash lento come PBKDF2, bcrypt o scrypt. Un hash lento è un hash progettato per richiedere una grande quantità di potenza di calcolo, rendendo gli attacchi di forza bruta con elenchi di password comuni più diffusi.

Il vero vantaggio in termini di sicurezza degli hash lenti non è tuttavia grande, perché gli utenti selezionano le password da un elenco piuttosto piccolo di password comuni. Nella mia analisi, circa un milione di password (20 bit) recuperano il 50% degli account ( link ). Solo poche migliaia di password recuperano una parte significativa dei conti (6,1%).

È impossibile eliminare una quantità così piccola di entropia quanto basta per diventare un ostacolo significativo per un utente malintenzionato.