Questa penso possa essere una domanda sciocca, ma sono diventato piuttosto confuso su cosa dovrei fare qui per il meglio.Anche il Salt per una password Hash deve essere "hash"?
Quando salate un hash della password, il sale deve essere anche sottoposto a hash o lasciato in chiaro?
NOTA: eseguo l'hashing di una password in SHA-256 e Salt è una stringa predefinita poiché verrà memorizzata una sola password alla volta.
TIA
Chris (Shamballa).
Non importa.
Lo scopo di un sale è impedire attacchi di precomputazione.
In entrambi i casi, l'hashing del sale o il suo utilizzo da solo, restituisce gli stessi dati aggiunti come un sale ogni volta. Se si salda il sale, tutto ciò che si sta facendo in modo efficace è cambiare il sale. Prima di eseguire l'hashing, lo si converte in una stringa diversa, che viene quindi utilizzata come sale. Non c'è motivo per farlo, ma non farà nulla di male se lo fai.
Hai solo bisogno di essere coerente e utilizzare lo stesso metodo ogni volta o si finirà con un diverso hash della password.
Il sale non deve essere sottoposto a hash, in quanto è necessario il valore originale da combinare con la password prima di eseguirne l'hashing.
Non si deve eseguire l'hash del sale, poiché gli hash sono a senso unico. È necessario il sale in modo da poterlo aggiungere alla password prima dell'ashing. Potresti crittografarlo, ma non è necessario.
La cosa fondamentale dei sali è che ogni password deve avere il proprio sale. Idealmente, ogni sale dovrebbe essere unico, ma anche casuale è buono. Il sale dovrebbe quindi essere abbastanza lungo da consentirgli di essere unico per ogni password.
Se tutti i sali sono uguali, è ovvio per il cracker (chi può vedere i propri valori hash), quali account hanno la stessa password. I valori dell'hash saranno uguali. Ciò significa che se creano una password, ottengono più di un account senza lavoro aggiuntivo. Il cracker potrebbe persino bersagliare quegli account.
Si dovrebbe presumere che il cracker acquisirà sia il valore di sale che di hash, quindi l'algoritmo di hash deve essere sicuro.
L'assenza di sale impedisce l'utilizzo di tabelle arcobaleno pre-calcolate per decifrare il valore dell'hash e l'aggiunta di sale per ogni account elimina il desiderio del cracker di precomporre le proprie tabelle arcobaleno utilizzando il sale.
@aaaa bbbb, se si salta il sale prima di memorizzarlo, non è possibile recuperare la password. Se usi un algoritmo di hashing nella tua generazione di sale, va bene. Il sale è la parte che viene aggiunta al testo in chiaro appena prima di eseguire l'hashing del valore. Non è un sale prima di quello. –
No non si deve hash il sale. Il sale è in testo chiaro ed è necessario per ricalcolare la password e controllarla con quella memorizzata nel file di password con hash.
Ma se avete bisogno di un forte procedura di salatura è possibile calcolare la password salata in questo modo:
SaltedHashedPwd = H (H (H (H (..... H (PWD-k + SALT-k) + SALT-k) + SALT-k) .....) + SALT-k + N
H è la funzione di hash SALT-k è una stringa k-casuale si utilizza come sale PWD-k è il k-password di (ogni password ha un diverso sale) N è il numero di iterazioni che componi la funzione H
Nello standard PKCS # 5 utilizza N = 1000!
In questo manne un attacco di dizionario non è possibile perché per ogni parola nel dizionario e per ogni SALE nel file di password, l'utente malintenzionato deve calcolare l'hash. Troppo espansivo nel tempo!
Penso che N = 100 dovrebbe essere sufficiente per i vostri usi :-)
Sbagliato. "Non importa" è la risposta corretta. Puoi eliminare il sale, che in effetti ti dà un nuovo sale che funziona. Tutto quello che devi fare è essere coerenti. –
Vedere meglio quello che ho scritto. Puoi avere la concatenazione di PWD e SALT ma alla fine devi concatenare la forma chiara di SALT. Altrimenti non è possibile ricalcolare l'hash nella fase di verifica. – robob
Come il sale deve essere salvato con l'hash (o almeno deve essere recuperabili con l'hash), un utente malintenzionato potrebbe possibilmente ottenere sia la password salt che la password hash. In alcune delle mie applicazioni, ho memorizzato il sale codificato nel database (con una chiave nota solo all'applicazione). Il mio ragionamento era che l'archiviazione del sale non crittografato insieme alla password hash avrebbe reso più facile craccare le password, poiché un hacker che sarebbe stato in grado di recuperare la tabella delle password (e avrebbe saputo o formulato un'ipotesi sull'algoritmo hash) sarebbe in grado per trovare corrispondenze tra gli hash di parole ben note (attacco dizionario) tagliando ogni parola nel dizionario e salendo poi con il sale a cui ha accesso. Se il sale fosse crittografato, tale attacco non sarebbe possibile a meno che non avesse anche accesso alla chiave di crittografia nota all'applicazione.
(Se qualcuno vede un errore in questa logica, si prega di commentare.)
Mi raccomando ancora fortemente contro l'utilizzo di un sale statico. Probabilmente sconfigge lo scopo di avere un sale, anche se si memorizza solo una password alla volta. – Slartibartfast
Sono d'accordo, probabilmente dovresti usare un sale diverso per ogni password, devi solo usare lo stesso sale ogni volta per una determinata password dell'utente. Ma il punto qui era che un sale è solo qualcosa in più aggiunto. Se si frusta il sale prima di usarlo, questo non lo cambia, lo rende semplicemente un qualcosa in più. –
È semantica, ma non è necessario aggiungere un po 'di sale. Un sale deve essere recuperabile in chiaro per poter essere utilizzato. Poiché un hash è a senso unico, non devi eliminare il sale. Se vuoi usare un algoritmo hash per generare il tuo sale, va bene, ma il valore hash risultante diventa il nuovo salt e devi essere ancora in grado di recuperarlo in testo non crittografato. Se hai veramente cancellato il tuo sale, hai perso il tuo account. –