Diciamo che ho un database e diverse applicazioni web separate che condividono il database. Se gli hash devono essere univoci e generati sul lato server, come posso assicurarmi di generare un hash univoco su più applicazioni?
Diciamo che ho un database e diverse applicazioni web separate che condividono il database. Se gli hash devono essere univoci e generati sul lato server, come posso assicurarmi di generare un hash univoco su più applicazioni?
Modifica: per qualche motivo, sembra che abbia completamente letto male la domanda. La risposta qui sotto si applica ad un'altra domanda che ha poca parvenza con la domanda reale.
Per quanto riguarda la tua domanda, un modo semplice per garantire l'unicità (con alta probabilità) è usare la casualità: da un PRNG crittograficamente strong, produci solo 16 byte casuali. Sono 128 bit. La matematica mostra che il primo riutilizzo avviene una volta che hai generato circa 20 miliardi di miliardi di valori di sale, cioè non succederà presto .
Le applicazioni possono anche utilizzare un metodo di generazione che cerca di raggiungere l'unicità utilizzando l'indirizzo MAC della macchina, l'ora corrente, l'ID di processo e whatsnot. GUID sono progettati per fare proprio questo. Ogni server può semplicemente richiedere un "nuovo GUID" quando ha bisogno di un sale; un GUID codifica come 16 byte. In effetti, un metodo di generazione GUID consiste nell'utilizzare un PRNG crittograficamente valido, quindi entrambi i metodi sono effettivamente gli stessi.
Si noti che per un buon sale, l'unicità dovrebbe essere in tutto il mondo , vale a dire applicare anche per altre applicazioni che sono collegate a altri database, che non si ' lo so. Casualmente e / o GUID si occupano anche di questo.
Risposta originale che non risponde affatto alla domanda:
Nell'hash della password, il salt è un "valore univoco": cioè, ogni password riceve il proprio valore salt. Viene generato un nuovo valore per ogni password. In particolare, il sale NON DEVE dipendere dal valore della password (quindi non può essere "calcolato" dalla password), e NON DEVE essere usato per più di una password (anche se lo stesso utente cambia solo la sua password, una nuova il sale deve essere generato).
Poiché il sale è necessario per ricalcolare l'hash, non c'è modo di sfuggirlo: è necessario memorizzare il sale nel database insieme all'output dell'hash corrispondente. Quando il sale viene memorizzato con il valore hash, chiunque abbia bisogno di convalidare una password legge prima entrambi il valore salt e il valore hash dal database, quindi usa salt e la password per ricalcolare il valore hash e vedere se corrisponde a quello appena letto dal database.
Le Bcrypt implementazioni codificano tradizionalmente l'output di hash e salt per te, come una singola stringa, quindi non lo fai devi preoccuparti di due valori da memorizzare: memorizzi una stringa una , leggi una stringa una e la libreria fa tutta la magia.
Se il database è condiviso, dovresti poterlo interrogare prima di aggiungere un hash. Aggiungi un vincolo univoco sul campo che contiene il sale in quanto ciò impedirà ad altre app di riutilizzare il sale. Per la generazione di sale consultare l'orso.