Quando gli utenti si registrano sul mio sito, voglio memorizzare il loro nome utente e la password hash nel mio database. Quando ho cancellato quella password, la salverò usando PHP.
Il problema è che non voglio salvare il sale in un database che potrebbe essere compromesso, che sconfigge lo scopo della salatura, vero?
Invece, voglio avere un sale unico per utente che è memorizzato su un server separato, ad esempio una piattaforma cloud?
Questo è sicuro / il modo giusto per andare?
Non è un problema se l'attaccante impara i sali. I sali non sono pensati per essere segreti. Ciò che è importante per un salt è che è univoco per ogni istanza di password con hash (vale a dire non solo un sale unico per utente, ma il sale dell'utente deve essere cambiato quando l'utente cambia la sua password).
Se pensi che il tuo sale sia qualcosa che può essere condiviso tra le password, ma non deve essere noto all'attaccante, allora non è un sale; questo è un tasto . Alcune persone chiamano tali tasti "pepe" nel caso di hashing della password. Questo è un concetto abbastanza distinto dai sali e, in generale, aggiunge complessità e aumenta la frequenza dei guasti senza migliorare realmente la sicurezza. Prendi le basi prima (ad esempio usando la funzione giusta con i sali appropriati).
Il metodo normale è quello di memorizzare il sale insieme al valore hash. Preferibilmente, si lascia che la libreria di hashing delle password generi il sale e gestisca la codifica del valore di hash e di sale come una singola stringa. Quindi assicurati di utilizzare PHP 5.5 (o più recente) e usi password_hash () (e non usare l'impostazione salt manuale: la libreria fa la cosa giusta per impostazione predefinita, quindi lasciatela fare). Tra le possibili funzioni di hashing della password , bcrypt è il migliore può avere al momento, ed è quello che password_hash() userà.
La mia risposta sarà diversa da chiunque altro. Tom Leek e Xander hanno fornito una buona intuizione, quindi ecco la mia risposta alla tua domanda iniziale, espandendo da questo tuo commento:
"I don't want to store the salt in a database that could be compromised - that defeats the purpose of salting, doesn't it?"
Sì e no. Se qualcuno ha compromesso il tuo database, hai cose più grandi di cui preoccuparti. Il solo fatto che siano arrivati così lontano apre il potenziale per lo sniffing sul filo, dove se non viene utilizzata la crittografia, i dati sono visibili prima di essere crittografati e inseriti in un database.
I sali proteggono perché aggiungono uno strato per contrastare le fessurazioni. Un cracker ha bisogno di hash una password E un sale per produrre qualcosa da confrontare con un hash noto per trovare la password giusta. La maggior parte dei cambiamenti salanti, altrimenti se ciò accadesse, la salatura sarebbe inutile:
User1 (password) [ kitten + your_static_salt = thundercat ]
User2 (password) [ kitten + your_static_salt = thundercat ]
Nelle precedenti fasi teatrali, due utenti hanno scelto la parola "gattino" come password che viene salata per produrre il risultato di "thundercat". Se ciò è vero, la porzione salata è in qualche modo inutile. Se stai usando password_hash da PHP, il sale viene generato casualmente per te, il risultato sarebbe il seguente (ovviamente ridotto a icona per chiarezza):
User1 (password) [ kitten + password_hash = thundercat ]
User2 (password) [ kitten + password_hash = uppercut ]
In quanto sopra, vediamo la stessa password, PHP's password_hash cambia il salt ogni volta. Non c'è bisogno di reinventare nessuna ruota qui, perché è necessario fare alcune immersioni profonde in crypt () per capirlo. Se sei veramente che riguarda la salatura e la sicurezza della password, dai un'occhiata a Phpass di Solar Designer Tuttavia, quando dichiari di essere preoccupato per qualcuno che comprometta il db stesso, questo cambia la portata di ciò che un utente malintenzionato potrebbe fare senza nemmeno dover decifrare le password per cominciare.
Aggiungerebbe complessità senza aggiungere molto valore.
Non sconfiggere lo scopo della salatura, come si capisce, perché un sale non è destinato a essere segreto, solo univoco. L'obiettivo non è rendere impossibile la determinazione della password dall'hash, ma rendere impossibile il calcolo preliminare degli hash che possono quindi essere confrontati direttamente con il tuo per vedere se c'è una corrispondenza e per garantire che password identiche producano risultati diversi hash.
Quindi, tentare di mantenere il sale separato e segreto non fa parte del design della costruzione, e sarebbe meglio usare il tempo e le risorse di sviluppo per rafforzare e proteggere l'applicazione e il database dal compromesso in primo luogo .
Non è necessario.
Pensaci in questo modo ...
Se il tuo server ha accesso ai sali e un utente malintenzionato si radica sul tuo server, otterrà l'accesso ai tuoi "sali memorizzati a distanza" ovunque si trovino.
Poiché utilizzi PHP, controlla le funzioni password_hash e password_verify.
No, non farlo.
Primo: i sali non sono segreti. Sono utilizzati per assicurarsi che l'annullamento dell'hash per una password non rivela tutte le copie di tale password nel database. È usato per rendere più difficile l'inversione dell'hash.
Secondo: aumenterà la latenza. Il tuo sistema di autenticazione dovrà ottenere il nome utente e la password da parte dell'utente, accedere a un database, ottenere l'ID utente, chiedere a un server remoto di eseguire l'id utente, calcolare e decidere se l'utente ha la password corretta o meno. p>
Terzo: lo script avrà le credenziali per accedere al database del sale . Se qualcuno entra nel tuo sistema, sarà in grado di accedere anche a quel database. Anche se non possono accedere direttamente al database, avranno accesso al database userid , itereranno attraverso tutti gli userid e otterranno tutti i dati dal database salt.
E tutti questi aspetti negativi non ti daranno ulteriore sicurezza, non sarà nemmeno marginalmente migliore.
La crittografia è un problema risolto. Un sacco di esperti crittografi hanno già definito il modo migliore per crittografare e scambiare informazioni. Segui le linee guida e sarai al sicuro.