È una buona idea utilizzare un input dell'utente come SALT?

Vuoi che il sale sia unico. Inoltre, non vuoi che il sale sia "rivelatore" perché lo memorizzi "così com'è", come testo chiaro, sul server del database. Un sale non deve essere segreto, ma le persone possono diventare nervose se conservi, senza protezione, qualche valore che sentono dovrebbe essere segreto - e questo include il nome da nubile della madre, che è apparentemente usato da alcuni Banche degli Stati Uniti come meccanismo di autenticazione.

Garantire l'unicità dei sali è facile dal lato server: basta generare una sequenza abbastanza lunga di byte casuali. La casualità non è unicità , ma funziona altrettanto bene con una schiacciante probabilità. Buone funzioni di hashing della password possono utilizzare qualsiasi sequenza di byte come sale . Buone implementazioni delle funzioni di hashing della password genereranno anche il sale correttamente per te e lo includeranno nel loro output, quindi non devi preoccupartene (questo è ciò che normalmente si verifica con bcrypt ); in tal caso, dimentica tutto di questa risposta e della tua domanda e lascia che la biblioteca faccia il suo lavoro.

Chiedere all'utente di rispondere al proprio sale è una cattiva idea. In primo luogo, è tecnico e si può presumere che la maggior parte degli utenti non capisca nulla di ciò che è un sale; molti di loro diventeranno nervosi. Inoltre, quando gli utenti fanno capiscono cos'è un sale, allora sanno che un buon sale è un sale casuale; gli utenti umani non sono ben attrezzati per generare casualità (non fa parte di ciò che un cervello umano è bravo a). D'altra parte, il tuo server può fare casualità. Infine, non puoi contare sugli utenti umani per rafforzare l'unicità - e, in particolare, quando un utente cambia la sua password , non cambia il suo nome da nubile della madre , quindi è un fallimento inevitabile all'unicità.

Modifica: se il tuo linguaggio di programmazione offre UUID , altrimenti noto come GUID (la distinzione è bizantina), questi sono buoni per i sali. Ad esempio, in .NET, chiama semplicemente System.Guid.NewGuid() . Esistono vari metodi per creare tali valori, ma tutti mirano all'unicità mondiale (potrebbero essere prevedibili, ma non è un problema per i sali). "Metodo 4" è in realtà 122 bit di casualità. Il metodo migliore per la generazione di sale è lasciare che sia il codice della libreria di hashing delle password a farlo, ma se si deve usare una libreria che non lo fa da sé, usare un UUID fornito dal sistema è un metodo discreto e poco impegnativo.

Un salino viene usato per prevenire l'uso di tavoli arcobaleno e richiede che un attaccante attacchi ogni hash separatamente. Funziona solo se non è possibile creare tabelle arcobaleno per l'intero spazio di sali.

Un utente scelto sale è a) altamente probabile che non sia univoco, anche a livello locale eb) molto probabilmente un valore che potrebbe essere trovato in un database di una tabella arcobaleno rispetto a uno scelto a caso. Entrambi determinano una notevole riduzione dell'efficacia del sale poiché semplificano gli attacchi contro l'hash.

Sebbene il sale non debba essere casuale, deve essere globalmente unico in modo che non sia possibile utilizzare un DB di tabelle arcobaleno. La casualità è il modo più semplice per garantire questo, anche se altre opzioni valide per derivare un sale funzionano.

Non c'è motivo di usare un input da parte dell'utente, è perfettamente corretto usare semplicemente un numero casuale e memorizzarlo nel database con il record dell'utente. Ciò non ha un impatto negativo sulla sicurezza in quanto il sale non deve essere univoco, ma deve semplicemente rendere inutilizzabili le tabelle arcobaleno precalcolate.

Come ha detto Terry nella sua risposta, l'unico requisito per un sale deve essere unico per ogni password. Pertanto vorrei solo generare un test casuale di almeno 16 byte (assicurati di utilizzare il generatore casuale del tuo sistema operativo e non una strana implementazione fai-da-te). Il nome da nubile di tua madre può essere qualcosa che in realtà è probabile (non ci sono tanti nomi diversi, forse solo un migliaio) da ri-verificarsi, è più improbabile che generi i byte casuali da solo.

Ricorda che ti è permesso di memorizzare il testo in chiaro salato accanto alla password, un sale non è considerato segreto.

L'unico requisito di un sale è che sia globalmente unico. Se sei sicuro di poter raggiungere questo requisito, con tutti i mezzi vai avanti.

Pensateci però, che cosa offre esattamente lo schema proposto rispetto al metodo standard esistente per l'acquisizione di alcuni byte di dati casuali? Perché vuoi incazzare i tuoi utenti chiedendo un altro input? Non aggiungere più complessità per te stesso e per i tuoi utenti. Segui il metodo standard che di solito è gestito automaticamente da qualsiasi libreria di hashing delle password decente.

Non c'è ragione per non fare un salt random. Non hai necessariamente bisogno di numeri casuali crittograficamente forti, solo alcuni bit da un PRNG che viene seminato con un tempo di alta risoluzione del giorno e alcuni altri valori come l'ID del processo e quant'altro.

L'aggiunta di domande per ulteriori informazioni sul profilo solo allo scopo di creare un sale sembra una cattiva idea dall'esperienza utente e dal punto di vista dell'efficienza.

Se intendi creare il sale mediante l'hashing delle informazioni sul profilo utente, utilizza i valori delle proprietà che sono già presenti. Ma torniamo al primo punto: anche se usi queste informazioni, non c'è ragione di non mischiare variabili addizionali non correlate al profilo utente, come la porzione dei microsecondi dell'ora del giorno.

Re: The likelihood of the exact same name in our 2000 strong community is extremely little.

Hai mai sentito parlare del compleanno paradosso ? Le probabilità che qualcuno su 2000 persone abbia un cognome particolare sono inferiori a quelle di due persone in una folla di 2000 che hanno lo stesso cognome.