/ ** Dave's Home-brew Hash ^ H ^ H ^ H ^ H ^ Hkinda stupido algoritmo * /// dati utente $ user = ''; $ password = ''; // timestamp, "random "# $ time = date ('mdYHis'); // noto agli aggressori - totalmente inutile // ^ inoltre, come ha sottolineato jdm nei commenti, questo cambia quotidianamente. sembra rotto! // hash diversi per giorni diversi? eh? o è memorizzato come salt? $ rand = mt_rand (). '\ n'; // mt_rand non è sicuro come generatore di numeri casuali // ^ è ancora meno sicuro se chiedi un solo numero a 31 bit. e perché \ n? // crypt è buono se configurato / salato correttamente // ... tranne che hai usato crypt sul nome utente? WTF. $ Crypt = crypt ($ user. $ Time. $ Rand); // funzione hash hash_it ($ stringa1, $ stringa2) {$ pass = md5 ($ stringa1); // perché MD5 sta effettuando lo stesso passaggio quando è disponibile crypt? $ nt = substr ($ passaggio, 0,8); // < --- BAD BAD BAD - perché mescolare un hash MD5?!?!? $ th = substr ($ pass, 8,8); $ ur = substr ($ passaggio, 16,8); $ ps = substr ($ passaggio, 24,8); // sul serio. Non ne ho idea. perché? // ^ mescolare porta _zero_ una sicurezza extra. ha _zero_ senso farlo. // inoltre, che succede con i nomi delle variabili? // e ora lo SHA1 anche con altra spazzatura? wtf? $ hash = 'H'.sha1 ($ stringa2. $ ps. $ ur. $ nt. $ th); return $ hash} $ hash = hash_it ($ password, $ crypt); // ... per favore fermati. mi fa male la testa. summon_cthulhu ();  

Dave, non sei un crittografo. Smettila.

Questo metodo casalingo non offre alcuna reale resistenza agli attacchi di forza bruta e dà una falsa impressione di sicurezza "complicata". In realtà stai facendo poco più di sha1 (md5 (pass) + salt) con un hash forse rotto ed eccessivamente complicato. Sembra che tu abbia l'illusione che un codice complicato offra una maggiore sicurezza, ma non è così. Un forte sistema crittografico è forte indipendentemente dal fatto che l'algoritmo sia noto a un aggressore - questo fatto è noto come principio di Kerckhoff. Mi rendo conto che è divertente reinventare la ruota e farlo a modo tuo, ma stai scrivendo codice che verrà inserito in un'applicazione business-critical, che dovrà proteggere le credenziali del cliente. Hai la responsabilità di farlo correttamente.

Attenersi a algoritmi di derivazione delle chiavi provati e testati come PBKDF2 o bcrypt, che hanno subito anni di analisi approfondita e controllo da parte di un'ampia gamma di crittografi professionisti e hobbisti.

Se desideri una buona istruzione sulla corretta memorizzazione delle password, dai un'occhiata a questi link:

• Come conservare salt?
• Qualche esperto di sicurezza consiglia bcrypt per l'archiviazione delle password?
• Come archiviare in modo sicuro le password ?

Vantaggi di un protocollo pubblico:

• Probabilmente scritto da persone più intelligenti di te
• Testato da molte più persone (probabilmente alcune di loro più intelligenti di te)
• Revisionato da molte più persone (probabilmente alcune di loro più intelligenti di te), spesso ha prove matematiche
• Migliorato da molte più persone (probabilmente alcune di loro più intelligenti di te)
• Al momento solo una di quelle migliaia di persone trova un difetto, molte persone iniziano a risolverlo

Svantaggi di un protocollo pubblico:

• Se viene effettivamente trovato un difetto,
• E reso pubblico
• E non risolto abbastanza velocemente

gli aggressori inizieranno a cercare siti vulnerabili / applicazioni. MA:

• Probabilmente cercheranno prima obiettivi più importanti
• Quando il difetto viene scoperto, lo sai e puoi bloccarlo
• No tutti i difetti sono "critici" (la maggior parte sono come "le collisioni sono possibili in determinate condizioni" o "il tempo per la forza bruta non è di 10 ¹² anni, ma di 10 ⁶ anni")

La sicurezza per oscurità è considerata del tutto negativa. Inventare il tuo rientra in quella categoria.

Se Dave è davvero il "tuo" sviluppatore, in quanto hai l'autorità per licenziarlo, allora hai l'autorità per indirizzarlo a utilizzare uno schema più ben documentato e dovresti.

In crittografia, meno segreti che devono essere mantenuti, meglio è. Ciò si applica soprattutto ai segreti "hardcoded", come la funzione hash stessa, che non sono segreti non appena il codice contenente il segreto lascia il tuo edificio.

Questo è il motivo per cui gli standard aperti per la crittografia sono un buona cosa; se lo schema esiste da anni o addirittura decenni, con l'algoritmo di base e varie implementazioni pubblicamente note, e ancora nessuno ha trovato un modo per entrare, è un buon schema.

Caso in questione, Polynomial ha fornito un'ottima analisi di ciò che non va nello schema, ma qui ci sono i principali fallimenti dell'algoritmo di hash proposto:

• MD5 è completamente rotto ; Sebbene un attacco preimage non sia reso molto più semplice dai modi principali in cui MD5 viene interrotto (è estremamente vulnerabile a forti collisioni di testo in chiaro noto; conoscendo il messaggio e il digest, si può produrre una collisione in 2 ^ 24 volte), l'hashing l'algoritmo è troppo veloce per essere protetto contro il moderno hardware di cracking distribuito. Non dovrebbe mai essere utilizzato in applicazioni che richiedono la protezione dei dati.

• SHA-1 è considerato vulnerabile ; Anche in questo caso, non esiste un vettore elegante per un attacco preimage, ma c'è un forte attacco di collisione (2 ^ 61 volte per un hash a 160 bit), e l'algoritmo di hashing è abbastanza veloce e lo spazio delle chiavi abbastanza piccolo che l'hardware corrente può essere facilmente brutale -Forza.

• Più hash non significano necessariamente un hash migliore . Gli hash sono un processo deterministico; rappresentano un "oracolo casuale" nella crittografia teorica, ma poiché devono sempre produrre lo stesso output dato lo stesso input, non possono aggiungere alcuna entropia a ciò che è già inerente all'input.

  Detto semplicemente, usare una combinazione segreta di più hash come sta facendo Dave, anche se quella combinazione è sconosciuta, non aggiunge una quantità significativa di lavoro a una forza bruta (l'ordine relativo di tre hash ha 6 possibilità, aumentando la complessità di provare tutte le possibilità di meno di 3 potenze di 2), e quella complessità aggiuntiva scompare non appena un attaccante può decompilare il codice e scoprire l'ordine relativo delle funzioni hash.

• Le password sono intrinsecamente a bassa entropia . Le migliori password "consumabili dall'utente" (non prive di senso) hanno una complessità massima di circa 50 bit di entropia, il che significa che possono essere violate, se hai un'idea di cosa stai cercando, in 2 ^ 50 o meglio . Ciò rende le password più facili da decifrare rispetto ad altre cose che normalmente sottoporresti ad hashing (come i digest di certificati), richiedendo una "prova di lavoro" aggiuntiva per aumentare la loro sicurezza.

• Questo schema non aggiunge alcuna prova di lavoro significativa ; tre hash invece di uno, nel grande schema delle cose, aggiungono l'equivalente di circa 1,25 bit di entropia allo schema nel lavoro extra richiesto; potresti fare di meglio richiedendo che le password siano più lunghe di un carattere.

BCrypt, contrariamente a quanto sopra, ha come vantaggio principale una funzione di derivazione della chiave estremamente lenta o KDF. Blowfish, il cifrario di crittografia che costituisce la base di BCrypt, utilizza un "SBox"; un ampio array di valori iniziali predeterminati, che viene modificato dalla chiave e / o IV per produrre lo stato iniziale del cifrario attraverso il quale viene alimentato il testo in chiaro. In BCrypt, questa configurazione SBox è resa più complessa prendendo la password e i valori salt più piccoli ed eseguendoli attraverso il cifrario "unkeyed" un numero predeterminato di volte, "riscaldando" il cifrario in uno stato che teoricamente potrebbe essere prodotto solo eseguendo lo stesso numero di iterazioni di setup, utilizzando la stessa password e salt. Questo codice "riscaldato" viene quindi alimentato con un testo in chiaro costante per produrre il valore hash. In termini di CS, l'hash costituisce una "prova di lavoro"; un compito computazionale difficile (che richiede tempo e / o risorse) da eseguire, ma facile da verificare per la correttezza (l'hash prodotto corrisponde a quello che abbiamo già?).

Quel "numero predeterminato "di iterazioni del setup di SBox è configurabile; questo è il vero potere di BCrypt. Durante l'hashing viene specificato un certo numero di "round" di impostazione della chiave e per n round, vengono eseguite 2 ^ n iterazioni dell'impostazione della chiave. Ciò significa che l'incremento del numero di round fa sì che l'hash esegua il doppio del lavoro e impieghi il doppio del tempo sullo stesso hardware per produrre la prova di lavoro richiesta. BCrypt quindi può facilmente tenere il passo con la legge di Moore, che è stata la rovina di molte funzioni hash precedenti.

La principale debolezza teorica di BCrypt è il suo basso utilizzo di memoria; mentre il tempo di calcolo può essere aumentato esponenzialmente, la quantità di memoria richiesta rimane effettivamente costante (SBox non diventa più grande all'aumentare delle iterazioni e non è necessario mantenere alcun "risultato intermedio"). In quanto tale, mentre BCrypt ostacola la pura potenza di calcolo pipeline di una GPU, rimane vulnerabile al cracking da parte di più sofisticati "array di porte programmabili sul campo" (fondamentalmente un insieme massiccio e altamente modulare di unità logiche "cablate", che sono le lo stato dell'arte nell'elaborazione altamente distribuita), perché i vincoli di memoria ridotta significano che puoi semplicemente lanciare circuiti stampati più relativamente economici al problema.

Un algoritmo più recente, SCrypt, combatte i cracker FPGA aumentando in modo esponenziale le richieste di memoria e le spese di calcolo per il calcolo dell'hash, quindi la memoria limitata disponibile per ogni FPGA li rende rapidamente non fattibili (il cracking distribuito richiederebbe fondamentalmente un gran numero di combinazioni CPU / FSB / RAM, essenzialmente computer pieni , agganciati insieme). L'unico problema è che SCrypt ha solo 2 o 3 anni, quindi non ha il pedigree crittoanalitico di BCrypt (13 anni). E davvero, se devi preoccuparti che un cracker armato di FPGA riceva una password in un lasso di tempo possibile (come prima che tu possa cambiarle tutte comunque), hai fatto incazzare alcune persone molto potenti e hanno già esposto un'altra grave vulnerabilità (consentendo a un utente malintenzionato di ottenere gli hash delle password memorizzate in primo luogo, in modo che possa decifrarne uno "offline").

In conclusione, usa BCrypt per l'hashing della password. Ha 13 anni, basato su un algoritmo di cifratura di 20 anni, e in quel periodo non sono state trovate vulnerabilità note che aiuterebbero un cracker di password. È lento come la melassa e può essere configurato per esserlo sempre, a condizione che lo abbini all'obbligo per gli utenti di cambiare la password ogni 90 giorni circa, in modo che le nuove password continuino ad essere sottoposte ad hashing con configurazioni più costose.

Per essere onesti con Dave, in termini di sicurezza delle password homebrew questo è uno dei casi migliori in quanto tutto è solo un po 'di obsfuscation (e davvero non molto) mascherando hash = SHA1 (salt + MD5' (Password) ) dove MD5 ' esegue uno scambio reversibile dell'ordine dei byte dell'hash MD5. Ora la parte username / time / random / crypt è usata solo per generare un salt, e l'unico requisito che abbiamo per i sali è che devono solo avere una buona probabilità di unicità; quindi anche se è troppo complicato, non serve parlarne.

Di nuovo hash = sha1 ($ salt + md5 '($ password)) . La riorganizzazione dell'MD5 non aggiunge sicurezza ( swap (00112233445566778899aabbccddeeff) diventa ccddeeff8899aabb0011223344556677 ) lo scambio non ti impedisce di utilizzare le tabelle arcobaleno md5 dopo (ad esempio, guarda il codice e inverti il scambiare). Tuttavia, la presenza del sale unico rende irrealizzabili le tabelle arcobaleno.

Ora, per essere critici, questo si riduce a una semplice funzione hash crittografica applicata due volte; che è meglio che memorizzare una password in chiaro (vedi trasgressori di testo in chiaro) e meglio che archiviare un hash non salato (vedi leak linkedin). Tuttavia, nell'era delle GPU massicciamente parallele economiche, questo è troppo debole per l'uso moderno. Chiunque abbia un po 'di esperienza di programmazione GPU generica che ha ottenuto in qualche modo sul server live (per ottenere gli hash con il loro sale) può probabilmente vedere il suo codice sorgente, provare la propria password come caso di test e quindi può forzare qualsiasi password specifica a una velocità di miliardi di tentativi al secondo per GPU.

Quindi, se un utente utilizza una password su un elenco di circa un milione di password precedentemente trapelate (ad esempio da linkedin), l'attaccante può quasi decifrarla istantaneamente. Se la password di un utente è composta da 8 lettere casuali del set di caratteri A-Za-z0-9; ci vorrebbero in media circa 60 ore per rompere per GPU (quindi se avessi 60 GPU; ci vorrebbe 1 ora). L'utilizzo di tecniche di cracking comuni che sfruttano forme di password comuni potrebbe velocizzarlo notevolmente. Vale anche la pena notare che poiché $ password passa attraverso una funzione di hashing MD5 a 128 bit, non vi è assolutamente alcun vantaggio nell'usare più di 128 bit di entropia nella passphrase (anche se per essere onesti è un password sicura; come una passphrase diceware di 10 parole o una password alfanumerica casuale di 22 caratteri).

In realtà, dovresti usare funzioni hash crittografiche iterate; è qualcosa come bcrypt o PBKDF che rallenta il tasso di forza bruta degli aggressori di un grande fattore costante (diciamo 10 ⁵ ) (quindi invece di 60 ore per decifrare una password casuale di 8 caratteri da un Set di 62 caratteri (A-Za-z0-9); ci vogliono 6 milioni di ore (~ 700 anni per essere probabilmente rotto) con una singola GPU, e questo migliora con password più forti (ad esempio, una password di 10 caratteri richiederebbe ~ 3 milioni di anni; quindi anche con un milione di GPU ci vorrebbero 3 anni). Quindi un piccolo rafforzamento dei tasti sposta la password relativamente debole (8 caratteri casuali da 62 caratteri) fuori dalla gamma di fattibilità di essere violata da un attaccante. i limiti massimi dell'utilizzo di una password rinforzata con chiavi semplici vedi questa risposta.

Collision Attacks vs Pre-Image Attacks (o Perché Collision Attacks su una funzione hash sono irrilevanti per l'hashing della password)

La risposta di KeithS, sebbene dia buoni consigli (usa bcrypt e non una semplice funzione di hash crittografica per hash la tua password) inizialmente ha criticato MD5 e SHA1 per la logica sbagliata (non usare MD5 come suo vulnerabile agli attacchi di collisione). C'è una sottile differenza tra pre-immagine e attacchi di collisione e le argomentazioni nei commenti erano troppo condensate, quindi sto elaborando qui. Consiglio vivamente di leggere l ' articolo di wikipedia sugli attacchi pre-immagine.

Un attacco pre-immagine dice che viene fornito uno specifico hash a 128 bit scritto in esadecimale: h = ad2baf26a87795b3c8a8366a08b44112 , una specifica funzione hash H , trova un messaggio m tale che h = H (m) ; nota che ci sono N = 2 ¹²⁸ diversi hash distinti. Ora, se la tua funzione hash crittografica non è interrotta, ogni bit nel tuo hash ha una probabilità del 50% di essere 0 o 1 per un messaggio casuale m. Quindi dovrò in media generare hash per circa N = 2 ¹²⁸ hash prima di avere la fortuna di trovare qualsiasi messaggio m tale che h = H (m ) (questo messaggio potrebbe non essere lo stesso input utilizzato per generare l'hash originariamente, ma rientra comunque nella categoria di attacco "pre-immagine").

Un attacco di collisione dice trovami due messaggi qualsiasi m1 e m2 tali che H (m1) = H (m2) . Nota che m1 , m2 , (e H (m1) ) sono tutti liberi di cambiare. Questo caso è un problema molto più semplice poiché se genero M hash per M messaggi diversi, non sto solo confrontando i messaggi M con un hash specifico (quindi ho M possibilità di trovare una collisione), ora ho M * (M- 1) / 2 coppie di hash, quindi circa M ^ 2 possibilità di avere una collisione. Quindi, in questo caso, dovrò generare all'incirca all'incirca sqrt (N) ~ 2 hash ⁶⁴ prima che sia probabile che uno di essi entri in collisione con un altro su un hash ideale a 128 bit.

Diamo un'occhiata ai due tipi di problemi di compleanno. Il problema della collisione si traduce nel comune "paradosso" del compleanno; quante persone hai bisogno in una stanza prima che due persone condividano un compleanno con N = 365 giorni in un anno. La risposta è un paradosso in quanto hai solo bisogno di circa sqrt (N) ~ 23 persone prima che sia probabile che due persone condividano un compleanno (come con 23 persone in una stanza hai 253 coppie diverse di persone che potrebbero corrispondere). (So ​​che sqrt (365)! = 23: Sto usando la matematica approssimativa non concentrandomi su fattori costanti insignificanti. Rifacendo il calcolo con sqrt (365) ~ 19 persone nella stanza e poi P (due parti di compleanno ) = 19! * Comb (365,19) / 365 ** n = 37,9% , che sebbene non strettamente il 50% significa che è abbastanza probabile che accada). Nota per il problema del compleanno della collisione, non puoi avere N + 1 = 366 persone in una stanza e c'è la possibilità di non avere una collisione (ignorando i giorni bisestili); nella migliore delle ipotesi le prime 365 persone hanno avuto compleanni diversi e l'ultima persona ha generato una collisione.

Il problema della pre-immagine è una domanda molto diversa, di quante persone ho bisogno in una stanza prima che sia abbastanza probabile che qualcuno ha un compleanno specifico (diciamo B = 18 dicembre). In questo caso, ho bisogno di circa N ~ 365 persone prima che accada. Ad esempio, con 365 persone nella stanza hai una P (qualcuno ha il compleanno B) = 1 - (1 - 1/365) ^ (# persone) quindi per # people = 365 hai una probabilità del 63% che il compleanno di qualcuno sia una data fissa B. In questo caso, puoi facilmente immaginare di avere un numero qualsiasi di persone in una stanza e che non ci sia nessuno che abbia un compleanno in una data specifica. (Supponiamo che tu abbia invitato persone nella stanza solo se il compleanno non era una data specifica; non c'è limite al numero di persone che potresti invitare).

Quando una funzione hash come MD5 / SHA1 viene interrotta per attacchi di collisione, significa che puoi generare una collisione in meno lavoro rispetto al tempo di forza bruta di sqrt (N) ~ 2 ^{numbits / 2} . Per MD5 ci vogliono solo circa ~ 2 ^ 24 tempo per generare una collisione; per SHA1 ci vuole ~ 2 ^ 61 tempo. Ciò significa che gli attacchi di collisione su MD5 sono estremamente facili da eseguire; ma gli attacchi pratici a SHA1 sono ancora difficili. Ma gli attacchi di collisione contano solo se non ti interessa quale hash stai cercando di abbinare. Questi attacchi di collisione sono abbastanza rilevanti per alcune applicazioni come la firma crittografica dei messaggi per garantire l'integrità dei messaggi, quindi fai attenzione all'uso di MD5 / SHA1 in questi casi. Tuttavia, quando hai un sale unico e un hash specifico che stai cercando di abbinare per l'autenticazione, gli attacchi di collisione non hanno importanza.

Vedi il relativo post sul meme sulla sicurezza

Anche se questo può sembrare molto semplicistico, le regole sono vere: progettazione di algoritmi crittografici e correttamente / saldamente è molto difficile. Persino quelli progettati da esperti e selezionati da migliaia di persone nel corso degli anni alla fine hanno scoperto dei buchi.

Quindi Do Not Roll Your Own Crypto è un buon consiglio per tutti (possibile le eccezioni includono notabili come Rivest, Adleman, Pornin, Shamir)

Anche se possiamo trovare molti difetti con l'algoritmo di Dave, in realtà non è orribile perché non è una birra fatta in casa al 100%; usa protocolli di hashing che (anche se deboli) sono basati su principi solidi. D'altra parte, adotta misure che aumentano la complessità per lo sviluppatore ma fanno poco per migliorare la sicurezza del suo algoritmo.

Ma il motivo per cui sto aggiungendo un'altra risposta qui è per sollevare l'argomento secolare secondo cui c'è valore nell'oscurità. La linea di difesa primaria dovrebbe sempre essere algoritmi di hashing forti e ampiamente accettati, ma non c'è nulla di male nell'aggiungere anche la più piccola quantità di oscurità come ulteriore livello di difesa.

Questo livello di oscurità non dovrebbe mai essere considerato una difesa in sé, semplicemente un fattore aggiuntivo che riduce le possibilità di compromesso. Poiché un attacco riuscito normalmente richiede una serie di fattori per essere attuati, anche piccole difese possono avere un grande impatto nel ridurre il rischio complessivo.

Non posso dirti quante volte ho visto discariche di hash che ho provato a decifrare dove semplicemente non ottengo nulla perché alcuni Dave da qualche parte hanno pensato a questo stupido algoritmo non standard che non posso decifrare a meno di fare un'intensa crittoanalisi o di entrare nei server web per ottenere l'algoritmo. Non si può negare che questi stupidi algoritmi siano un valido fattore difensivo.

Ora, se Dave ha preso il suo stupido algoritmo e lo ha aggiunto come strato ad algoritmi più forti come PBKDF2 o bcrypt, allora ha oscurità con il sostegno di solide pratiche di sicurezza. Inoltre, l'oscurità non deve essere complessa come il codice di Dave, tutto ciò di cui hai veramente bisogno è essere un po 'diverso per essere oscuro. Ricorda che questa non è una difesa, solo uno strato di oscurità.

I modi migliori per ottenere l'oscurità sono l'utilizzo di un HMAC, la concatenazione di una costante salt lato server e / o l'utilizzo di un numero elevato di iterazioni non standard. Nessuna di queste misure sarà valida da sola, ma certamente affrontano vettori di attacco specifici che contribuiscono al rischio complessivo.

tl: dr; la sicurezza attraverso l'oscurità è un male, ma una solida sicurezza più una ragionevole quantità di oscurità è una strategia valida.

OK, licenzia Dave. Per lo meno colpiscilo con una mazza-indizio molto grande. I protocolli aperti sono utili perché chiunque può cercare e tentare di trovare vulnerabilità e problemi strutturali e implementare correzioni. La visibilità migliora il protocollo. Una buona sicurezza significa che tutti possono sapere come funziona il sistema ed è comunque protetto.

Convincilo con un buon ragionamento. Non rimproverarlo.

Devi pensare al motivo per cui stiamo eseguendo l'hashing delle password: il motivo è proteggere la password originale facendo in modo che il processo di hashing richieda molto tempo per l'esecuzione della CPU. La forza bruta è il modo in cui le password vengono generalmente recuperate.

Se l'aggressore è in grado di rubare il tuo database delle password, è riuscito ad accedere al tuo database. Se hanno accesso al database, probabilmente hanno accesso anche al codice che produce queste password. Dopo aver esaminato il codice possono iniziare a forzare le password perché l'algoritmo di hashing impiega troppo poco tempo per essere eseguito.

L'idea alla base di metodi e pratiche di hashing ben noti come usare PBKDF2 con 10.000 iterazioni è che richiedono molto tempo per essere eseguite sull'hardware corrente.

Se hai tempo a disposizione potresti anche scrivere un programma di forza bruta e mostrargli quanti attacchi al secondo hai può eseguire con il suo algoritmo rispetto agli standard prevalenti.

Ho scritto diversi algoritmi di hashing. Non c'è niente di sbagliato in questo, se sai cosa stai facendo. In modo molto lieve, ha ragione sul fatto che algoritmi collaudati potrebbero essere un po 'più vulnerabili agli attacchi. Quindi, se riesci a creare un buon algoritmo, sei d'oro. L'unico problema è che fa totalmente schifo, per una serie di ragioni.

1. // timestamp, random # $ time = date ('mdYHis');

   Non mi sento nemmeno di dover spiegare questo. Stava cercando di creare un numero "casuale" seminato quando non ha alcun senso farlo. Gli hash cambieranno di giorno in giorno. Non riesco a immaginare che funzioni in uno scenario ragionevole.

2. Dice che vuole allontanarsi dagli algoritmi di hashing conosciuti, eppure usa MD5 (il più noto di tutti, e abbastanza debole anche) per la maggior parte del "suo" algoritmo. Il suo metodo è solo un molto derivato del semplice hashing MD5. Il che mi porta a:
3. Sta mescolando il suo risultato MD5. Uh, perché? Come piccola attività divertente, prova a chiedergli di spiegare il suo ragionamento lì. E ti darò un consiglio per aiutarti: qualunque sia la sua risposta, è sbagliata. Mischiare un valore hash è come mescolare un mazzo di carte completamente vuote. Non c'è alcun vantaggio in più da questo.

Ci sono anche più cose che non vanno, ma queste sono quelle grandi. Digli di tornare al suo solito lavoro e usa solo bcrypt (o scrypt , che è probabilmente anche un po 'più sicuro per il fatto che è davvero impegnativo per la CPU)

La steganografia trarrebbe vantaggio dalla segretezza operativa di Dave meglio della crittografia. Questo potrebbe essere ciò a cui Dave intendeva intuitivamente.

Crittografia

Ogni soluzione crittografica beneficia dell ' esposizione più ampia possibile perché fare affidamento su un segreto diverso dalla chiave privata rende la sicurezza operativa per un consumatore di criptovalute molto più difficile. Una chiave è un singolo rischio per la sicurezza facile da gestire, portabile, prevedibile e ben definito che gli esperti di crittografia si sono impegnati a fondo per garantire che tutti i rischi nell'algoritmo siano stati ridotti solo il tasto.

Le chiavi possono essere rese impercettibili (alta entropia) in quanto richiedono attacchi di forza bruta o di canale laterale. I segreti in altri aspetti di un algoritmo non possono essere resi impercettibili perché qualsiasi altro aspetto di un algoritmo di crittografia può essere generalizzato in una classe universale di algoritmo di crittografia (possibilmente più debole) + un valore costante. Questo valore costante rappresenta tutta l'entropia invariante residua nella struttura o nell'offuscamento dell'algoritmo. Questo valore non è mai particolarmente grande o entropico in un algoritmo di produzione casalinga ed è intrinsecamente costante in qualsiasi programma per computer che non si auto-modifichi. Un utente malintenzionato può acquisire la fonte e rimuovere direttamente questa (minore) entropia o eseguire il testo cifrato tramite una classe di algoritmi generalizzati. La NSA, ad esempio, farebbe proprio questo per varianti sconosciute di algoritmi comuni utilizzati da potenze straniere.

Steganografia

Ogni soluzione steganografica beneficia del minor visibilità pubblica perché nascondere la posizione dei segreti richiede che l'aggressore personalizzi la propria ricerca in un modo potenzialmente unico per quella vittima; e scala in base alla quantità di nascondigli possibili e metodi per nascondersi a disposizione della vittima.

Potrebbe essere semplice come avere una falsa colonna della password hash e nascondere quella reale in quattro colonne time_t (64 bit) in varie tabelle che registrano le informazioni dell'utente. Ciò può essere complesso quanto nascondere un Emulazione Linux portatile all'interno di un film BluRay.

La steganografia si basa in ultima analisi sulla creazione o sulla modifica di un artefatto che ha un significato o scopo semantico pubblico e un significato o scopo semantico privato secondario. Una persona o un'organizzazione trae vantaggio dal nascondere i significati semantici secondari più o meno allo stesso modo di qualsiasi bugia per omissione. Sia che " Il mio calzino è noioso e non contiene diamanti " o " Questi sono gli hash che stai cercando, ignora quel honeypot o quella connessione socket a un server di audit ".

In Combination

Quindi Dave dovrebbe usare librerie di alto livello controllate pubbliche come BouncyCastle invece di un home-brew di cripto-primative di basso livello; ma dovrebbe sentirsi libero di far sentire l'hacker che naviga nell'ecologia del server come se stesse leggendo un programma brainfuck a cui mancano alcuni caratteri.

Supponendo che la documentazione di supporto completa sia conservata in un luogo offline sicuro per i successori di Dave ...

Proverò un approccio diverso per rispondere a questa domanda. Non ti dirò che qualcosa è brutto e non ti spiegherò perché. Spiegherò esattamente perché è brutto, passo dopo passo, e ti mostrerò come romperlo, ma non entrerò troppo in profondità nei Rainbow Tables ... si presume che tu sappia cosa è.

Ecco perché l'hash del tuo sviluppatore non è corretto: perché introduce solo alcuni fattori che potrebbero essere completamente forzati una volta che il metodo viene scoperto, anche se dovesse randomizzare il mescolamento.

Come? Perché se ho accesso al tuo server, conosco anche il metodo che il tuo sviluppatore sta usando per hash la tua password perché ho rubato anche quel codice e posso riorganizzare tutto per adattarlo alla mia piccola applicazione pazza.

Diciamo che ho violato la tua azienda e ho ottenuto l'accesso al tuo database in modo da poter ottenere questi hash. So QUANDO gli utenti si registrano, corretto? So quando hanno cambiato la password l'ultima volta perché, a meno che tu non sia un principiante completo, dovresti registrare queste informazioni nel database.

  $ time = date ('mdYHis');  

Questo timestamp è probabilmente più o meno nello stesso momento in cui l'utente ha registrato la propria password o l'ha modificata. Possiamo saperlo perché l'ultima volta che è stato aggiornato dovrebbe essere memorizzato nel database. L'ora in cui ti sei registrato dovrebbe essere memorizzata nel database. Parte della cripta è stata sconfitta.

  $ rand = mt_rand (). '\ n';  

Fantastico, un generatore di numeri casuali. Sai, niente è veramente casuale sui computer. I generatori di numeri casuali non sono veramente casuali. Questo è il Mersenne Twister . Tutto ciò di cui ho bisogno sono 624 diverse combinazioni per capire tutti i numeri futuri. Ho anche rubato il tuo "sale" dal database e so come lo stai calcolando.

Poiché conosco le date in cui i tuoi utenti si sono registrati, so come ricreare il numero corretto per la routine Mersenne Twister in quel momento specifico. Posso scrivere un piccolo metodo di cracking per estrarre il numero esatto che probabilmente sarebbe accaduto in quel momento. Il tuo sale non è più casuale. Ma sai cosa? È irrilevante. Conosco il formato esatto che stai usando per quel sale e probabilmente l'ho preso comunque dal tuo database. Quindi posso usare Rainbow Tables per annientare completamente il tuo sale in meno di un secondo perché mt_rand () da solo produce un massimo di 10 ^ 10 hash e un minimo di 10 ^ 9 , che significa 11 miliardi di possibilità, e poiché sono tutti numeri e conosco il formato del tuo sale, verranno decifrati in meno di un secondo.

Quindi ora So a chi appartiene questo nome utente perché ho collegato il tuo database. So quando si sono registrati, so quando hanno cambiato la password l'ultima volta e conosco il tuo numero casuale. Ti vedo, Dave, un ladro sul tetto. Il mio nuovo collegamento satellitare ha sia lo spettro a infrarossi che quello a raggi X. Vedo il tuo cuore battere. Vedo che hai paura.

Ora che $ crypt è stato sconfitto, diamo un'occhiata alla function hash_it () .

  funzione hash_it ($ stringa1, $ stringa2) {$ pass = md5 ($ stringa1); $ nt = substr ($ passaggio, 0,8); $ th = substr ($ pass, 8,8); $ ur = substr ($ passaggio, 16,8); $ ps = substr ($ passaggio, 24,8); $ hash = 'H'.sha1 ($ stringa2. $ ps. $ ur. $ nt. $ th); return $ hash}  

Ora diamo un'occhiata ad alcuni input di esempio: hash_it (Dave, testpassword1);

Risultati:

  $ pass = "b7e055c6165da55c3e12c49ae5207455" $ nt = "b7e055c6"; $ th = null; $ ur = "3e12c49a"; $ ps = "e5207455";  

$ hash Input : "H" + "nome utente +" RegistrationDate "+" 1604716014 "+" e5207455 "+" 3e12c49a "+" b7e055c6 "(tldr: "HDaveRegistrationDate1604716014e52074553e12c49ab7e055c6" )

  $ hash = 'H'.sha1 ("DaveRegistrationDate1604716014e52074553e12c49ab7e055c6);  

` $ hash output : "6b347a1521b6b84501806268614abe1e7324c703" tempo)

Ecco come potrebbe funzionare un attacco :

1. Rompi Mersenne Twister ( mt_rand () ) dopo 624 osservazioni, o semplicemente Rainbow Table the salt.
2. Prendi la REGISTRATION_DATE di Dave dal database o la USER_LAST_MODIFIED_DATE
3. Prendi la SHA1 di Dave hash
4. Avvia un attacco di forza bruta (diventa un hash sha1 statico dopo aver infranto la tua "sicurezza") con i seguenti parametri:
   • "Username" + "RegistrationDate" + YourRandomNumber + DictionaryAttack[”
5. Danneggia i tuoi clienti.

E questa è la storia del motivo per cui non dovresti lanciare la tua crittografia a meno che tu non sappia veramente cosa stai facendo. Immagina se fossi un vero cracker, e non è così uno che è appena tornato indietro nel codice.