Le stringhe di sale sono memorizzate per applicazione? [duplicare]

Question

Le stringhe di sale sono memorizzate per applicazione? [duplicare]

#1 da (0 voti)
#2 da (0 voti)
#3 da (0 voti)

0

1) Poiché la memorizzazione di password in testo semplice nei database non è sicura e quindi non è una buona pratica.
password memorizzata in db="abcde" (testo normale)
2) Per evitare ciò, le password vengono memorizzate dopo essere state sottoposte a hashing utilizzando alcune tecniche di hashing affidabili come SHA256 o SHA 512 ecc.
password memorizzata in db = SHA256 ("abcde") = 36bbe50ed96841d10443bcb670d6554f0a34b761be67ec9c4a8ad2c0c44ca42c
3) Ma dal momento che le password hash sono vulnerabili agli attacchi dei tavoli arcobaleno o agli attacchi dizionario, viene applicata una nuova tecnica di salatura. Qui viene aggiunto un salt (una stringa) (normalmente prefisso o suffisso) alla password e quindi la password risultante + salt viene hash e archiviata in db.
password + salt="abcde" + "catsarecool" e < br> password memorizzata in db = SHA256 ("abcdecatsarecool") = 8A85335AB6B09405FF34DCC146A0B690A3BFA834B8C53EBAD77F64C653A89F82

Ora posso spiegare / chiedere ciò che voglio confermare e le preoccupazioni che ho -
1) quando si usa salting (3), suppongo che anche la stringa salt debba essere memorizzata nel DB. Per favore conferma?
2) Se la stringa salata deve essere memorizzata in DB, qual è la procedura migliore: utilizzare un sale comune per tutti gli utenti dell'applicazione o un solo sale per utente.
3) a) L'intero scopo dell'hashing era che qualsiasi utente malintenzionato che ottiene il dump DB sarà in grado di vedere le password in testo semplice, che è meno sicuro rispetto a quando è sottoposto a hash.
b) E lo scopo della salatura è rendere questo lavoro più difficile rendendo impossibile l'uso di un dizionario o di un arcobaleno in quanto l'attaccante dovrà anche fare una supposizione per "sale" insieme alla password. Ma se un utente malintenzionato è in grado di ottenere il dump di DB in qualche modo, l'utente malintenzionato avrà anche i "sali" che, se memorizzati in db, vengono archiviati come testo normale. Quindi, ora che l'hacker conosce il "sale", non è il suo compito scoppiare la password tanto difficile quanto lo era quando cercava di decifrare le password con hash.

Non sono un esperto di sicurezza ma sono consapevole che per memorizzare le password, le tecniche più lente come bcrypt o scrypt o PBKDF2 saranno più appropriate. Commenti su queste o altre tecniche che sono le migliori per memorizzare le password sono i benvenuti. Ma sono preoccupato per lo scenario di cui sopra per scopi di apprendimento? Quindi condividi gentilmente i tuoi pensieri.

passwords salt password-cracking scrypt sha2

posta joveny 22.07.2017 - 07:03

fonte

3 risposte

Leggi altre domande sui tag passwords salt password-cracking scrypt sha2

Certificato di firma del codice per l'applicazione incorporata Come configurare un server per i file? [chiuso]

score 0 · Answer 1

Hai più domande in una, quindi risponderò a quella che credo sia la tua domanda principale.

Utilizza una quantità di sale per password per utente. Ciò interrompe gli attacchi da tavolo arcobaleno in quanto un attaccante ora ha bisogno di una tabella arcobaleno per ogni possibile password con ogni sale che stai utilizzando. Per loro calcolare questo sarebbe impossibile. Raccomanderei l'uso di PBDKF # 2 o bcrypt o di un'altra funzione di derivazione della chiave basata su password (PBKDF). In questo fraseggio di giorno in giorno, anche con sale, ora è visto come una soluzione più debole rispetto all'utilizzo di un buon PBKDF.

score 0 · Answer 2

Lo scopo di un sale è impedire l'uso di un tavolo arcobaleno. Gli hacker spesso hanno abbandonato file di grandi dimensioni che contengono hash precalcolati, lo usano per accelerare il cracking delle password.

Aggiungendo un salt alla tua password, stai essenzialmente trasformando "password" in "passwordGSVKELWO". Prevenire l'uso di una tabella arcobaleno e aumentare ulteriormente la complessità della bruteforcing della password. Tuttavia, per poter verificare l'hash, è necessario conoscere il sale utilizzato per crearlo. Pertanto, si accetta di memorizzare il sale insieme all'hash della password e di utilizzarlo per verificare la password di un utente al momento dell'accesso. Ora, perché stai tenendo traccia del sale, devi assolutamente andare avanti e utilizzare quelli unici per ciascun utente.

Algoritmi come bcrypt hanno un parametro chiamato work, che determina quanto sia intensa la CPU. Un valore di lavoro elevato può aggiungere uno o due secondi per l'accesso, ma quando un utente malintenzionato tenta di decifrarlo diventa esponenzialmente più lento.

L'utilizzo di queste tecniche è accettabile per l'apprendimento, ma non per lo sviluppo. Utilizza una libreria ampiamente conosciuta e accettata per gestire l'hashing della password e il controllo, per assicurarti di essere protetto contro tutte le vie di attacco.

score 0 · Answer 3

Ok molte domande, eccoci qui.

1) Sì, il sale deve essere memorizzato nel database. Altrimenti non sarà possibile verificare l'hash. In genere, il sale come array di byte viene aggiunto o aggiunto all'hash e quindi codificato in base 64 e memorizzato come stringa.

2) Sì, un sale per utente è la norma, memorizzata come sopra.

3) a) Sì assolutamente. b) È ancora un po 'più difficile. Un valore unico per utente indica che due utenti con la stessa password hanno hash diversi. Con un sale fisso saranno uguali. Ciò significa che gli hash possono essere interrotti da una sorta di analisi della frequenza.

La migliore pratica corrente non è quella di usare un singolo hash usando qualcosa come sha256 dato che l'algoritmo è veloce e che rende più veloce la forza bruta. In genere ciò si ottiene eseguendo molti round (forse 10000) di hashing o qualche altro metodo di ottimizzazione della quantità di lavoro richiesto. Come utente puoi aspettare un secondo per verificare l'hash al momento dell'accesso. Come attaccante, aumenta enormemente il tempo impiegato