Domanda:
Il "protocollo di Dave" non va bene se trapelano solo il database e non il codice?
Rick
2019-07-01 13:49:09 UTC
view on stackexchange narkive permalink

Ho letto "La sicurezza della password fatta in casa dal mio sviluppatore è giusta o sbagliata, e perché?", ma ho ancora una domanda nella mia mente:

Anche se qualcuno usa un cattivo algoritmo di sicurezza fatto in casa proprio come Dave, un utente malintenzionato non può ottenere la vera password se l'aggressore compromette solo il database, non il server. La risposta di Mark Burnett alla domanda di Dave sembra confermare la mia ipotesi.

Di nuovo, prendi il codice di Dave come esempio. Dave usa funzioni hash insicure / veloci, md5 e sha1, quindi sì, puoi decifrare facilmente la sua password (ottenere il testo normale) dal database. Ma non puoi ancora ottenere la vera password se il suo server non è compromesso.

@Anders In realtà mi sento abbastanza confuso quando leggo alcune domande sulla sicurezza delle password altamente votate.Perché quando si parla di "compromesso" o "crackato", non so se si parla di server e database compromessi, o semplicemente del database.
"sì, puoi decifrare facilmente la sua password (ottenere il testo normale) dal database. Ma non puoi ancora ottenere la vera password se il suo server non è compromesso". Non capisco questa riga. Se riesci a decifrare la sua password come farenon hai la vera password?
@VipulNair Perché come fa Dave, non memorizza direttamente l'hash della password, non sai quale conversione usa sul server.
Otto risposte:
#1
+69
Conor Mancone
2019-07-01 14:51:46 UTC
view on stackexchange narkive permalink

Sì, ma ..

Per renderlo chiaro e chiaro ... Stiamo parlando di una compromissione solo del database quando un utente malintenzionato ha accesso al database ma non al codice sorgente dell'applicazione. In tal caso, l'attaccante otterrà gli hash delle password ma non sarà in grado di decifrarli e ottenere le password originali a causa dell'algoritmo personalizzato di Dave. Quindi, in caso di violazione del solo database, sì, l'algoritmo della password di Dave proteggerà le password più che se avesse usato MD5 o SHA1.

Tuttavia Questa è solo una possibile strada per perdite di sistema. C'è un fatto fondamentale che distrugge la "matematica" che fa sembrare ragionevole l'algoritmo homebrew di Dave.

La metà di tutte le violazioni inizia internamente.

(fonti 1 2 3) Il che è un fatto molto che fa riflettere, una volta che lo lasci capire. Della metà delle violazioni causate dai dipendenti, metà sono accidentali e metà sono intenzionali . L'algoritmo di Dave può essere utile se tutto ciò di cui sei preoccupato è una perdita del solo database. Se questo è tutto ciò di cui sei preoccupato, allora il modello di minaccia da cui ti stai proteggendo nella tua testa è sbagliato.

Per fare solo un esempio, gli sviluppatori per definizione hanno accesso al codice sorgente dell'applicazione. Pertanto, se uno sviluppatore ottiene l'accesso in sola lettura al database di produzione, ora ha tutto ciò di cui ha bisogno per decifrare facilmente le password. L'algoritmo personalizzato di Dave è ora inutile, perché si basa su hash vecchi e facili da decifrare.

Tuttavia, se Dave avesse usato un moderno algoritmo di hashing delle password e avesse usato sia sale che pepe, lo sviluppatore che ha guadagnato l'accesso a un dump solo del database non avrebbe assolutamente nulla di utile.

Questo è solo un esempio casuale, ma il punto generale è semplice: ci sono molte fughe di dati che si verificano nel mondo reale in cui l'hashing corretto avrebbe fermato il danno effettivo quando l'algoritmo di Dave non poteva.

In sintesi

Si tratta di difesa in profondità. È facile creare una misura di sicurezza in grado di proteggere da un particolare tipo di attacco (l'algoritmo di Dave è un leggero miglioramento rispetto a MD5 per la protezione dalle fughe di soli database). Tuttavia, ciò non rende sicuro un sistema. Molte violazioni del mondo reale sono piuttosto complicate, sfruttando le debolezze in più punti di un sistema per fare finalmente dei danni reali. Qualsiasi misura di sicurezza che inizi con il presupposto "Questo è l'unico vettore di attacco di cui devo preoccuparmi" (che è quello che ha fatto Dave) andrà a finire pericolosamente male.

I commenti non sono per discussioni estese;questa conversazione è stata [spostata in chat] (https://chat.stackexchange.com/rooms/95782/discussion-on-answer-by-conor-mancone-isnt-daves-protocol-good-if-only-the-d).
#2
+32
Fund Monica's Lawsuit
2019-07-01 22:48:20 UTC
view on stackexchange narkive permalink

Questo non risponde specificamente alla domanda sul protocollo di Dave, ma volevo affrontare la domanda più generale, per i Daves di tutto il mondo che stanno scrivendo i propri hash. Ci sono alcune cose, Daves, che devi capire:

  1. Non sei un crittografo . Non è un lieve contro di te; Non lo sono neanche io. Ma anche se fossi un crittografo, dovresti essere il migliore al mondo intero per essere certo che il tuo algoritmo non avesse difetti che potrebbero compromettere la sicurezza, perché anche gli esperti fanno casino su a lotto (tutte e quattro le parole sono collegamenti separati). Tra le altre cose, i potenziali difetti negli hash includono:
    • Reversibilità accidentale. Forse non lo intendevi, ma hai messo troppe informazioni nell '"hash", e ora può essere banalmente invertito, anche senza forza bruta. Per un esempio di algoritmo "complesso" che è comunque abbastanza facile da invertire, guarda i generatori congruenti lineari.
    • Complessità insufficiente su CPU, GPU, ASIC, ecc. Questo è sorprendentemente difficile da fare; c'è una ragione per cui ci sono solo tre librerie per eseguire l'hashing delle password e sono tutte basate sulle stesse idee. A meno che tu non abbia intimamente familiarità con il funzionamento di GPU e ASIC, molto probabilmente costruirai qualcosa che può essere eseguito molto più velocemente sulle GPU rispetto alle CPU, annullando immediatamente qualsiasi altra protezione che hai.
    • Troppa complessità nel punto in cui lo stai eseguendo, combinata con l'ultimo punto. È molto facile indicare i test delle prestazioni e dire: "Guarda, mi ci vogliono 30 secondi per fare 30 hash, fantastico!" Tranne che, ancora una volta, non sei un crittografo o uno sviluppatore di GPU, quindi non ti rendi conto che le tue complesse aggiunte e moltiplicazioni possono effettivamente essere replicate abbastanza facilmente sulle GPU, quindi possono crackare 30 milioni di hash in 30 secondi, per tutto il tempo DoSing il tuo servizio provando ad accedere più di una volta al secondo.
    • Uniformità insufficiente. L'output di una funzione di hash della password teoricamente perfetto è indistinguibile da un vero generatore di numeri casuali, quando alimentato con input variabili. In pratica, non possiamo arrivarci, ma possiamo avvicinarci incredibilmente . Il tuo algoritmo potrebbe non farlo. E no, "guardare" casuale non significa che sia abbastanza vicino; se sei abbastanza inesperto da scrivere la tua crittografia segreta per una sicurezza "migliore", sei abbastanza inesperto da non sapere come individuare la vera casualità.
    • Anche se costruisci il tuo algoritmo interamente da buono , solide primitive crittografiche, puoi ancora metterle insieme in modo sbagliato.
  2. Non sei un programmatore di sicurezza informatica . Probabilmente c'è una parola migliore per questo, ma il punto è che non sei specializzato nella scrittura di codice che implementa correttamente algoritmi, anche quelli come il tuo. Per un brevissimo elenco di possibili problemi che potrebbero essere visibili dal solo database, ognuno dei quali è collegato al primo risultato di Google per "[item] attack":

E tutto ciò è solo pensare esclusivamente agli attacchi offline ai database, dove il pensiero è fatto da uno studente universitario che non si sta nemmeno laureando in sicurezza informatica . Ti garantisco che mi sono perso un bel po 'di cose. Ho completamente ignorato tutti gli altri vettori di attacco per MITM, client dannosi, ecc. Ho anche omesso di menzionare ogni errore che potrebbe verificarsi anche se si utilizza un prodotto standard; Considera un esercizio per il lettore capire come potresti usare anche una buona crittografia sbagliata. Infine, ho completamente omesso la classe comune di errori in cui lo sviluppatore utilizza la crittografia dove dovrebbe utilizzare gli hash , che vedo occasionalmente.

Quindi, in sintesi, Dave, ogni volta che pensi di avere la migliore idea per un hash interno segreto da utilizzare per il tuo codice di produzione e non utilizzare uno standard, non -prodotto da scaffale, pubblico, accuratamente testato, ricorda questo:

Non lo fai.

Usa semplicemente bcrypt. (O Argon2)

(Come nota a margine, se stai solo costruendo un algoritmo per divertimento e / o autoeducazione, sentiti libero di ignorare tutto questo. il tuo algoritmo per proteggere le password in produzione è pericoloso perché creerai un algoritmo debole che offre poca o nessuna protezione. Costruisci il tuo algoritmo per vedere se puoi infrangerlo è un ottimo modo per passare il tempo, stimolare la mente e forse anche imparare un po 'di crittografia.)

Ho alcuni orrori progettati specificamente per far preoccupare un progettista di schede ASIC, ma ho paura di usarli perché l'allocazione di 5600k di RAM per controllo della password apre un DOS facile contro il mio server.
"Usa solo Bcrypt" - no, usa Argon2.È stato il gold standard per un bel po 'di tempo ormai.
@Polynomial Nel post originale, Dave stava cercando di sostituire Bcrypt, motivo per cui la versione originale di questo post faceva riferimento solo a Bcrypt.Buon punto;Ho aggiunto Argon2.
Se indentate la riga che inizia con "E tutto ciò che riguarda esclusivamente gli attacchi offline ai database ..." con 4 spazi, verrà renderizzata come parte della sezione numerata sopra di essa, allineandola a quel contenuto.
@jpmc26 Sì, ma stavo cercando di applicarlo a _both_ sezioni.Tutti i problemi che ho menzionato nel primo bit potrebbero lasciare il database, da solo, crackabile, direttamente o in altro modo.Se lo espandessi a tutto ciò che potrebbe portare a un attacco, questo elenco sarebbe _molto_ più lungo ...
@Polynomial L'articolo di wikipedia su Argon2 è piuttosto breve e, a parte il riferimento alla "Password Hashing Competition", che sembra non sia stato fatto da nessuna grande organizzazione rispettabile.Non sto dicendo che ciò lo rende cattivo, ma c'è qualche analisi dettagliata di noti esperti che potrei guardare?(Anche una domanda su questo stesso sito [non la menziona in modo prominente] (https://security.stackexchange.com/questions/211/how-to-securely-hash-passwords). Difficile tenersi aggiornati con ilalgoritmi in continua evoluzione e decidere cosa è sufficientemente testato per essere utilizzato ..
@Voo Questa domanda è del 2010. Escludendo la modifica automatica della community per correggere i collegamenti, l'ultima modifica è del 2015 e non sembra essere stata una modifica del contenuto, ma solo grammaticale.Se guardi la cronologia delle modifiche, vedrai che le informazioni sono davvero del 2013. Un _lot_ può cambiare in sei anni, specialmente nei campi digitali, specialmente nella sicurezza informatica.Ho scelto intenzionalmente una domanda più recente, perché qualcosa del 2018 è meno obsoleto di qualcosa del 2013, e _quella_ domanda chiama esplicitamente Argon2 la scelta preferita.
@Nic In qualche modo ha perso il tuo link nella risposta, do la colpa al mio telefono.
@Voo Argon2 è stato ampiamente controllato sia dagli accademici che dalla comunità della sicurezza.Sebbene alcuni attacchi di riduzione dei costi siano stati scoperti in una delle modalità, non sminuiscono in alcun modo la superiorità complessiva di Argon2 su bcrypt.Lo consiglio vivamente per nuovi progetti (e aggiornamenti di progettazione), a meno che non ti trovi in una situazione in cui un'implementazione di scrypt è disponibile in modo nativo nella tua piattaforma / framework di scelta e Argon2 non lo è.In genere non consiglierei bcrypt per i nuovi progetti, ad eccezione dei dispositivi IoT con poca memoria.
@Voo Dì solo che è stato compromesso perché utilizza l'algoritmo di Dave per memorizzare la tua password :)
@Polynomial Sono abbastanza sicuro che se stai cercando di proteggere un dispositivo IoT con poca memoria, non utilizzerai affatto un database hash delle password.Costruirai la funzionalità della password nell'app di controllo, utilizzando alcune funzioni di derivazione della chiave e quindi crittografia basata su chiave standard.O almeno, è così che lo farei ...
@NicHartley Non tutti i dispositivi interagiscono con i sistemi esterni.Esistono ancora casi comuni nel firmware in cui è necessario eseguire la derivazione della chiave da una password o archiviare una password localmente in modo sicuro.
@Polynomial ... Non sono sicuro di aver capito cosa intendi.Puoi fornire qualche esempio di dispositivi IoT che interagiscono solo, anche indirettamente, con altri dispositivi a bassissimo consumo?Lo chiedo perché anche l'automazione industriale di solito ha una sorta di computer "standard" centrale, che potrebbe facilmente eseguire il key-stretching in un modo molto più resistente alla forza bruta rispetto a qualsiasi dispositivo incorporato.
@NicHartley Non sono necessariamente IoT, possono essere solo hardware normale.Vengono in mente dispositivi standalone come i gestori di password hardware.Ho anche visto dispositivi IoT in cui una password di accesso remoto è archiviata localmente come hash e le richieste in arrivo prendono quella password e ne verificano la validità: PBKDF2 va bene qui, Argon2 o scrypt non è fattibile.
@Polynomial Ohh, capisco cosa intendi - giusto, questo è un buon punto.Anche se in quel caso, si spera che chiunque lo realizzi si renderà conto che, indipendentemente dalla funzione che usano, un PC può immediatamente decifrarlo molte volte più velocemente, solo in virtù del fatto che non è un dispositivo a basso consumo ... Per quanto riguarda i dispositivi IoT "appropriati"che richiede una password, sono sicuro che è _fatto_, il punto è solo che _non dovrebbe essere_.Ti do più credito di quanto do alla maggior parte degli sviluppatori IoT.Anche nei dispositivi embedded non IoT, dovrebbe essere fatto uno sforzo per evitare l'uso di password.
#3
+10
Anders
2019-07-01 15:16:29 UTC
view on stackexchange narkive permalink

In caso di violazione del database e non del codice sorgente, Dave potrebbe aver migliorato le cose rispetto al semplice SHA1 . Ma ...

  1. È probabile che anche il codice sorgente sia trapelato, come Conor Mancone spiega.

  2. L'homebrew potrebbe rovinare l'hash, rendendolo ancora meno sicuro di un semplice SHA1. Dio sa come lo strano aggeggio di Daves interagisce con le parti interne dell'algoritmo di hashing. Se non altro, Dave ha creato un piccolo inferno per la manutenzione per coloro che vengono dopo di lui, e grandi disastri non sono mai buoni per la sicurezza.

  3. Dà un falso senso di sicurezza. Se Dave non fosse stato così orgoglioso della sua brillante soluzione, avrebbe potuto dedicare del tempo a documentarsi su come eseguire correttamente l'hashing delle password. Dalla domanda, è chiaro che Dave pensa che quello che ha fatto sia meglio che dire bcrypt. Non lo è.

  4. La piccola protezione extra fornita dall'algoritmo homebrew avrebbe potuto essere ottenuta con un peperoncino invece. È meglio di un algoritmo homebrew in ogni modo possibile.

Quindi sì, un homebrew potrebbe essere migliore di SHA1 in alcune circostanze molto specifiche. Se è meglio in media è una domanda aperta, ma la risposta non ha molta importanza. Il punto è che è terribile rispetto a un vero algoritmo di hashing delle password, ed è esattamente ciò che la birra artigianale ha impedito a Dave di implementare.

Per farla breve, Dave ha fatto un casino.

Direi che se aggiungere un peperone significa aggiungere il pepe direttamente alla password e poi cancellarlo.È inutile e il cattivo algoritmo di Dave vince in questa situazione.
@Rick Perché sarebbe inutile?
Inoltre, non capisco perché alcune risposte altamente votate affermino che aggiungere un peperoncino direttamente alla password e all'hash può essere più sicuro.Puoi semplicemente aumentare la lunghezza del sale se ti limiti a concatenare il pepe e la password, aggiungendola o anteponendola.Penso che un peperone dovrebbe essere usato come chiave segreta, ad esempio, usato insieme a "HMAC".Ma come ho commentato sotto la risposta di @Conor Mancone, sarebbe sufficiente modificare un po '.
@Rick Sì, un peperone dovrebbe essere segreto e non archiviato nel database.Quindi protegge esattamente dalla situazione che descrivi: database trapelato, codice non trapelato.Questo è lo scopo del pepe, quindi non puoi paragonarlo all'aumento della lunghezza del sale.
@Rick Non prendo alcuna posizione su come mescolare il pepe - questo è al di fuori dello scopo di questa domanda.
@Rick La domanda rimane: perché un peperone dovrebbe essere inutile?
Cerchiamo di [continuare questa discussione in chat] (https://chat.stackexchange.com/rooms/95578/discussion-between-rick-and-anders).
#4
+7
atk
2019-07-02 12:14:09 UTC
view on stackexchange narkive permalink

TLDR: la crittografia insicura non è nemmeno sicura se non riesci a vedere il valore crittografato.

Gli altri post spiegano bene molte delle ragioni per cui non dovresti scrivere la tua crittografia, in un ambiente in cui l'attaccante può vedere il valore crittografato, ma perde qualcosa di veramente importante: non dovresti nemmeno scrivere la tua crittografia quando l'aggressore non può vedere il messaggio crittografato.

C'è questa cosa chiamata "canale laterale". I canali secondari sono (di solito 1 ) cose non intenzionali che perdono informazioni su ciò che sta facendo la tua applicazione. Ad esempio, forse sono necessari più cicli della CPU - e quindi più tempo - per confrontare una password parzialmente corretta con il valore 2 "cifrato". Ciò consentirebbe a un utente malintenzionato di accelerare un attacco di forza bruta per apprendere lentamente la password corretta.

Facciamo un esempio ingenuo. Facciamo finta che ci voglia 1 secondo per testare un singolo carattere della password inviata rispetto al valore memorizzato nel database. Immagina che la password corretta sia lunga 8 caratteri e che una password non valida venga rifiutata al primo risultato errato. L'algoritmo potrebbe avere un aspetto simile a:

  booleano encrypt_password (stringa password) {if (non isascii (password)) {return false; } // ERRORE! risultato stringa; foreach (char c: password) {result + = daves_magic_that_takes_1s (c)} return true;} boolean is_correct_password (input, pw_from_db) {if (input.length! = pw_from_db.length) {return false} foreach (char c_in, c_db: input, password) {c_in = daves_magic_that_takes_1s (c_in) if (c_in! = c_db) {return false}} return true; // password valida!}  

Ora, immaginiamo che la password valida sia "password" e che l'aggressore provi a inserire "a". Questo non riesce, perché le password sono di lunghezza errata. L'aggressore può provare a caso varie password. Ogni password errata più lunga o più corta di "password" richiede meno di un secondo per l'elaborazione. Diciamo che presto provano "12345678". "12345678" ha la stessa lunghezza di "password" quindi richiede un secondo per l'elaborazione. Il tempismo è diverso e l'attaccante se ne accorge. Tentano più volte di verificare ed è coerente.

L'aggressore ora prova diverse password di 8 caratteri. Tutti impiegano 1 secondo. L'aggressore ha scoperto un canale laterale che gli dice che la password valida è probabilmente lunga 8 caratteri. Ora devono determinare quale password di 8 caratteri è quella giusta.

L'aggressore inizia a provare casualmente password di 8 caratteri. Alla fine, provano "p2345678" e notano che ci vogliono 2 secondi per completare. Testano un sacco e scoprono che tutti i tentativi che iniziano con "p" richiedono 2 secondi per essere completati. L'aggressore ipotizza che l'algoritmo abbia un canale laterale che gli dice quanti caratteri ha corretti.

Ora, invece di dover tentare tutte le 96 ^ 8 password per forzare quella valida, l'attaccante ha solo per provare 96 * 8 password 3 . A seconda di quante password possono essere testate in parallelo, probabilmente possono forzare con successo la password in un tempo molto ragionevole. Questo è fantastico per l'attaccante! Ed è terribile per la sicurezza del tuo sistema. 4

Come proteggiamo dai canali secondari di temporizzazione? Garantiamo che tutte le operazioni in cui la tempistica potrebbe trapelare informazioni sensibili DEVONO sempre richiedere lo stesso tempo per essere eseguite.

Questo potrebbe sembrare un esempio molto semplice. È successo in natura. La ricerca di NVD per "canale laterale di temporizzazione" ti consentirà di ottenere molte vulnerabilità del mondo reale che producono tutte lo stesso tipo di risultati, consentendo a un utente malintenzionato di apprendere informazioni segrete a cui non è autorizzato. Per definizione, se tutte le operazioni richiedono la stessa quantità di tempo indipendentemente dall'input, la quantità di tempo impiegata da qualcosa non ti dice nulla sull'input.

Nel mondo reale, i canali laterali sono incredibilmente facile da introdurre. Dave probabilmente non ne ha nemmeno sentito parlare, ed è probabilmente un buon ingegnere interessato alle prestazioni del suo sistema, che in realtà è un anti-pattern per la protezione dai canali laterali. L'algoritmo di Dave può benissimo avere canali secondari sia ovvi che sottili che non scoprirà mai, ma che i ricercatori e gli aggressori sanno cercare e possono scrivere abbastanza facilmente test automatici per rilevarli. 5

Quindi, solo perché non puoi vedere la crittografia non significa che non puoi vedere gli effetti collaterali della crittografia cattiva e utilizzare questi effetti collaterali per apprendere il segreto protetto.


Endnotes

1: Beh, se sei un agente dell'intelligence o un bravo giornalista di giornali, probabilmente hai intenzionalmente organizzato canali laterali in modo da poter comunicare con i tuoi agenti / fonti senza che "il nemico" lo sappia. Allo stesso modo, se sei subdolo, potresti creare un protocollo crittografico con un canale laterale al suo interno con l'intenzione di far trapelare informazioni segrete.

2: poiché possiamo e dobbiamo sempre presumo che la crittografia personalizzata non sia sicura (per i motivi che altri hanno menzionato in questo thread e altro), probabilmente non dovremmo chiamare l'uso di algoritmi di crittografia personalizzati "crittografia" o "decrittografia" ... forse "crittografia insicura" o "decrittografia interrotta "...

3: Ignoro gli attacchi di forza bruta che riescono, in media, quando l'attaccante ha provato il 50% + 1 password, per semplicità di descrizione. Mi sto concentrando sui canali laterali, non sugli attacchi di forza bruta. Sorvolo anche sui calcoli di un attacco di forza bruta, poiché è anche tangenziale all'argomento principale; un po 'di Google-Fu per conto del lettore dovrebbe individuare molte risorse che vanno in profondità nei dettagli.

4: "1 secondo è troppo lento", giusto? Nessun sistema del mondo reale potrebbe essere controllato per i canali secondari di temporizzazione del mondo reale su Internet, giusto? Sbagliato. Non ho i riferimenti a portata di mano, ma ci sono state ricerche per un certo numero di anni che hanno dimostrato che è possibile testare statisticamente i tempi nell'ordine dei millisecondi su transazioni HTTP.

5 In effetti, sarei pronto a scommettere che ci sono framework o strumenti esistenti (molto probabilmente entrambi) che puoi utilizzare per testare la tua applicazione per ovvi canali secondari, se dovessi esercitare il tuo Google-Fu. sup>

#5
+4
Artelius
2019-07-02 05:31:24 UTC
view on stackexchange narkive permalink

Attacchi Known-plaintext / Chosen-plaintext

Supponiamo che tu conosca la password di un particolare utente o, meglio ancora, possa registrarti e creare la tua password tutte le volte che vuoi.

E hai accesso in lettura al database.

Supponiamo inoltre che tu sospetti (o sai ) che si tratti di un algoritmo homebrew abbastanza semplice.

A questo punto puoi avviare la forzatura bruta dell'algoritmo e provare a ottenere l'hash nel database. Ad esempio, potresti "indovinare" che l'algoritmo sia

  $ hash = md5 ($ pass. $ Salt. 'Some random string');  

Dovresti forzare la stringa casuale. Ciò diventa più difficile man mano che la stringa si allunga, ma potresti essere in grado di sfruttare alcuni punti deboli di md5 scegliendo attentamente le password.

In alternativa potresti "indovinare" l'algoritmo

  $ hash = sha1 (md5 ($ pass. $ salt. 'abc'). 'def');  

e poi prova a forzare di nuovo.

Qualcosa come complicato poiché l'algoritmo di Dave sarebbe estremamente difficile senza alcuni suggerimenti. Se sapessi che è stato coinvolto un riordino dei personaggi, sarebbe utile.

* Questo. * L'attaccante può determinare l'algoritmo senza troppi sforzi!Questo è ciò che richiede il principio di Kerckhoffs.L'unica cosa con cui non sono d'accordo è che è difficile da capire.Presumo che sia facile da capire per un utente malintenzionato, anche se potrebbe richiedere un piccolo sforzo in più rispetto a un semplice MD5.
@jpmc26 Avere il database rende facile _verificare_ un potenziale algoritmo ma ancora difficile _indovinare_.Puoi raccogliere il frutto che pende in basso (come il programmatore che conserva un sale nel DB ma dimentica di usarlo!) Ma oltre a questo ci sono troppe permutazioni da esplorare.In una riga di codice puoi moltiplicare tutti i valori ASCII per 3, concatenarli, interpretarli come esadecimali e quindi sottrarre 730 prima dell'hashing ... come si fa a scrivere un brute-forcer per esplorare questa merda?
L'unica eccezione è che, se si osserva che la distribuzione dei valori finali non è uniforme e / o dipende in qualche modo dall'input, ciò può far trapelare informazioni sull'algoritmo.Ma se l'ultima fase dell'algoritmo è una funzione hash standard (anche md5) ciò non accadrà.
"Come fai a scrivere un brute-forcer per esplorare questa merda?"Una delle cose che ho imparato è che gli aggressori sono molto più intelligenti di quanto possa immaginare.=) Non possiamo provare che qualcuno non abbia trovato un modo completamente inaspettato per farlo, e il fatto che così tanti schemi crittografici siano caduti sotto un attacco molto intelligente che nessuno immaginava fosse possibile è il motivo per cui non dipendiamo dasegretezza.Semplicemente non sono disposto a credere che nessuno l'abbia fatto.
@jpmc26 Certamente._Tutto_ dovrebbe essere considerato suscettibile di attacchi creativi;ma facciamo affermazioni sulle cose in modo che altri addetti alla sicurezza possano identificare i punti deboli.Sarei molto interessato a conoscere i punti deboli conosciuti in questo genere di cose.Tieni presente che l'uso dei peperoni è comune come misura _ aggiuntiva_ e si basano sulla segretezza.Quello che abbiamo qui è (se fatto bene) una forma diversa di pepe, come la vedo io.
#6
+4
Rick
2019-07-02 20:23:54 UTC
view on stackexchange narkive permalink

Ho imparato molto di più di questa domanda, leggendo la risposta di @Conor Mancone e discusso con @Conor Mancone e @Anders, quindi decido di scriverlo. Correggimi se sbaglio di nuovo.


md5 e sha1 sono danneggiati, ma non come penso io

Pensavo erroneamente che l'output hash di md5 e sha1 possa sempre essere facilmente violato (ottieni il testo di input originale), non importa quanto sia grande l'input .

No, non lo è .

Se uso un pepe abbastanza lungo sul server, anche se uso md5 o sha1 per hash una password, sarebbe comunque sicuro, dato che il server non è compromesso .

Ad esempio: memorizza md5 ($ 128bits_long_pepper. $ password) nel database.
Anche senza sale, non puoi decifrarlo. Supponiamo che la tua velocità hash md5 sia 100 miliardi di hash / s . Prendiamolo come 2 ^ 40 hash / s per comodità, poiché 2 ^ 40 > 100 miliardi . Per forzarlo, è comunque necessario 2 ^ 128/2 ^ 40 = 2 ^ 88 secondi = 9.80719764 × 1018 anni . E naturalmente penso che nessuno pre-calcoli una tabella arcobaleno del genere.

Ma non dico che sceglierei md5 per hash la mia password. Non lo farei. Perché una volta che anche il tuo server viene compromesso, queste password con hash non fanno differenza dal testo in chiaro.

Sono un principiante e ho letto molti post molto votati che parlano di quanto siano pessimi md5 e sha1 , ma non vedo risposte a riguardo ⬆️ . Ne noto solo alcuni nei commenti.


Sale, pepe, funzione hash

Infine penso di aver compreso appieno questi 3 concetti e i loro casi d'uso / combinazioni.
Innanzitutto, riassumo 3 tipi di attacchi da solo: 1. attacco di forza bruta (il modo "prova tutto") 2. attacco al tavolo arcobaleno (lo sguardo diretto al contrario) 3. attacco dizionario ( $ pepper. $ Common_password. $ Salt forza bruta, parzialmente forza bruta, rispetto a 1.)

Quindi penso:

  1. Salt ha lo scopo di difendere l'attacco del tavolo arcobaleno.
  2. Una buona funzione hash (lenta) ha lo scopo di difendere l'attacco di forza bruta.
  3. Pepper ha principalmente lo scopo di difendere l'attacco del dizionario, dato che il server non è compromesso.

Spiega con un esempio:

( Salt ) Bisogna rendersi conto che un sale non è un grosso problema come molte persone descrivono. Difende solo una cosa, ovvero che un utente malintenzionato non può semplicemente fare una ricerca inversa nella sua tabella arcobaleno per ottenere la tua password senza hash. Se si utilizza solo la funzione hash salt + fast (senza pepe sul server), un utente malintenzionato può eseguire la forza bruta per ciascuna password con hash. Ovviamente un altro presupposto è che non si richieda al proprio utente di memorizzare una password lunga 128bit per la registrazione :).

Quindi:

  • funzione hash salt + fast non difende l'attacco di forza bruta. Se può difendere l'attacco della tabella arcobaleno o l'attacco del dizionario non è importante ora.
  • salt + slow hash function difende gli attacchi di forza bruta. Difende anche l'attacco al tavolo arcobaleno. Non difende l'attacco del dizionario.

( Pepper ) Ma per la combinazione salt + fast hash , se usi un pepe abbastanza a lungo sul server, dato che il tuo server non è compromesso, solo il database lo fa, la password sarà comunque sicura.

Quindi:

  • salt + funzione hash veloce + pepe lungo (es. 128 bit) + server non compromesso ora può difendere l'attacco di forza bruta. Difende anche l'attacco della tabella arcobaleno e l'attacco del dizionario.

( funzione hash ) Ma una volta che il server viene compromesso, la combinazione di cui sopra è come una merda. L'attaccante conoscerebbe il pepe. La difficoltà per decifrare salt + funzione hash veloce + long pepper (es. 128bits) + server viene compromesso è la stessa che qualcuno usa solo una funzione hash veloce .

Quindi:

  • salt + funzione hash veloce + pepe lungo (es. 128 bit) + il server viene compromesso non difende l'attacco di forza bruta. Se può difendere l'attacco della tabella arcobaleno o l'attacco del dizionario non è importante ora.
  • Ma se usi una funzione hash sicura / lenta, le cose cambiano.
    salt + funzione hash lenta + pepe (non è necessario che sia molto lungo, ad esempio 6 caratteri forse sono abbastanza buoni?) + il server viene compromesso difendere un attacco di forza bruta. Difende anche l'attacco al tavolo arcobaleno. Non difende l'attacco del dizionario.

Che dire della funzione salt + hash lento , non è abbastanza? Questa combinazione difende l'attacco di forza bruta e l'attacco da tavolo arcobaleno. Ma non difende l'attacco del dizionario. Aggiungere un peperone sul server è facile, perché no?


Di 'qualcosa per Dave

Come puoi vedere dall'alto, un peperone è solo qualcosa per cui lo usi fai un po 'di conversione sul lato server.
È la "conversione sul server" che conta davvero, a patto che il server non sia compromesso.
Ad esempio, prendi una costante casuale e la concatena con la password, hash ($ pepper. $ password, $ salt) , è un tipo di conversione. Quindi, se inventi degli algoritmi di merda sul server come fa Dave, stai anche facendo una conversione. Per entrambe le situazioni, l'aggressore deve compromettere il server. Per il primo, l'attaccante può semplicemente afferrare il tuo valore costante. Per quest'ultimo, l'attaccante ha bisogno di capire come funziona la tua cosa di merda e deve fare il contrario.

Quindi il punto è che penso che l'idea di Dave vada benissimo (fai un po 'di conversione sul server), ma non è necessario aggiungere tale oscurità / complessità. Perché la manutenzione potrebbe essere un inferno se aggiungesse sempre più complessità in questo modo. Una "conversione" come la concatenazione di un peperone sul server è abbastanza lontana. Di nuovo, penso che dopotutto sia un problema di compromesso. E l'idea di Dave è giusta dall'inizio (vuole impiegare un po 'di sicurezza extra sul lato server).

"Per quest'ultimo, l'attaccante deve capire come funziona la tua roba di merda e deve fare il contrario."- Per la maggior parte delle funzioni crittografiche casalinghe, gli aggressori non hanno bisogno di accedere al tuo codice sorgente per capire come funziona.- E nessuno sta dicendo che se non sei un esperto, dovresti smetterla ... Stiamo dicendo che se non sei un esperto, allora benvenuto nel club, e se vuoi diventare un esperto, fantastico!Non pensare di essere abbastanza esperto da distribuire la tua crittografia casalinga per proteggere i segreti reali fino a quando non avrai superato l'effetto Dunning-Kruger.
Vorrei anche essere un po 'più pedante (perché in questo caso è importante, perché sviluppatori PHP come i miei colleghi e molti altri sviluppatori leggono Stack Exchange e se ne vanno pensando di essere esperti) - "Algoritmi di hashing lenti"dovrebbero essere" Funzioni di derivazione chiave ", alcune delle quali utilizzano algoritmi hash sicuri come primitive e non sono reversibili come gli hash ... ma i KDF hanno impostazioni che regolano la quantità di lavoro necessaria e sono progettati per resistere alle GPU eASIC.SHA2 è lento.PBKDF2 utilizzando SHA2 è sicuro.
@Ghedipunk Sì, con slow intendo funzioni hash come `bcrypt` e` PBKDF2`.
@Ghedipunk Perché un utente malintenzionato non ha bisogno di accedere al codice sorgente, ad esempio io uso alcuni algoritmi homebrewed sul server, più `bcrypt` e` salt` nel database?
* Se * stai anche utilizzando una funzione di estensione della password sicura, sei il più sicuro che puoi ragionevolmente, con o senza il tuo algoritmo di hash / crittografia homebrew.Tuttavia, spesso non è il caso delle persone che utilizzerebbero la crittografia casalinga nella produzione, quindi mentre ci sono sfumature (e infosec è PIENO di sfumature), viene dato un consiglio generale supponendo che uno sviluppatore ingenuo implementerà le cose nel modo più ingenuo.
Per riformulare: la sicurezza in profondità è buona, ma è valida solo quanto l'aggregato di ogni livello.Uno strato debole non riduce la sicurezza * fintanto che non riduce l'entropia * (questo è un grosso problema), ma deve essere usato con strati forti, che è un passo che molti dimenticano.
Il pepe non è per sconfiggere gli attacchi del dizionario, ma per garantire che una perdita del database non sia sufficiente per decifrare le password.È fondamentalmente un modo sicuro per "personalizzare" un algoritmo hash.
@forest "assicura che una perdita del database non sia sufficiente per violare le password."In quale modo?Assicurati che l'aggressore non possa eseguire un attacco con dizionario.Si può sostenere che con la funzione "pepe lungo + sale + hash md5", difende anche l'attacco di forza bruta.Ma questo è per qualcuno che usa solo funzioni hash errate come "md5".
@Rick Un pepe è come un sale globale immagazzinato _ fuori_ dal database.Potresti persino memorizzarlo nel codice sorgente, quindi sarebbe necessario trapelare il codice per iniziare anche a decifrare gli hash.Pensa a un peperoncino come a una versione personalizzata di un hash che non richiede di essere un crittografo con decenni di esperienza necessari per _progettare_ un hash personalizzato o una modifica.Un peperoncino fornisce una protezione perfetta contro una perdita di database.
Ti manca un tipo di attacco: la crittoanalisi ... Molti algoritmi di crittografia progettati da crittografi anche ben consolidati risultano deboli in determinate condizioni e questo spesso può essere determinato senza l'algoritmo.Supponiamo che io abbia un attacco "noto con testo in chiaro": posso specificare un testo arbitrario e quindi ottenere il testo cifrato e quindi utilizzare metodi statistici per trovare punti deboli nell'algoritmo.
@Blackhawk Quelli sono abbastanza facili da evitare.Per non parlare del fatto che per l'hashing delle password, anche l'hash più debole (e uno dei primi), MD4, non è vulnerabile ad alcun attacco che renda possibile il cracking delle password.Ovviamente, essendo un hash veloce e non un KDF, è ancora pessimo da usare per le password, ma la crittoanalisi non è un problema.Diavolo, è vero anche con l'antico hashish che è venuto prima, MD2!
#7
+2
Peter
2019-07-04 00:06:53 UTC
view on stackexchange narkive permalink

Sebbene abbia valore nell'usare un algoritmo personalizzato "nascosto", esiste già un modo banale e consolidato per creare algoritmi di hash sicuri personalizzati: Pepper *

Perché il molto economico , esiste un'opzione molto rapida e molto sicura di utilizzare un Pepper, le persone che invece scrivono un algoritmo crittografico da zero per essere "più sicure" sono sempre alle prime armi. Quindi non solo il "protocollo di Dave" è uno spreco di tempo e denaro, è anche un (presumibilmente) protocollo sicuro scritto da qualcuno che non sa molto di protocolli sicuri. E questa è generalmente considerata una scelta imprudente, indipendentemente dall'effettiva sicurezza (o mancanza di sicurezza) nel protocollo di Dave.

* In breve, un pepe è un sale segreto che è lo stesso per tutti gli utenti.

#8
  0
Volker Siegel
2019-07-03 17:08:54 UTC
view on stackexchange narkive permalink

Regola empirica: non fare la sicurezza della birra fatta in casa.

Perché spesso va storto. E la persona che l'ha scritto non può provarlo, se qualcuno ha qualche presupposto sbagliato mentre lo scrive, lo ha ancora durante il test. Un test indipendente è sorprendentemente costoso / richiede tempo, molto più che scriverlo.

È necessario includere anche tutte le modifiche correlate. Sapere "non può esserci un problema, perché ..." non è un approccio valido. Per gli stessi motivi di cui sopra.

La sicurezza del software è un argomento difficile. È così difficile che è difficile persino capire quanto sia difficile.



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