Questo dovrebbe andare bene.
Ho intenzione di dividere la domanda in due parti:
1. Come funziona bcrypt in termini di utilizzo di sale e amp; archiviazione?
I sali vengono utilizzati per una serie di motivi, principalmente per prevenire attacchi da tavolo arcobaleno e creare hash unici per password non univoche.
Le tabelle arcobaleno sono enormi dizionari di hash e il loro testo in chiaro. L'idea è di cercare l'hash e trovare il testo in chiaro associato. Per rendere questo difficile, ogni password viene salata con un valore univoco, assicurando che ogni password deve essere crackata separatamente.
Se due utenti hanno la stessa password, senza sale, gli hash saranno gli stessi. Questo ci apre agli attacchi casuali. Se due utenti hanno la stessa password, ma diversi sali, gli hash saranno diversi.
Il problema dei sali è che puoi memorizzarli in testo semplice , perché non è necessario che siano più segreto dei tuoi forti hash delle password. In quanto tale, bcrypt salva semplicemente il sale in testo semplice all'interno dell'hash:
$2a$05$TwentyTwoCharsForASalt$e2uDLvp1Ii2e./U9C8sBjqp8I90dH6hi
Questo è diviso nei seguenti token:
- Il prefisso
2a per identificare l'hash come una cripta blowfish (cioè bcrypt)
- Un fattore di lavoro a due cifre (in genere limitato da 04 a 31)
- Un valore salato di 22 caratteri, dai valori
a-z A-Z 0-9 . /
- Il valore hash.
Come tale, i parametri necessari per verificare l'hash (incluso il salt) sono memorizzati all'interno della stringa hash stessa. Quando viene chiamata la funzione di verifica, convalida il prefisso, estrae il fattore di lavoro e sale, calcola l'hash della password specificata (utilizzando il fattore di lavoro e il sale) e confronta il risultato con l'hash memorizzato nella stringa hash specificata.
2. Posso farlo in uno scenario di bilanciamento del carico?
Sì. Non ci sono problemi qui. Basta calcolare l'hash su una macchina e inserirla nel database. Non ha senso cercare di distribuire una singola operazione di hash su più macchine usando il cloud voodoo. Basta modificare il tuo fattore di lavoro per adattarlo alle tue prestazioni e ai requisiti di sicurezza e farne a meno. Se il tuo server (s) non può prenderlo, rilasciare il fattore di lavoro nel codice di creazione hash. Poiché è memorizzato nell'hash, i nuovi hash utilizzeranno automaticamente il valore più basso e gli hash precedenti non saranno interessati.
Se davvero è veramente necessario farlo su più server, configura un sistema di distribuzione del lavoro in modo che ogni hash sia calcolato su una casella disponibile. Tuttavia, a quel punto direi che hai problemi più grandi delle semplici password di hashing.
I problemi di concorrenza nel tuo sistema di database non sono correlati alla funzione di hash che stai usando, quindi se hai problemi con questo ti suggerisco di pubblicare una domanda su Amministratori di database .