Qualcuno non conserva i sali?

Non conservare il sale è un cattivo consiglio.

Lo scopo principale di un salt è che ogni password utente deve essere attaccata individualmente.

Se non salvi il sale, allora, come hai detto, devi provare ogni singola combinazione di sali per convalidare la password. Se è necessario controllare ogni singola combinazione di sali, ciò significa che il sale non può essere troppo lungo (hai menzionato 12 bit in un commento). Se il sale non è lungo, significa che il sale verrà ripetuto per molti utenti. Se viene ripetuto per molti utenti, significa che l'attaccante sarà in grado di attaccare più utenti contemporaneamente, il che farà risparmiare tempo all'attaccante.

In questo modo, hai quasi completamente annullato lo scopo dell'utilizzo di un sale.

Un sale "segreto" è noto come pepe .

Da Wikipedia:

A pepper can be added to a password in addition to a salt value. A pepper performs a similar role to a salt, however whereas a salt is commonly stored alongside the value being hashed, for something to be defined as a pepper, it should meet one of the following criteria that define it a more carefully hidden 'secret' than the salt value:

• The pepper is held separately from the value to be hashed
• The pepper is randomly generated for each value to be hashed (within a limited set of values), and is never stored. When data is tested against a hashed value for a match, this is done by iterating through the set of values valid for the pepper, and each one in turn is added to the data to be tested (usually by suffixing it to the data), before the cryptographic hash function is run on the combined value.

Il vantaggio di un pepe è che un attaccante deve ora indovinare fino al numero di possibili permutazioni di un valore di pepe per ogni voce in chiaro.

I peperoni aumentano la lunghezza dell'attacco per un hash specifico, mentre un sale no.

Ricorda che un sale è un'effettiva mitigazione per gli hash precalcolati e fa sì che un attaccante passi molto tempo ad attaccare una serie di hash. Tuttavia, se solo un hash è preoccupante e non si devono usare gli hash precalcolati, un sale non aumenta la lunghezza dell'attacco. Tuttavia, un Pepper forza l'autore dell'attacco a utilizzare supposizioni multiple per ogni password in chiaro, anche per un singolo hash.

In questo modo, un pepe è simile a allungamento della chiave .

La maggior parte delle implementazioni preferisce il key stretching to peppers.

La mia osservazione personale è che la maggior parte delle implementazioni preferisce il key stretching ai peperoni. Non ho un riferimento per questo in modo che i lettori possano fornire riferimenti di supporto o dissenzienti nei commenti. Le persone tendono a preferire lo stretching chiave perché ha un costo di prestazione noto e previsto e un vantaggio in termini di sicurezza. Per calcolare l'ennesimo round di un hash, gli hash N devono essere calcolati. Con un pepe, tuttavia, è possibile calcolare solo il numero di tentativi previsti . Considerare un pepe da 1 byte, l'attaccante avrebbe bisogno di 256 tentativi per indovinare tutte le possibili combinazioni, ma il valore atteso è 128, e l'attaccante potrebbe (in media 1/256 volte) indovinare il valore al primo tentativo.

Peppers e Key Stretching possono funzionare l'uno contro l'altro.

Lo stiramento dei tasti è efficace perché è possibile impostare il numero di cicli in base al periodo di tempo in cui si desidera eseguire il calcolo di un hash. Supponiamo che tu voglia un singolo assegno impiegare mezzo secondo sull'hardware attuale, basta aumentare i turni fino a quando ciò non si verifica.

Con un peperone, poiché devi indovinare più valori per ogni password, la dimensione di un peperone deve essere inversamente proporzionale al numero di giri per mantenere costante il tempo di calcolo.

Consigli pratici sulle implementazioni di hash

Il miglior consiglio per le implementazioni di password / hash consiste nell'utilizzare metodologie ben note e librerie testate. Dovresti utilizzare bcrypt o pbkdf2 con un sale unico e molti round. Questi algoritmi tendono ad avere implementazioni ben note in molte lingue e framework. Se trovi una libreria ben nota e testata che include un peperone, oltre ai sali e allo stretching chiave, potrebbe valerne la pena utilizzarla, ma il vantaggio aggiuntivo spesso supera i costi di prestazione.

Sfondo: dovresti utilizzare un hash di password lenta. (per esempio bcrypt) Per "lento" intendo computazionalmente costoso, prendendo più di 100 ms (sul tuo hardware) ^{con la protezione DoS *} per testare una singola password. Ciò serve ad aumentare la potenza di elaborazione necessaria (sull'hardware dell'attaccante) per trovare la password con la forza bruta, nel caso in cui l'hash venga rubato.

Per utente sale unico altamente raccomandato. (nel caso di bcrypt viene generato automaticamente) Salt dovrebbe essere altamente unique (cioè lungo e casuale), ma non segreto . Usando sale unico significa che un utente malintenzionato dovrebbe eseguire un lavoro di forza bruta separato per ciascun utente .

Se non c'erano "sale", l'attaccante poteva usare immediatamente un Tavolo Arcobaleno e nessuna forza bruta.

Se si utilizza solo un "sale condiviso", un utente malintenzionato potrebbe crackare le password per tutti gli utenti con un job forza bruta singolo . (non veloce come una tabella arcobaleno ma ancora molto più facile di una forza bruta separata Job per ognuno)

Risposta: Se dovessi "non memorizzare" il sale ("forza bruta l'hash in fase di esecuzione" come suggerisce il tuo professore)

• i possibili sali dovrebbero essere molto pochi
• l'hash dovrebbe essere un po 'più veloce

Ciò annullerebbe totalmente lo scopo di Salt , compromettendo gravemente il beneficio di un hash lento. Questo è un grave errore di progettazione da parte del tuo professore. Fondamentalmente, è lanciare il proprio schema di archiviazione delle password, dove dovrebbe utilizzare l'algoritmo ben controllato bcrypt (o scrypt o PBKDF2 ) come previsto per essere utilizzato .

_{* Come commentato @Navin , questo sarebbe un potenziale vettore di attacco DoS. Una soluzione è limitare il numero di tentativi orari per IP e per nome utente. È anche possibile che tu debba ridurre la "lentezza" del tuo hash a solo 10ms. Questo non è buono come 100ms da una prospettiva di "hash rubato", ma comunque migliore di "microsecondi".}

Il tuo professore non è corretto. Il punto di un sale è aumentare l'entropia delle password con hash per impedire qualsiasi tipo di attacco pre-computazione su di esse e impedire che la stessa password di utenti diversi abbia lo stesso valore hash.

Essere in grado di provare tutti i valori di sale possibili significa che devi avere una quantità molto bassa di entropia nel sale, il che significa che è possibile una precalcolazione tramite le tabelle arcobaleno.

Potresti usare il sale in questo modo. Sarebbe una sorta di processo di hash-stretching. Solitamente allunghi un hash ripetendo l'algoritmo diverse migliaia di volte, il che rallenta gli utenti e gli aggressori di 1000 volte, ma di solito gli utenti non si preoccupano del rallentamento. L'uso di un sale in questo modo avrebbe l'effetto di eseguire un algoritmo di allungamento hash ripetendolo per molti hash sconosciuti.

Tuttavia, questo è un approccio estremamente insolito. I metodi tradizionali di salatura fanno ciò che i sali dovrebbero fare molto meglio (fare in modo che nessuno possa precomputare una tabella delle password). I metodi tradizionali di fare l'hash stretching fanno ciò che l'allungamento hash dovrebbe fare molto meglio (fallo in modo che gli hacker impieghino più tempo a calcolare le password). Usare un sale in questo modo è come raddoppiare i due insieme. Il risultato è una specie di tipo di lavoro, ma gli approcci più puliti fanno entrambe le soluzioni lontano meglio del brutto mismash delle tecniche.

Piuttosto che pensare al sale in termini di forza bruta, mi piace pensarlo in termini di dire che rende impossibile dire qualcosa su una password, inclusa la sua relazione con altre password, osservandola. Se il sistema non utilizza la salatura, l'analisi delle password con hash di due utenti indica se le loro password reali corrispondono. Se un sistema salted utilizzando solo il nome utente, ma nulla di casuale, specifico per il tempo o specifico del sistema, quindi guardando le password con hash di un utente su due macchine che utilizzano lo stesso approccio, potrebbe indicare se le password dell'utente sulle due macchine corrispondono. Se il sistema salted utilizzando l'ID di sistema e il nome utente, ma nulla di casuale o di tempo specifico, allora qualcuno con accesso a due diversi hash di password dallo stesso utente potrebbe dire se le password associate corrispondono.

L'effetto della salatura casuale è di far sì che non ci siano due hash che utilizzano la stessa password, anche se coinvolgono lo stesso utente sullo stesso sistema. Mentre si potrebbe ottenere un effetto simile senza immagazzinare i sali se i tentativi di log-in dovessero essere brutali, forzandoli, un tale approccio limiterebbe la lunghezza pratica del sale che si potrebbe usare e quindi aumenterebbe la probabilità che le password usate in due contesti avrebbero il stesso sale e quindi essere riconoscibile come corrispondente.

Che cosa ti dà la salatura? Gli utenti malintenzionati dispongono di database precalcolati di valori hash per le password, comuni e non. Se acquisiscono il tuo database e hanno l'hash delle password per ogni utente, è semplice controllare gli hash rispetto a quei valori senza sale.

Con un salt casuale che viene memorizzato insieme alla password, questo metodo follemente non è più possibile. Ma se l'attaccante ha il sale così come l'hash, è ancora possibile utilizzare gli attacchi dizionario per password deboli o forzanti brute per quelli brevi. Tutto ciò che l'utente malintenzionato deve fare è utilizzare il sale e provare diverse password utilizzando un dizionario o un attacco a forza bruta.

Ora diciamo che quando la password è cambiata, la si hash con un valore casuale di 12 bit che non è memorizzato insieme al sale che è. Quindi, ogni volta che controlli la password, devi provare tutti i 4096 valori. Sul mio computer ci vogliono circa 3,5ms, quindi 284 password possono essere controllate ogni secondo. Un po 'più di CPU sul server quando qualcuno effettua l'accesso, ma per qualcuno che prova un dizionario o attacchi di forza bruta, hai reso il loro lavoro molto più difficile, anche se hanno l'hash e il sale.

Sembra esserci qualche merito nell'idea di non memorizzare un numero controllato di bit di sale, che è configurato in modo indipendente ed è indipendente dalla dimensione del sale.

Supponiamo di avere sali da 32 bit. Potremmo scegliere di memorizzare solo 22 bit e la forza bruta attraverso i restanti 10 quando effettuiamo l'autenticazione. L'effetto di questo è come se alla funzione di hashing fossero aggiunti altri round. Non così tante che l'impatto sull'autenticazione legittima, ma sufficiente per aumentare la difficoltà del cracking a forza bruta.

L'anno prossimo, le macchine diventano più veloci. Quindi passiamo attraverso il database delle password e buttiamo giù un po 'da ogni sale: ora memorizziamo solo 21 bit e dobbiamo forzare la forza fino a 11.

È come se raddoppiassimo la forza di hashing, ma senza l'interruzione della sostituzione dell'algoritmo e inducendo gli utenti a ri-hash le loro password (che è lasciata alla normale politica di scadenza della password).

Questo approccio di "progress salt salting" potrebbe prolungare la vita utile delle funzioni di hashing.

Tuttavia, questo tipo di approcci rallentano l'autenticazione legittima e dell'attacco a forza bruta di un fattore uguale, quindi nella migliore delle ipotesi forniscono un livello di sicurezza minore. La nostra attenzione dovrebbe essere posta in miglioramenti che aggiungano solo una quantità costante di tempo extra all'uso legittimo, mentre moltiplicano la difficoltà di cracking. Naturalmente, un miglioramento che ha questa proprietà sta aumentando la quantità di entropia nella frase della password! Ogni bit di entropia aggiunto alla password aggiunge un costo costante agli utenti legittimi, ma raddoppia lo sforzo di forza bruta. Una password di lunghezza N accetta O (N) in hash (e digita), ma O (2 ** N) in forza bruta. Aggiungendo 12 bit di entropia a una password batte celando 12 bit di sale.

Out in the wild abbiamo una tabella utenti. Una tabella utenti è in genere

ID   |  username | salt | encrypted_password               | horridly_insecure_reset_key
===========================================================================
1    | user1     | foo  | 09b6d39aa22fcb8698687e1af09a3af9 | NULL
2    | user2     | bar  | 6c07c60f4b02c644ea1037575eb40005 | NULL
3    | user3     | baz  | 09b6d39aa22fcb8698687e1af09a3af9 | reset

Quindi un metodo di autenticazione sarà simile a

def authenticate(user, password)
    u = User.find(user: user)
    return u.encrypted_password == encrypt(password + u.salt)
end

Avendo un sale per utente garantisce che anche se la password per utente1 è nota, non è possibile determinare la password per user2 o user3 senza il loro sale.

Inoltre, assicurati di non riuscire a trovare il sale con una serie di password crittografate e provare alcune password crittografate.

In sostanza, in questo modo, ogni attacco contro un utente deve essere avviato da zero.

Anche se un utente malintenzionato ha un elenco di utenti e di sali, ha ancora bisogno di fare il cracking contro ogni singolo utente per vedere se hanno una corrispondenza di password. Se disponevi di un pool di sali o di un sale statico, potrei sapere che la password dell'utente1 è password e quindi trovare tutte le password crittografate corrispondenti. Quindi in questo modo almeno li rallenta un po 'di più.

Ora, quando guardiamo i sali, vogliamo ridurre il riutilizzo del sale. Due sali identici renderanno più facile agli attaccanti. Se due persone condividono lo stesso sale e la stessa password, la rottura di un utente interromperà l'altra.

Quindi diciamo che usiamo solo questi tre sali. E abbiamo 3000 utenti. ciò significa che 1000 persone hanno lo stesso sale. Se l'1% di quelli ha una password di "password", allora queste persone possono essere violate tutte allo stesso tempo. 10 account vengono hackerati contemporaneamente. Perché conosciamo i tre sali. È molto facile ottenere 30 persone attaccate contemporaneamente.

Ora se ogni sale è unico. E sappiamo che la password dell'utente1 è la password, che non ti aiuta. Hai ancora crackato solo 1 utente. Devi ancora eseguire "password + sale = password crittografata" per tutti gli altri 2999 utenti.

Una nota davvero importante.

La sicurezza attraverso l'oscurità non è sicurezza. Ciò non significa che devi pubblicare la tabella degli utenti su Google perché è sciocco. Ma quando si misura la sicurezza, si dovrebbe presumere che l'attaccante abbia tutto. Non puoi dire "Ma non conosceranno l'applicazione perché non hanno il codice sorgente". Perché potrebbero. Non significa dare via i tuoi sali, significa solo che non è una vera sicurezza. Supponiamo che abbiano il nome utente e il sale, quindi cercano di rendere più difficile per loro ottenere la password.

SUPER IMPORTANT NOTE

Il codice e la tabella utilizzati qui sono circa 9.000 volte troppo semplici per l'uso reale. La password non è crittografata, i sali sono troppo corti, il metodo è un po 'semplicistico, in breve fare qualcosa di simile in produzione non è qualcosa che dovrebbe essere considerato sicuro. Ho scelto queste cause per il semplice scopo di dimostrazione, non perché siano sicure.