Non conservare il sale è un cattivo consiglio.

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

Se non si memorizza il sale, allora , come hai detto, devi provare ogni singola combinazione di sale per convalidare la password. Se devi controllare ogni singola combinazione di sale, 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'aggressore sarà in grado di attaccare molti utenti contemporaneamente, il che farà risparmiare tempo all'attaccante.

In questo modo, si sconfigge quasi completamente lo scopo di utilizzare un sale.

Un sale "segreto" è noto come pepe.

Da Wikipedia:

Un pepe può essere aggiunto a una password in oltre a un valore di sale. Un peperone svolge un ruolo simile a un sale, tuttavia mentre un sale viene comunemente conservato insieme al valore che viene hash, affinché qualcosa possa essere definito come un pepe, dovrebbe soddisfare uno dei seguenti criteri che lo definiscono un "segreto" nascosto più accuratamente rispetto al valore del sale:

• Il pepe viene tenuto separato dal valore da sottoporre ad hashing
• Il pepe viene generato casualmente per ciascun valore da sottoporre ad hashing (entro un insieme limitato di valori) e non viene mai memorizzato. Quando i dati vengono testati rispetto a un valore hash per una corrispondenza, ciò viene fatto iterando attraverso l'insieme di valori validi per il peperone, e ognuno a sua volta viene aggiunto ai dati da testare (di solito aggiungendo un suffisso ai dati), prima che la funzione hash crittografica venga eseguita sul valore combinato.

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 di testo in chiaro.

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

Ricorda che un sale è una mitigazione efficace per gli hash precalcolati e fa un utente malintenzionato passa molto tempo ad attaccare una serie di hash. Tuttavia, se un solo hash è preoccupante e non devono essere utilizzati hash precalcolati, un salt non aumenta la durata dell'attacco. Un Pepper, tuttavia, costringe l'attaccante a utilizzare più tentativi per ogni password in chiaro, anche per un singolo hash.

In questo modo, un peperone è simile all ' allungamento dei tasti.

La maggior parte delle implementazioni preferisce l'estensione delle chiavi a peppers.

La mia osservazione personale è che la maggior parte delle implementazioni preferisce lo stretching delle chiavi ai peperoni. Non ho un riferimento per questo, quindi i lettori possono fornire riferimenti di supporto o dissenso nei commenti. Le persone tendono a preferire lo stretching chiave perché ha un costo delle prestazioni noto e previsto e un vantaggio in termini di sicurezza. Per calcolare l'ennesimo round di un hash, è necessario calcolare N hash. Con un peperoncino, tuttavia, è possibile calcolare solo il numero di tentativi previsto . Considera un pepe di 1 byte, l'attaccante avrebbe bisogno di 256 tentativi per indovinare tutte le possibili combinazioni, ma il valore atteso è 128 e l'aggressore potrebbe (in media 1/256 volte) indovinare il valore sul primo tentativo.

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

Key stretching è efficace perché puoi impostare il numero di round in base alla durata del calcolo di un hash prendere. Supponiamo che tu voglia che un singolo controllo richieda mezzo secondo sull'hardware corrente, devi solo aumentare i round finché non si verifica.

Con un peperone, poiché è necessario indovinare più valori per ciascuna password, la dimensione di un peperone deve essere inversamente correlata 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 è quello di utilizzare metodologie ben note e librerie testate. Dovresti utilizzare bcrypt o pbkdf2 con un salt unico e molti round. Questi algoritmi tendono ad avere implementazioni ben note in molti linguaggi e framework. Se ti capita di trovare una libreria ben nota e testata che include un peperone, oltre ai sali e allo stretching dei tasti, potrebbe valere la pena usarlo, ma il vantaggio aggiuntivo spesso supera i costi delle prestazioni.

Sfondo: dovresti utilizzare un hash della password lento. (cioè bcrypt) Con "lento" intendo costoso dal punto di vista computazionale, impiegando più di 100 ms (sul tuo hardware) ^{con protezione DoS *} per testare una singola password. Questo per aumentare la potenza di elaborazione necessaria (sull'hardware dell'attaccante) per trovare la password con la forza bruta, in caso di furto dell'hash.

Il sale univoco per utente è altamente raccomandato. (nel caso di bcrypt viene generato automaticamente) Salt dovrebbe essere altamente unico (cioè lungo & casuale), ma non segreto . L'uso di salt univoco significa che un utente malintenzionato dovrebbe eseguire un processo di forza bruta separato per ogni utente .

Se non ci fosse "sale", l'attaccante potrebbe utilizzare immediatamente un Rainbow Table e nessuna forza bruta.

Se utilizzi solo un "sale condiviso", un utente malintenzionato potrebbe decifrare le password per tutti gli utenti con un singolo bruto forza lavoro. (non veloce come un tavolo arcobaleno, ma comunque molto più semplice di un lavoro di forza bruta separato per ciascuno)

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

• i possibili sali dovrebbero essere pochissimi
• l'hash dovrebbe essere un bel po ' più veloce

Ciò vanificherebbe totalmente lo scopo di Salt, paralizzando gravemente il vantaggio di un hash lento. Questo è un grave errore di progettazione da parte del tuo professore. Fondamentalmente, sta implementando il proprio schema di archiviazione delle password, dove dovrebbe utilizzare l'algoritmo bcrypt ben controllato (o scrypt o PBKDF2) come doveva essere utilizzato .

_{* Come ha 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 ridurre la "lentezza" del tuo hash in soli 10 ms. Non è neanche lontanamente buono come 100 ms dal punto di vista di "hash rubato", ma comunque molto meglio di "microsecondi".}

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

Essere in grado di provare tutti i possibili valori di sale significa che devi avere una quantità di entropia molto BASSA nel sale, il che significa che è possibile un pre-calcolo tramite tabelle arcobaleno.

Puoi usare il sale in questo modo. Sarebbe una sorta di processo di stiramento dell'hashish. In genere si allunga un hash ripetendo l'algoritmo diverse migliaia di volte, il che rallenta gli aggressori e gli utenti di 1000 volte, ma gli utenti in genere non si preoccupano del rallentamento. Usare un salt in questo modo avrebbe l'effetto di eseguire un algoritmo di allungamento dell'hash dovendo ripeterlo per molti hash sconosciuti.

Tuttavia, questo è un approccio estremamente insolito. I modi tradizionali di eseguire il salting fanno ciò che i sali dovrebbero fare molto meglio (fare in modo che nessuno possa precalcolare una tabella delle password). I modi tradizionali di eseguire l'hash stretching fanno quello che si suppone dovrebbe fare molto meglio (fare in modo che gli hacker impieghino più tempo per calcolare le password). Usare un sale in questo modo equivale a schiacciarli insieme. Il risultato in un certo senso funziona, ma gli approcci più puliti fanno entrambe le soluzioni di gran lunga meglio del brutto miscuglio di tecniche.

Piuttosto che pensare al sale in termini di forzatura bruta, mi piace pensarlo in termini di affermazione che rende impossibile dire qualsiasi cosa su una password, inclusa la sua relazione con altre password, guardandola. Se il sistema non utilizza il salting, esaminare le password con hash di due utenti indicherebbe se le loro password reali corrispondevano. Se un sistema salta utilizzando solo il nome utente ma niente di casuale, specifico per l'ora o per il sistema, esaminare le password con hash di un utente su due macchine che utilizzano lo stesso approccio indicherebbe se le password dell'utente sulle due macchine corrispondevano. Se il sistema saltava utilizzando l'ID di sistema e il nome utente, ma niente di casuale o di tempo specifico, qualcuno con accesso a due diversi hash di password dallo stesso utente potrebbe dire se le password associate corrispondono.

L'effetto di il salting casuale serve a fare in modo che non sia probabile che due hash che utilizzano la stessa password corrispondano, anche se coinvolgono lo stesso utente sullo stesso sistema. Sebbene si possa ottenere un effetto simile senza conservare i sali se i tentativi di accesso dovessero forzarli brute, un tale approccio limiterebbe la lunghezza pratica del sale che si potrebbe usare e quindi aumenterebbe la probabilità che le password utilizzate in due contesti abbiano il stesso sale e quindi essere riconoscibile come corrispondenza.

Cosa ti dà la salatura? Gli aggressori 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 i loro hash rispetto a quei valori senza un salt.

Con un salt casuale che viene memorizzato insieme alla password, questo follemente metodo veloce non è più possibile. Ma se l'attaccante ha il sale oltre che l'hash, è ancora possibile utilizzare attacchi a dizionario per password deboli o forzatura bruta per quelle brevi. Tutto ciò che l'attaccante deve fare è usare il salt e provare password diverse usando un dizionario o un attacco a forza bruta.

Ora diciamo che quando la password viene modificata, la si hash con un valore casuale a 12 bit che non è conservato insieme al sale che è. Quindi ogni volta che controlli la password, devi provare tutti i 4096 valori. Sul mio computer ci vogliono circa 3,5 ms, quindi è possibile controllare 284 password ogni secondo. Un po 'più di CPU sul server quando qualcuno accede, ma per qualcuno che prova un dizionario o attacchi di forza bruta, hai semplicemente 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 del sale, che è configurato in modo indipendente ed è indipendente dalla dimensione del sale.

Supponiamo di avere sali a 32 bit. Potremmo scegliere di memorizzare solo 22 bit e forza bruta attraverso i restanti 10 quando ci autenticiamo. L'effetto di questo è come se più round fossero stati aggiunti alla funzione di hashing. Non così tanti da influire sull'autenticazione legittima, ma abbastanza da aumentare la difficoltà del cracking a forza bruta.

L'anno prossimo, le macchine diventeranno più veloci. Quindi esaminiamo il database delle password e eliminiamo un po 'da ogni sale: ora memorizziamo solo 21 bit e dobbiamo applicare la forza bruta fino a 11.

È come se raddoppiassimo la forza di hashing, ma senza il interruzione della sostituzione dell'algoritmo e del reinserimento da parte degli utenti delle proprie password (che è lasciata alla normale politica di scadenza delle password).

Questo approccio di "eliminazione progressiva del sale" potrebbe estendere la vita utile delle funzioni di hashing.

Tuttavia, questi tipi di approcci rallentano l'autenticazione legittima e l'attacco di forza bruta di un fattore uguale, quindi nella migliore delle ipotesi forniscono un livello di sicurezza minore. La nostra attenzione dovrebbe essere posta sui miglioramenti che aggiungono solo una quantità costante di tempo extra per un uso legittimo, moltiplicando la difficoltà di cracking. Ovviamente, un miglioramento che ha questa proprietà è l'aumento della 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 cracking della forza bruta. Una password di lunghezza N richiede O (N) per hash (e tipo), ma O (2 ** N) per forza bruta. Aggiungendo 12 bit di entropia a una password, occorrono 12 bit di sale.

In natura abbiamo una tabella degli utenti. Una tabella utenti è solitamente

  ID | nome utente | sale | password_crittografata | horridly_insecure_reset_key ================================================= ========================== 1 | utente1 | foo | 09b6d39aa22fcb8698687e1af09a3af9 | NULL2 | utente2 | bar | 6c07c60f4b02c644ea1037575eb40005 | NULL3 | utente3 | 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 salt per utente assicura che anche se la password per utente1 è nota non puoi capire la password per utente2 o user3 senza il loro sale.

Ti assicuri anche di non poter capire il sale disponendo di una serie di password crittografate e provando alcune password crittografate.

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

Anche se un utente malintenzionato ha un elenco di utenti e sali, deve comunque eseguire il cracking contro ogni utente per vedere se ha una password corrispondente. Se avessi un pool di sali o un sale statico, potrei sapere che la password dell'utente1 è password e quindi trovare tutte le password crittografate che corrispondono. Quindi in questo modo li rallenta almeno un po 'di più.

Ora, quando guardiamo ai 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 violazione di un utente interromperà l'altro.

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 questi ha una password di "password", allora quelle persone possono essere violate tutte allo stesso tempo. 10 account vengono violati contemporaneamente. Perché conosciamo i tre sali. È molto facile far attaccare 30 persone contemporaneamente.

Ora se ogni sale è unico. E sappiamo che la password di user1 è password, questo non ti serve a niente. Hai ancora solo crackato 1 utente. Devi ancora fare "does password + salt = encrypted password" per tutti gli altri 2999 utenti.

Una nota davvero importante.

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

NOTA SUPER IMPORTANTE

il codice e la tabella utilizzati qui sono circa 9.000 volte troppo semplici per un uso reale. Le password non sono criptate, i sali sono troppo corti, il metodo è un po 'semplicistico, insomma fare qualcosa del genere in produzione non è niente che debba essere considerato sicuro. Ho scelto questi perché lì semplici per il punto di dimostrazione, non perché sono sicuri.