Domanda:
Qualcuno non immagazzina i sali?
jazzpi
2016-07-15 14:33:58 UTC
view on stackexchange narkive permalink

Oggi in classe abbiamo parlato di hashing e salting delle password. Il nostro professore aveva una comprensione molto diversa del caso d'uso dei sali dal mio e ha detto che potresti non conservare affatto il sale e controllare ogni tentativo di accesso con tutti i sali possibili e autorizzare se uno corrisponde.

I Non vedo davvero alcun punto in questo dato che ora il mio servizio è molto più vulnerabile agli attacchi di forza bruta (invia una password, il server ne controlla molti), ma immagino che sia un po 'più sicuro per gli attacchi del dizionario puro contro la password con hash.

Quindi esiste un caso d'uso in cui le persone lo farebbero effettivamente?

Considerando la lunghezza del sale, ciò potrebbe comportare un'operazione di accesso molto lunga (poco pratica) se si devono provare tutti i valori di sale possibili.Ciò comporterà l'utilizzo di un intervallo di sale più piccolo per l'usabilità.Penso che ciò possa portare a una sicurezza peggiore rispetto all'utilizzo di un valore di sale valido e alla sua conservazione.Vedi anche https://stackoverflow.com/questions/184112/what-is-the-optimal-length-for-user-password-salt per una discussione sulla lunghezza del sale ideale, suggerendo tra 16 e 256 bit.
Decisamente.Abbiamo usato un salt a 12 bit, quindi solo 4096 tentativi, ma sal più lunghi non solo significano un tempo di accesso più lungo ma anche una sicurezza peggiore poiché il server cerca di autenticarti con 2 ^ n password invece di una sola.
Di cosa è professore questo ragazzo?Odontoiatria?
Nota che un buon hash crittografico è * lento * per impostazione predefinita, quindi l'intervallo di possibili valori di sale diventa troppo ampio molto presto.
Questo è il motivo per cui le persone dovrebbero imparare da Stack Exchange invece che dai professori.:-)
Se il tuo processo di accesso prevede una forzatura bruta ... il tuo ** lo stai facendo male **.L'unica differenza tra non usare il sale (idea terribile) e provare tutto il sale (idea terribile) è che uno sarà molto più costoso dal punto di vista computazionale (far incazzare i tuoi utenti).
Per quanto ne so, conservare un sale è una cattiva idea se il database si trova in un luogo umido - porta alla corrosione (vedi esempio di tabella corrosa in Second Life [qui] (https://slm-assets0.secondlife.com/assets/1123356/lightbox / 65b45b42685a44ca64e556f353d48e4e.jpg? 1277194741)).
Ho pensato che fosse su Cooking.SE quando l'ho visto nell'HNQ prima di notare la piccola icona "InfoSec": D
@oɔɯǝɹ: Una funzione hash crittografica generale dovrebbe essere _fast_ in base alla progettazione.Ecco perché le funzioni hash generali non dovrebbero essere utilizzate per l'hashing delle password!
@cat Haha, anche io.
Il tuo professore dovrebbe leggere: http://stackoverflow.com/questions/1645161/salt-generation-and-open-source-software/1645190#1645190
@CaffeineAddiction: "L'unica differenza tra non usare il sale (idea terribile) e provare tutto il sale (idea terribile) è che uno sarà molto più costoso dal punto di vista computazionale (far incazzare gli utenti)." In realtà, provare tutti i sali è anche peggio, perché ora (nel caso di jazzpi) hai 4096 volte più probabilità di incontrare una collisione di hash.Avere una password ultra sicura è irrilevante se lo stesso hash è generato da una parola del dizionario con un salt diverso.Dimentica la forza bruta basata su dati noti;questo rende effettivamente la tua applicazione meno sicura senza alcun dato noto.
raccomandazione leggermente fuori tema.Per prima cosa, conferma che ciò che hai scritto qui è effettivamente ciò che ha detto il professore.Se lo è, allora ti suggerisco di avvicinarti al preside della tua scuola e di chiedere un trasferimento / rimborso.Questa persona non è qualificata per insegnare in quella classe.
Il tuo professore ha semplicemente affermato che è possibile non conservare il sale ma non ha detto che è una buona idea?
@Shadur Probabilmente commedia.
È possibile che ci sia una certa confusione qui con l'uso di un peperone?- cioè un sale noto all'applicazione ma non memorizzato con le password nel database?
@Jedi, ragazzo Ho davvero impiegato molto tempo per ottenerlo.:) All'inizio l'ho completamente trascurato.
Il tuo professore sembra che non abbia idea di cosa stiano parlando.Sarebbe stato divertente se gli avessi chiesto cosa ne pensava di aggiungere un po 'di caffeina prima dell'hashing.
Nove risposte:
#1
+176
Gudradain
2016-07-15 17:29:34 UTC
view on stackexchange narkive permalink

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.

non aprirebbe anche la possibilità di più collisioni e molti più falsi positivi?
@CaffeineAddiction Forse.Ad esempio, potrebbe accadere quanto segue: hash (salt sbagliato + password sbagliata) = hash (salt giusto + password giusta).Ma non è un percorso pratico per attaccare poiché creare collisioni nella funzione hash è piuttosto difficile.
@CaffeineAddiction: non è probabile.Supponendo SHA-256 e un salt a 32 bit, le tue probabilità di una collisione con l'hash esistente (aka, 2nd preimage) sono passate da 2 ^ -256 a 2 ^ -224.Più grande, ma ancora infinitesimale nel grande schema delle cose.
@David come?le funzioni hash possono essere modellate come oracoli casuali in cui due input qualsiasi portano a output indipendenti, quindi non penso che la probabilità cambi affatto (a meno che non si riempia l'input a una lunghezza fissa)
@Thomas: sì, ma se il sistema prova 2 ^ 32 sali, la probabilità di ogni collisione rimane la stessa, ma la probabilità totale di * qualsiasi * collisione dovrebbe essere ridotta di 2 ^ 32.
@Thomas Hai un hash generato da " ".Ogni volta che l'utente inserisce la propria password, il server controlla la password combinata con i 2 ^ 32 possibili sali.Se per esempio stavi usando un hash a 32 bit, ciò significherebbe che la tua vera password funzionerebbe, ma ci sarebbe anche un'eccellente possibilità che l'hash corrisponda a uno dei 2 ^ 32 provati dal server se hai inserito _any_ password.
@David Hai dimenticato la lezione del paradosso del compleanno.I processi casuali entrano in collisione molto più spesso di così.Le probabilità in realtà vanno da 2 ^ -256 a 2 ^ -193.E questo con un singolo utente.Continua a salire abbastanza velocemente man mano che aggiungi utenti.Finisce comunque per essere abbastanza piccolo, però.
Ricorda, anche i falsi positivi sono vittorie per l'attaccante.Se trovano una password diversa che funziona con un sale diverso, possono usarla.Poiché tutti i sali sono stati provati, possono comunque essere autenticati.
@AaronDufour, il paradosso del compleanno si applica solo quando stai cercando collisioni nel set di dati.Questo è davvero più un attacco preimmagine: stanno cercando di abbinare un valore fisso.
#2
+126
amccormack
2016-07-15 19:14:41 UTC
view on stackexchange narkive permalink

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.

non aprirebbe anche la possibilità di più collisioni e molti più falsi positivi?
@CaffeineAddiction Devo ammettere che non conosco abbastanza bene la matematica alla base di questi algoritmi di hashing per dimostrare che l'uso di un peperoncino aumenterebbe o diminuirà le collisioni.È una buona domanda e potresti ottenere una risposta migliore su [crypto.se] (http://crypto.stackexchange.com/).Il mio pensiero è che probabilmente non aumenterebbe le collisioni a un importo significativo se 1) usassi un algoritmo di hashing sufficientemente grande come SHA-256 o superiore e 2) usassi una dimensione del pepe più piccola (meno di 2 byte).
I peperoni sono ancora conservati, però (non in bella vista, ma conservati)
@WoJ Il secondo punto nell'articolo di wikipedia sottolinea che il peperone potrebbe non essere conservato.Ho tentato di trovare un riferimento migliore rispetto a wikipedia che descrive un peperone ma non sono riuscito a trovarne uno.Se sei a conoscenza di un riferimento che suggerisce di conservare i peperoni, sarei felice di esaminarlo.
@amccormack: Non ho letto l'articolo di Wikipedia, mi dispiace.Detto questo, non ho mai visto una simile implementazione di un peperone (avendone assistito a una quantità limitata).Sarebbe un incubo verificare se l'algoritmo di hashing è corretto (lento, multi-round).
@Woj, Sono d'accordo, sarebbe un incubo da testare e probabilmente farebbe sì che l'implementatore riduca il numero di round per qualsiasi key stretching.Memorizzare il sale (o calcolarlo in modo deterministico) allevierebbe gli effetti negativi sullo stiramento delle chiavi e potrebbe mitigare alcuni casi in cui vengono trapelati solo i valori di hash + sale.
Come ho sempre sentito dire "pepe" è un sale memorizzato per applicazione nel codice, piuttosto che per utente nel DB.
Vale la pena notare che un peperone è ancora memorizzato, ma non necessariamente nel database.L'OP sembra parlare di un caso in cui il sale non è affatto memorizzato e l'applicazione essenzialmente forza bruta il sale ogni volta che viene tentato un accesso ...
@Ajedi32 Grazie per averlo sottolineato.Anche altri lo hanno fatto notare, ma non riesco a trovare una fonte definitiva che faccia questa affermazione.Se potessi indicarmene uno, lo apprezzerei.
@amccormack Non sono sicuro di una fonte definitiva, ma praticamente ogni articolo o post che ho letto sui peperoni sembra condividere questa definizione.http://security.stackexchange.com/q/3272/29865 http://stackoverflow.com/q/16891729/1157054 https://blog.filippo.io/salt-and-pepper/ E oltre a ciò, non archiviazioneil pepe sarebbe abbastanza inutile - sarebbe fondamentalmente solo un modo davvero hacky per aumentare il fattore di lavoro della tua funzione hash.
I riferimenti alla definizione della parola "pepe" sono discussi su crypto.SE: [Esiste una definizione autorevole del termine crittografico "pepe"?] (Https://crypto.stackexchange.com/q/24698/23581), [Definizione di "pepe" nelle funzioni hash] (https://crypto.stackexchange.com/q/20578/23581).Apprezzo la risposta data in quest'ultimo, dove il pepe è per lo più definito come un segreto supplementare sconosciuto all'attaccante, e non ci si preoccuperebbe se questo segreto fosse codificato / caculato / ecc.fintanto che rimane sconosciuto all'aggressore.
@Ajedi32, quando ho posto questa domanda, il termine "pepe" non era affatto ampiamente utilizzato, ma non ho inventato il termine, l'ho letto da qualche parte sulla carta alcuni anni prima.
Pensavo che un pepe fosse un sale per applicazione memorizzato al di fuori del database.
Una cosa interessante per i peperoni è che il test dei valori per un peperone potrebbe essere fatto in parallelo, ma l'applicazione di più giri di un hash deve essere eseguita in sequenza.
dovrebbe anche menzionare scrypt (https://en.wikipedia.org/wiki/Scrypt) come alternativa ragionevole.
* "può valere la pena usarlo, ma il vantaggio aggiuntivo spesso supera i costi delle prestazioni." * La parola ** "ma" ** è un errore di battitura in quella frase o sto fraintendendo qualcosa?Sembra che dovrebbe dire "perché".
#3
+21
Bryan Field
2016-07-15 18:37:58 UTC
view on stackexchange narkive permalink

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".

"Se non ci fosse il sale, l'attaccante potrebbe forzare l'hash per tutti gli utenti in un unico lavoro di forza bruta. (Consente di risparmiare molto tempo in questo modo)" Oppure selezionare dal database per ogni utente con l'hash MD5 `5f4dcc3b5aa765d61d8327deb882cf99`, che corrisponde alla password "password".È anche un modo per proteggere gli utenti da se stessi.
Non utilizzare mai MD5 per memorizzare le password!Usa invece un hash lento.Ma sì, capisco il tuo punto.Ho aggiornato la risposta per fare riferimento alle Rainbow Tables a cui fai riferimento.
Vero.Nel mondo reale, dovresti utilizzare una libreria di hashing della password adeguata in qualsiasi lingua con cui stai lavorando, che normalmente include il sale nella stringa di hash e protegge dagli attacchi temporali, rendendo discutibile l'intera discussione.Ma sì, MD5 non è per le password.
#4
+16
Steve Sether
2016-07-15 18:37:46 UTC
view on stackexchange narkive permalink

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.

#5
+3
Cort Ammon
2016-07-16 03:07:46 UTC
view on stackexchange narkive permalink

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.

#6
+2
supercat
2016-07-15 20:52:19 UTC
view on stackexchange narkive permalink

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.

#7
+1
Jason Goemaat
2016-07-18 07:24:21 UTC
view on stackexchange narkive permalink

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.

Non renderesti il loro lavoro molto più semplice se * non * avessero hashish e sale?Da ora il server controlla 4096 valori se ne trasmetto solo uno, dando così molti più falsi positivi.Questo è stato il ragionamento usato dal mio prof ma non mi sembra molto utile, quindi mi piacerebbe vedere qualcuno che utilizza effettivamente questo approccio nel codice del mondo reale.
Se non hanno l'hash, non ha senso, vero?La salatura protegge dalle persone che hanno gli hash.Se l'utilizzo di un numero a 12 bit diventa popolare, gli aggressori potrebbero creare database con hash precalcolati per ciascuno di questi numeri e password comuni / non comuni per semplificare il loro lavoro.Anche se generi 4096 sali casuali e li riutilizzi invece di un semplice numero a 12 bit, li lascerebbe concentrarsi su un valore di sale, diciamo, e forse comprometterebbe molti utenti se ne hai milioni.
Sì, la salatura protegge dalle persone che hanno gli hash.Normalmente, non ti rende * più vulnerabile * contro le persone che non hanno gli hash, ma lo fa con questa variante.
Come ti rende * più * vulnerabile?
Perché se invii una password al server, è necessario controllarla con tutti i 4096 possibili sali, dandoti così un potenziale molto più alto di falsi positivi.
Sembra che tu stia parlando di una collisione nell'algoritmo di hashing con il tentativo di password casuali.Se hai un hash a 256 bit, quei 4096 tentativi sono quasi privi di significato quando si cerca di produrre una collisione.Il motivo per cui puoi usare la forza bruta _quando hai l'hash_ è perché puoi eseguire milioni o miliardi di controlli ogni secondo sui tuoi computer locali.Se il tuo sito consente alle persone di provare milioni di password senza bloccarle, (A) stai sbagliando e (B) devono avere una connessione incredibilmente veloce ai tuoi server e (C) dovresti notare che le CPU del tuo server sonoancorato.
#8
  0
Kaz
2016-07-16 04:08:03 UTC
view on stackexchange narkive permalink

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.

"Questo approccio di" eliminazione progressiva del sale "potrebbe prolungare la vita utile delle funzioni di hashing".Esistono funzioni di hashing con dimensioni di hash configurabili (un esempio è Keccak), e usarle come primitiva sottostante di un KDF mi sembra un'idea molto migliore.È ancora possibile utilizzare questa tecnica per estendere la vita utile degli hash delle password non aggiornati (con un aggiornamento, il nuovo hash avrebbe la dimensione hash configurata più di recente), ma è anche discutibile se sia una buona idea.Vedrai la semplice password dell'utente a ogni accesso (tranne ad esempio SRP), in modo da poter aggiornare l'hash.
@Rhymoid È necessaria l'autorizzazione di scrittura per la voce del database delle password per aggiornare l'hash al momento dell'autenticazione (quando la password è nota brevemente al sistema).Ad esempio, su Unix classico, tutti possono leggere `/ etc / passwd` e usare gli hash per l'autenticazione, ma solo un'utility` setuid` come `/ bin / passwd` potrebbe aggiornarli.(In generale, possiamo immaginare un sistema in cui l'aggiornamento di una voce del database di autenticazione è un privilegio separato dall'utilizzo per l'autenticazione, anche se entrambi sono privilegi speciali concessi solo a determinati programmi.)
#9
  0
coteyr
2016-07-21 18:54:13 UTC
view on stackexchange narkive permalink

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.



Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...