Come usare la password salt nel modo giusto [duplicato]

Question

Come usare la password salt nel modo giusto [duplicato]

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

1

Comprendo l'idea di base dei Sali password.

Si genera una stringa di dati "casuale"
antepone questi dati a una password utente
salva la password e sale (sale forse anche nel formato 'chiaro')

Come nel seguente scenario: Hai un'applicazione client lato client e un'applicazione server con un database. L'utente si registra con un nome utente e una password utilizzando l'app mobile. La password riceve un valore aggiunto e viene archiviata con hash sul lato server. Anche il sale deve essere memorizzato sul lato server, perché non ci si può fidare del client mobile. E il sale dovrebbe in qualche modo essere collegato all'account utente giusto. Quindi supponiamo che sia memorizzato nella stessa tabella utente proprio accanto alla password.

Come si può usare un sale in questo caso per prevenire qualsiasi attacco (ad esempio attacco al dizionario)? Se l'utente malintenzionato ha già accesso al server del database, sarebbe facile ottenere il sale. Se l'attaccante utilizza l'interfaccia dell'applicazione server in modo corretto, il sale verrà applicato anche ai suoi "tentativi di attacco per l'accesso". Forse mi manca qualche punto importante su come questo tipo di attacco venga portato a termine in modo usuale. O questo sistema sarebbe sicuro solo se la salatura e l'hashing fossero eseguiti direttamente sul client?

passwords salt password-cracking

posta little_planet 27.01.2016 - 14:37

fonte

3 risposte

Leggi altre domande sui tag passwords salt password-cracking

La conversione della route da WAN a LAN attraverso un router aggiunge sicurezza? [duplicare] Come autorizzare gli utenti per il servizio di riposo

score 0 · Answer 1

Salatura di per sé non impedisce un attacco di dizionario contro la password stessa. Ma rende molto più difficile l'uso di rainbow-table o di attacchi di password comuni contro l'hash. Se usi un PBKDF invece di un semplice hash o HMac, anche un attacco di dizionario contro la password potrebbe diventare impossibile.

P.S .: Il sale non è nulla da tenere segreto. Il suo unico scopo è quello di randomizzare l'hash e renderlo unico per un altro fattore diverso dalla password scelta dall'utente.

score 0 · Answer 2

How could using a salt in this case prevent any attack (e.g. dictionary attack)?

Lo scopo di un sale è aumentare il lavoro di calcolo che l'utente malintenzionato deve eseguire assicurandosi che la stessa password sia stata modificata in modo diverso per i diversi utenti.

Supponiamo che tu abbia 1.000 utenti. E diciamo che l'attaccante usa un dizionario di 100.000 parole per provare come password. Se non ci sono sali, deve eseguire l'hash delle 100.000 parole e confrontarle con gli hash memorizzati dei 1000 utenti: il lavoro di calcolo è di 100.000 operazioni hash.

D'altra parte, se quegli utenti sono salati, allora deve hash 100.000 parole moltiplicate per 1.000 valori di sale per un totale di 100.000.000 operazioni di hash.

Considera che user_a e user_b entrambi usano 'hello123' come loro password. Se non viene usato sale, entrambi avranno lo stesso hash:

f30aa7a662c728b7407c54ae6bfd27d1

Ora consideriamo dove ogni utente ha un salt ("1" nel caso di user_a, e "2" nel caso di user_b). Salt + password sarà hash su due valori separati:

1e081602cd8b58d2fbb83b9d5c3511ee
e91627dc5b332b288e98cb82194cae06

e ora se l'attaccante diventa fortunato e indovina uno, non avrà indovinato entrambi.

score 0 · Answer 3

Salt non previene attacchi di dizionario. Salt rallenta attacchi di dizionario.

Immagina di avere un database con un gruppo di utenti e password:

user1:2ac9cb7dc02b3c0083eb70898e549b63
user2:60bd8ed7a768e8bd6925beb0a691aadb
user3:2ac9cb7dc02b3c0083eb70898e549b63
user4:8e601d1cd9d9ea079d8f15a0414e5d2b
user5:306578f0e3e22fc26e9295069d9961b1

Non sai quali sono le password, ma puoi vedere, dato un po 'di vista, che user1 e user3 hanno la stessa password, anche se è hash. Pertanto, puoi cercare gli hash più comuni e cercare di romperli, sapendo che avrai una manciata di utenti.

Se ho lo stesso database, con le stesse password, ma con sali unici per ciascuno (in questo caso, ho aggiunto il nome utente):

user1:08df37a942cb96598d8b459861bbcb45
user2:ed763cc6753bde74ad1ea491e31882dc
user3:95f6430be7989dc73dac21407817c048
user4:a01805e1f7d1f88e9b0d8eab8f1aebb6
user5:b913e9c11863bf6f9c49777a45dcc3ce

Ora, non puoi sapere se qualcuno degli utenti utilizza la stessa password l'uno dell'altro. La tua unica scelta per cercare di infrangere le password è provare a crackare a turno ciascuna.

Se so che i miei dati sono stati presi, dirò ai miei utenti di cambiare le loro password. Nel primo caso, però, quasi certamente otterrai alcuni hit abbastanza velocemente per password deboli e ti daranno accesso a più account.

Nel secondo caso, ricevi comunque gli hit con password deboli, ma ottieni solo un account per ciascuno. Questo mi dà un po 'di buffer per informare i miei clienti, e spero che meno di loro ne risentiranno.

E questo è prima che tu pensi che per alcune password comuni, l'esperienza fornirà agli hacker la conoscenza dei contenuti sulla base di hash comuni - user1 in questo caso sta usando Password1 , e sono sicuro che alcuni dei visitatori di questa pagina lo avremo notato quasi istantaneamente (è solo un hash MD5).

Il sale limita anche l'uso delle tavole arcobaleno, anche se al giorno d'oggi queste sembrano essere meno popolari. Ciò potrebbe comportare un aumento nell'uso di sale casuale.