resistenza allo scrypt con sale "debole"

Il riutilizzo della password come parte del sale è, in generale, non raccomandato. La password è segreta e le informazioni potrebbero perdere in questo modo, a seconda dei dettagli interni della funzione hash. Ti suggerisco di astenervi.

Il nome utente è, di per sé, un sale non troppo buono, ma se lo hai solo, allora usalo. L'unica proprietà dei sali è unicità . Quando si utilizza il nome utente come sale, si corre il rischio di collisioni saline quando:

• Lo stesso nome utente viene utilizzato in due sistemi distinti (ad es. se ogni istanza di sistema ha un utente "admin" con quel nome utente esatto, per gli attaccanti diventa utile calcolare tabelle arcobaleno usando "admin" come salt).

• Un utente cambia la sua password (vecchia e nuova password quindi usa lo stesso sale e un attaccante può attaccare entrambi in parallelo).

Se i tuoi nomi utente sono unici in tutto il mondo (ad es. indirizzi email), il primo problema viene evitato. Una variante consiste nell'utilizzare come salt il nome utente con, come suffisso, un segno "@" seguito dal nome del server. Per le modifiche della password, è possibile diminuire l'intensità del problema con il semplice espediente di non richiedere regolari modifiche della password da parte degli utenti (questi non migliorano comunque la sicurezza).

Nonostante la tua pretesa di non avere mezzi per immagazzinare un sale, lo fai (forse senza rendertene conto): ovviamente stai memorizzando il nome utente e l'hash della password di ogni utente. La stessa memoria può essere utilizzata per memorizzare un altro elemento per ogni utente, un sale per utente casuale.

Inoltre non hai bisogno di ulteriori informazioni sull'utente per generare un sale. Hai solo bisogno di un generatore di numeri casuali una volta, quando viene creato l'account utente. Quindi hai solo bisogno di una buona fonte di entropia, che ovviamente è più facile a dirsi che a farsi su un server senza testa.

Forse la confusione deriva dal fatto che il termine "sale" viene talvolta usato in significati diversi. Alcuni autori sembrano utilizzare il termine "sale" per un input aggiuntivo (costante) globale utilizzato per calcolare gli hash delle password. Anche se abbastanza buono da sventare alcuni attacchi arcobaleno, questo non è un ottimo modo per implementare un sale. Un modo migliore è scegliere un sale diverso per ogni utente. Molte implementazioni, ad es. funzione crypt di PHP , aggiungi anche il salt (e alcuni parametri di hashing) al valore hash calcolato per convenienza, sollevandoti dal dover archiviare e recuperare separatamente il sale.

A pochi programmatori non piace archiviare il sale in un database, sostenendo che il sale potrebbe proteggere nello scenario che un utente malintenzionato ottiene il database delle password ma non un certo sale globale possibile cablato nel codice di autenticazione. Sospetto che tu possa essere di questa persuasione basandoti sul tuo commento sul fatto di non avere un database remoto. Si consideri che tale argomento può essere pericoloso: se si presuppone che il database delle password possa essere compromesso, ma alcune fonti di informazioni esterne (il sale o i sali) non lo sono, allora è molto meglio proteggere la propria password per utente database e questo ulteriore archivio di informazioni per utente. Soddisfano esattamente la stessa funzione e quindi dovrebbero essere ugualmente facili (o difficili!) Da proteggere.