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.

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":
   • Analisi della frequenza
   • Known-plaintext
   • Restanza dei dati

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

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.

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 ¹ ) 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 ² "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 ³ . 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. ⁴

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

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>}

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.

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

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.

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.