Sia usando salt salt e diversi calcoli hash o un'altra strategia di delay (bcrypt, scrypt, quale dei due) ha senso non solo per molti utenti, ma sicuramente anche per un utente.
Salt impedisce a un utente malintenzionato di inserire banalmente il tuo hash in Google per ottenere una password istantanea senza nemmeno utilizzare uno strumento. Un buon sale casuale rende meno probabile che tu ne abbia scelto uno che qualcun altro ha costruito una tabella arcobaleno per il valore comunque (come per alcuni sali evidenti che potresti vedere, come gli ID utente).
Avere un sale diverso e casuale per ogni utente impedisce a un utente malintenzionato di riutilizzare gli hash in una tabella arcobaleno (o di utilizzare una tabella arcobaleno per un sale specifico già esistente facilmente). Costringe alla forza bruta ogni singolo utente. Non puoi impedire a qualcuno di continuare un attacco di forza bruta, e alla fine avrà successo (dal momento che anche le password "forti" sono relativamente deboli). Ma più tempo ci vuole per forzare un utente, più sicuri sono i rimanenti (se occorrono 2 secondi per forzare un utente, puoi fare 1000 utenti in poche ore - se ci vuole una settimana per utente, le cose sembrano molto meglio). Questo è il punto di usare qualcosa come bcrypt.
Ora, se c'è un utente solo un , forzare brute il primo utente significa una compromissione del 100%.
Quindi, usare una strategia che ritarda la forza bruta è importante almeno quanto con un database di molti utenti (ma concettualmente più importante).
Qualcosa come un GUID andrà bene, non importa se memorizzi la "stringa" da qualche parte o se la riutilizzi quando lo stesso utente cambia password. Un sale deve essere accessibile in qualche modo in modo da poter convalidare la password. Certo, sarebbe ovviamente bello se si potesse tenerlo segreto, ma questo non è né possibile né necessario per il suo scopo. Inoltre, se qualcuno può rubare il sale, avrà anche la password hash, dal momento che di solito viene memorizzata nello stesso posto. Pertanto, non vi è alcun "rischio aggiuntivo" che qualcuno possa preparare un tavolo arcobaleno prima del tempo per quel sale conosciuto (prima di rubare la password effettiva). Detto questo, se ti senti a disagio, non costa nulla anche a cambiare il sale ogni volta che l'utente cambia password.
Lo scopo del sale non è la crittografia di alcun tipo, ma il contrasto con le tabelle arcobaleno, che rendono l'inversione della funzione hash un'operazione banale.
In linea di principio, hardcoding un "sale scelto a caso" direttamente come proposto sarebbe altrettanto valido per il tuo scenario di un utente. Tuttavia, questo è un approccio errato poiché esiste la possibilità che alla fine riutilizzerai il codice per qualcos'altro (un tuo progetto diverso) o che alla fine avrai più di un utente.
Potresti non vederlo arrivare ora, ma generalmente è una possibilità.
Ora la cosa sulle cose che potrebbe accadere è che alla fine loro accadrà . Quindi, se esegui direttamente l'hardcode di un singolo salt perché c'è comunque un solo utente, alla fine avrai un buco di sicurezza, forse tra 10 anni quando non ci penserai più.
Non appena usi lo stesso sale per diversi utenti o per un singolo utente in diversi progetti, è piuttosto inutile. Non dovresti semplicemente rendere possibile che ciò accada.
Lo stesso vale, ovviamente, per l'approccio di avere un sale "permanente" che usi ovunque, ad esempio, per il resto della tua vita. Questo è un invito aperto alla costruzione di un tavolo arcobaleno, poiché così facendo si risparmia il lavoro computazionale. Attaccare una delle tue password sarà più o meno lo stesso carico di lavoro che attaccare tutte le password nel corso della tua vita.