Sale casuale - necessario per un singolo utente?

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.

Quando non salti (o pepe) la password, la password non è molto strong e un hacker ottiene l'hash, può essere spezzato semplicemente guardando l'hash in una tabella arcobaleno (un elenco precalcolato degli hash delle password più comuni che possono essere trovate online ). Ma quando aggiungete alcuni dati aggiuntivi alla password, una tabella arcobaleno precalcata è inutile e un utente malintenzionato deve calcolare l'hash di ogni password comune, il che richiede un tempo di elaborazione considerevole, soprattutto quando si utilizza una funzione hash lenta (che è consigliata) .

Quando il tuo sale è sempre lo stesso (il che significa che è un "pepe") e un attaccante ottiene quel peperone, possono precompilare un tavolo arcobaleno per quel pepe che può essere usato per rompere qualsiasi hash con password futuro con lo stesso pepe . Quando l'applicazione è ampiamente distribuita e ogni distribuzione utilizza lo stesso pepe, sarebbe possibile per un utente malintenzionato eseguire il calcolo preliminare di tale tabella al fine di aumentare l'efficienza nel targeting di più distribuzioni. Quando l'applicazione è solo una singola istanza, una tale tabella arcobaleno potrebbe essere ancora utile. Un possibile scenario di attacco sarebbe quando ci sarebbe qualche vulnerabilità che perde l'hash e non si sa di tale vulnerabilità. Senza una tabella arcobaleno, potrebbe essere necessario molto tempo prima che un utente malintenzionato interrompa la nuova password dopo ogni modifica della password, il che ti richiederà un po 'di tempo per trovare e risolvere il problema. Con una tabella arcobaleno, ci vorranno solo pochi secondi per rompere qualsiasi nuova password impostata.

È sempre una buona idea salare visto che non vuoi che una tabella prestabilita rispetto a quell'algoritmo sia di beneficio nell'attaccare la password. Se la tua password viene compromessa perché una tabella arcobaleno è stata costruita rispetto al sale precedente, la modifica della password non sarebbe stata efficace.

Devi scegliere un nuovo salt per rendere qualsiasi sforzo esistente contro l'hash null e vuoto.

If I am implementing an application that will only ever be used by one user per database, is there any point in having a randomly generated salt?

Sì, la salatura delle password è sempre una buona idea . Non importa quanti utenti ci sono. Se un attaccante si impossessa del tuo database e gli hash non vengono salati, ha un enorme vantaggio, perché potrebbero esserci tavoli arcobaleno e altre tecniche per ottenere una corrispondenza per i valori hash appena ottenuti. Le password salate d'altra parte forniscono sicurezza, perché il sale non è noto all'attaccante in anticipo.

Pensa in termini di buone pratiche, perché il tuo sistema potrebbe essere adottato e utilizzato da più persone.

Surely if the salt was randomly generated, it would need to be stored alongside the encrypted user password and user ID, which would mean the attacker has access to the salt from the database

Questo non è affatto un problema ed è solitamente come è fatto . Un attaccante non ha alcun vantaggio nel conoscere il sale - almeno fino a quando la stessa funzione di hash non è fondamentalmente rotta.