Domanda:
La sicurezza della password home-brew del mio sviluppatore è giusta o sbagliata, e perché?
nallenscott
2012-12-18 20:51:12 UTC
view on stackexchange narkive permalink

Uno sviluppatore, chiamiamolo "Dave", insiste sull'utilizzo di script home-brew per la sicurezza delle password. Vedi la proposta di Dave di seguito.

Il suo team ha impiegato mesi ad adottare un protocollo standard del settore utilizzando Bcrypt. Il software ei metodi in quel protocollo non sono nuovi e si basano su implementazioni collaudate che supportano milioni di utenti. Questo protocollo è un insieme di specifiche che descrivono in dettaglio lo stato dell'arte attuale, i componenti software utilizzati e come dovrebbero essere implementati. L'implementazione si basa su un'implementazione ben nota.

Dave si è opposto a questo protocollo sin dal primo giorno. Il suo ragionamento era che algoritmi come Bcrypt, poiché sono pubblicati, hanno una maggiore visibilità per gli hacker e hanno maggiori probabilità di essere presi di mira per gli attacchi. Ha anche sostenuto che il protocollo in sé era troppo ingombrante e difficile da mantenere, ma credo che il problema principale di Dave fosse il fatto che Bcrypt è stato pubblicato.

Quello che spero di ottenere condividendo il suo codice qui, è quello di generare consenso su:

  1. Perché la birra fatta in casa non è una buona idea, e
  2. Cosa c'è di sbagliato nello script
  / ** Dave's Home-brew Hash * /// user data $ user = ''; $ password = ''; // timestamp, random # $ time = date ('mdYHis '); $ rand = mt_rand ().' \ n '; // crypt $ crypt = crypt ($ user. $ time. $ rand); // hashfunction hash_it ($ string1, $ string2) {$ 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} $ hash = hash_it ($ password, $ crypt);  
... e ora il protocollo di Dave è pubblicato?
La chiamata a "data" non significa che la stessa password avrà due hash diversi in momenti diversi?
@jdm Immagino che memorizzi "$ time" e "$ rand" come sale nel db. In caso contrario, questo è chiaramente rotto.
Dave avrebbe potuto avere ragione se si fosse ritrovato con un approccio migliore e più sicuro. Non l'ha fatto. Il motivo per cui utilizziamo algoritmi pubblicati è che tutti beneficiamo della saggezza collettiva degli altri e non dobbiamo fare affidamento sulla nostra comprensione personale e in evoluzione di un concetto.
@schroeder concordato. La mia prima reazione è stata quella di consultare lo stato dell'arte attuale e partire da questo. Mi piacerebbe possedere questo tipo di IP, ma la realtà è che non abbiamo le competenze, le tecniche, i dispositivi, la manodopera per 1) creare l'algoritmo, 2) testare l'algoritmo e 3) mantenere l'algoritmo ...
Dave ha una premessa fondamentalmente falsa, che la sicurezza di un algoritmo si basa (anche parzialmente) sulla sua oscurità - non è così. La sicurezza di un algoritmo di hashing si basa sui limiti della nostra comprensione della matematica e, in misura minore, sulla capacità dell'hardware di forzarla. Una volta che Dave accetta questa realtà (ed è davvero la realtà, leggi l'articolo di Wikipedia sull'hashing), è una questione di chi è più intelligente: Dave da solo o da un folto gruppo di specialisti dedicati a questo problema molto particolare.
@ChrisB.Behrens altrimenti noto come [Principio di Kerckhoff] (http://en.wikipedia.org/wiki/Kerckhoffs%27s_principle).
Per favore, di 'a Dave di non reinventare la ruota.
Peggio ancora ** il suo algoritmo potrebbe essere forzato in pochi minuti, probabilmente per l'intera base di utenti. **
Oltre a quanto già detto, vorrei sottolineare che * gli algoritmi pubblicati sono progettati per rimanere sicuri anche se sono stati pubblicati *. Ciò significa che devono essere * migliori * degli algoritmi che possono fare affidamento sull'avversario che non sa come funzionano.
Il problema non è che Dave sia stupido; probabilmente non lo è. Il problema è che il suo algoritmo non è stato sottoposto ad anni di brutali test sul campo da parte di eserciti di esperti. Questo è l '** unico ** modo per dimostrare che un algoritmo di hashing è sicuro.
Il problema non è che Dave sia stupido. Siamo tutti, in un certo senso, stupidi. È che è caduto vittima dell '[effetto Dunning-Kruger] (http://en.wikipedia.org/wiki/Dunning–Kruger_effect) e non solo non ha idea di quanto sia stupido, ma è * completamente convinto * di sapere meglio degli esperti del settore. Questo è il vero pericolo. Muto e consapevole di ciò va bene, e come dovremmo sforzarci tutti di essere. Stupido e ignaro è un male, ma è relativamente facile rimediare. Stupido e imbarazzante essere troppo sicuro di sé è estremamente pericoloso e spesso impossibile da riparare.
"Ho già studiato e creato un protocollo abbastanza standard costruito attorno a Bcrypt. Il mio protocollo non è nuovo, ma si basa su implementazioni collaudate che supportano milioni di utenti." Ti sbagli quasi quanto Dave qui. Il diavolo è nei dettagli dell'implementazione. Non scrivere il proprio algoritmo / protocollo va bene, ma __non dovresti nemmeno implementarlo__. A meno che tu non sia un esperto, non dovresti fidarti dell'hashing della password per __qualsiasi codice che hai scritto da solo__. L'unica cosa responsabile da fare è utilizzare un'implementazione nota-buona, non solo un protocollo noto-buono.
Tieni presente questa http://security.stackexchange.com/questions/6095/xkcd-936-short-complex-password-or-long-dictionary-passphrase se scegli la password.
Per favore dimmi che non sei 'Dave'
@hillsons Haha, no. Ma grazie per avermi permesso di chiarirlo;)
Se un sistema viene utilizzato per proteggere obiettivi di alto valore, il numero di persone che tentano di infrangerlo sarà maggiore rispetto a se non fosse utilizzato per proteggere qualcosa di significato ampiamente riconosciuto. Se il sistema potrebbe non essere effettivamente sicuro, la probabilità che venga violato potrebbe quindi essere più alta della probabilità che qualcuno si preoccupi di violare un sistema oscuro di cui nessuno si preoccupa.
Permettigli di ascoltare il podcast "security now" di Steve Gibson su twit: http://twit.tv/sn, ad esempio mostra # 444 https://www.grc.com/sn/sn-444.htm dove parlano dell'implementazione di "Telegram" (a metà circa dello spettacolo)
Dave parla di non voler utilizzare algoritmi pubblicati, ma usa MD5 (un algoritmo pubblicato) su PHP (progetto open source)
Ottimo articolo @StephenTouset sull'effetto Kruger
Dave è pericolosamente pessimo in crittografia. Tipo, sai, quasi tutti. Ecco perché è davvero meglio utilizzare standard controllati sviluppati da esperti.
@supercat È molto pericoloso pensare lì.I bersagli a basso profilo vengono costantemente violati.Non importa che il tuo sito web non sia una banca o un server di posta elettronica;gli hacker stanno cercando di violare qualsiasi base di utenti possibile perché hanno un elenco di e-mail e password che potrebbero essere riutilizzate su un target di alto profilo
@BooleanCheese: Il mio punto di vista non era quello di suggerire che i sistemi di basso valore sono generalmente sicuri perché sono sistemi di basso valore, ma piuttosto che hanno rischi per la sicurezza diversi dai sistemi di alto valore.Supponiamo, ad esempio, che sia necessario disporre di un dispositivo in grado di autenticare le cose che si collegano ad esso senza essere in grado di connettersi a Internet su base regolare.Se il dispositivo utilizza una catena di certificati radicata con una delle odierne autorità di certificazione a livello di root e potrebbe non avere modo di verificare la revoca, una violazione di qualsiasi CA potrebbe violare il dispositivo.Se ha usato un certificato ...
... schema radicato al suo produttore, sarebbe vulnerabile a eventuali punti deboli in quello schema, ma questo è un diverso insieme di rischi.
Undici risposte:
#1
+515
Polynomial
2012-12-18 20:58:02 UTC
view on stackexchange narkive permalink
  / ** 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:

Potresti spiegare perché questo è "BAD BAD BAD"? Ho pensato che l'hashing ripetuto o l'elaborazione degli input hash possono aiutare a contrastare gli attacchi di Rainbow Table o di forza bruta. In che modo questo introduce vulnerabilità?
@jdm La parte "BAD BAD BAD" si riferisce all'inutile mescolamento dell'hash MD5, poiché offre zero sicurezza in più, ma in questo caso l'hash "ripetuto" è mal progettato. Si basa su MD5, crypt (qualunque cosa venga configurata) e SHA1 tutto in una volta, ma esegue solo 3 calcoli. Non è neanche lontanamente abbastanza vicino per sconfiggere la forza bruta basata su GPU. L'intera cosa non porta altro che oscurità, ed è probabilmente meno sicura di "sha1 (md5 (pass + salt))" con un sale decente. È importante utilizzare un algoritmo di derivazione della chiave appropriato (vedere il primo collegamento).
Grazie. Sono ugualmente frustrato, credimi. Dave è un ragazzo eccezionale e ha svolto un lavoro eccellente in passato. La sua reazione a tutto questo mi ha colto di sorpresa. Gli mancano alcuni concetti fondamentali che potrebbero essere raccolti con una semplice ricerca su Google. Non sto cercando di essere vendicativo o crudele, ma ho smesso di cercare di spiegarglielo. Questo è esattamente il tipo di feedback di cui ha bisogno ...
@nallenscott Per essere onesti, ho attraversato la stessa fase in cui stavo imparando a programmare: volevo fare tutto da solo e sono subito caduto nella trappola di scrivere la mia "crittografia" e l'hashing. Poi ho imparato a conoscere la vera sicurezza e ho scoperto che molto di ciò che avevo scritto in precedenza era orribilmente rotto. Massiccia sveglia!
@Polynomial Assolutamente. Ed è per questo che sono qui, per aiutare ad accelerare il processo per Dave. Da qualche parte nelle risposte e nei commenti c'è un'epifania che lo guiderà lungo il sentiero dell'illuminazione. Il tuo, in particolare, è stato un vero shock :)
@Polynomial - Anch'io progettavo i miei algoritmi di crittografia e hash, ma era quando ero alle medie. È stato sicuramente utile nel fornirmi le informazioni necessarie per comprendere gli algoritmi "reali" che avrei imparato in seguito.
@Casey: offcourse, inventa sempre il tuo. Crea la tua lista collegata, la tua crittografia, il tuo database, il tuo mergesort. Implementa gli algoritmi e le strutture dati per comprenderli meglio. Quindi getta via l'implementazione: quelle esistenti sono quasi sempre migliori. In caso contrario, partecipa al progetto e miglioralo! I tuoi colleghi esamineranno le tue modifiche e forniranno feedback. Se sbagli, imparerai, se hai ragione, i tuoi cambiamenti gioveranno a tutta l'umanità;)
@Polynomial Ottimo post. Si prega di eliminare riga per riga anche [questa domanda] (http://security.stackexchange.com/q/71934/36971), se si ha tempo.
Mi piace il messaggio di override dietro questa risposta, ma mi dispiace dire che questa risposta apparentemente ** presume ** che un utente malintenzionato abbia accesso al codice, che non è un * dato *. Puoi spiegare perché, se l'aggressore ** non ** ha il codice, perché questo algoritmo è lo stesso di `sha1 (md5 (pass) + salt)`? Chiaramente non conoscere il * processo * della confusione di Dave dell'hash `md5` iniziale si traduce in una maggiore sicurezza? So che gli hash / la crittografia * dovrebbero * essere ancora sicuri dato che il codice è disponibile per tutti ... ma in tal caso, perché non dire semplicemente che `$ user` e` $ password` sono visibili nel codice ...?
@monster Vedi [Principio di Kerckhoff] (https://en.wikipedia.org/wiki/Kerckhoffs's_principle). Non progettare mai un sistema in cui si presume che l'aggressore non conosca il processo. Una funzione crittografica dovrebbe fare affidamento sulla segretezza della chiave, non sulla segretezza dell'algoritmo.
@Polynomial Grazie per il link - l'avevo letto prima (penso che sia stato tu a postare il link in un altro thread che avevo letto). Come ho detto, la risposta mi piace, e forse sono un po 'schizzinoso, ma se abbiamo accesso al codice possiamo vedere facilmente "$ user" e "$ password", quindi non importa quale codice usi è irrilevante ? Se guardi il codice di Dave puoi vedere che sta assegnando manualmente `$ user` e` $ password` - se hai il codice lo hai! Di nuovo, probabilmente solo per essere pignoli.
@monster Avere accesso al codice non è la stessa cosa che avere accesso ai * valori delle variabili in fase di esecuzione *. È uno scenario completamente diverso. Il solo fatto di avere una copia offline del codice non dovrebbe influire sulla sicurezza del sistema crittografico.
@Polynomial, Sono d'accordo. Quello che sto dicendo è che sta assegnando entrambe le variabili "$ user" e "$ pass" nel suo codice a ". Assegna le variabili a una stringa nel suo codice e possiamo vedere chiaramente la stringa.
@monster Questo è un modo comune di denotare le variabili segnaposto, ecco perché il commento dice "dati utente". Verranno compilati con i valori effettivi del codice chiamante.
Lo shuffling degli hash non fornisce arbitrariamente un po 'di sicurezza? Non puoi scaricare e utilizzare tabelle hash precalcolate, giusto? (Probabilmente mi sbaglio.)
@MateenUlhaq No, perché se sai cos'è lo shuffle (cosa che devi presumere che faccia un attaccante; cioè il principio di Kerckhoffs), puoi banalmente un-shuffle e decifrarlo a prescindere. Va anche notato che gli hash crittografici standard sono TERRIBILI per la memorizzazione delle password.
La chiamata a "summon_cthulhu ()" alla fine è in realtà la riga di codice meno pericolosa.Scarse protezioni con password che danno un falso senso di sicurezza fanno molti più danni di un Great Old One incontrollato.
Vorrei sottolineare qualcosa che è stato sorvolato: va benissimo rotolare il tuo.Vai avanti!Fallo!Finché non è in prod.
Mi chiedevo solo, il fatto che stia usando SHA1 su un hash MD5 non lo renderebbe vulnerabile quanto un hash MD5 (che non è stato salato) da solo?Cioè, un utente malintenzionato dovrebbe solo trovare una collisione MD5 perché tutto cada a pezzi, giusto?
@DividedByZero Sì, con o senza sale.
"e perché \ n?"hai chiesto confuso .... Ecco cos'è l'oscurità ^^
@monster Un utente malintenzionato intelligente può derivare l'algoritmo creando un account con una password che conosce e quindi capire i passaggi dopo aver rubato il DB.Questo presuppone che non possano semplicemente rubare l'applicazione stessa e decompilarla (o visualizzarla direttamente se è uno script), però.Gli aggressori sono infinitamente più abili nel ricavare segreti come questo di quanto i difensori vogliano credere.Ecco perché i difensori dovrebbero applicare il principio di Kerckhoff: così facendo ci evita di presumere che l'attaccante sia più stupido o meno efficiente di quanto non siano in realtà.
#2
+242
Konerak
2012-12-18 21:40:53 UTC
view on stackexchange narkive permalink

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 12 anni, ma di 10 6 anni")

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

Per algoritmi ben noti se non sei un crittografo professionista probabilmente dovrebbe essere sostituito con.
"Probabilmente scritto da persone più intelligenti di te" - stai assumendo che 'Dave' ammetta l'esistenza di questo.
Qualsiasi password potrebbe essere chiamata "sicurezza per oscurità". Ma in un buon sistema, è stato dimostrato che la password è l '** unica ** cosa che devi mantenere segreta. Un sistema non testato ha quasi certamente altri difetti, quindi mentre stai proteggendo la password, qualcuno entra usando un attacco che non ti aspettavi. Questo è il motivo per cui desideri un algoritmo che sia stato attaccato brutalmente e che sia risultato essere forte.
@NathanLong: Un punto importante sulle password / chiavi: se si sospetta che i propri segreti siano stati compromessi, si può ristabilire la sicurezza facilmente e con sicurezza ad es. tirando 25 dadi trasparenti e utilizzando i valori per generare una password o una chiave (64+ bit di entropia); qualsiasi tiro di dado sarà sostanzialmente uguale a qualsiasi altro, a condizione solo che il nemico non scopra cosa fosse.
Se per * intelligente * intendi persone più informate sulla crittografia ...
#3
+170
KeithS
2012-12-18 23:03:01 UTC
view on stackexchange narkive permalink

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.

Innanzitutto, SHA1 è di 160 bit. In secondo luogo, essere interrotti per attacchi di collisione (da 2 ^ (n / 2) a forza bruta) non ha alcuna importanza nel dominio del cracking di una password con hash (dove ti preoccupi dei (primi) attacchi pre-immagine - 2 ^ n per forza bruta); vedi: http://en.wikipedia.org/wiki/Preimage_attack. Per le firme crittografiche non è possibile utilizzare un hash interrotto da collisione (e SHA1 viene interrotto in 2 ^ 61 tempo) (poiché i messaggi firmati potrebbero essere alterati). (Anche se la semplicità e la velocità di MD5 e l'esistenza di grandi tabelle arcobaleno significano che non è un problema per le password.) D'accordo con i tuoi argomenti per bcrypt però.
Eliminata lunga discussione su attacchi preimage, collisioni, forza di hashing, ecc
Per ulteriori informazioni sugli attacchi di collisione rispetto agli attacchi pre-immagine ispirati alla vecchia forma di questa domanda, vedere la [seconda metà della mia risposta] (http://security.stackexchange.com/a/25598/2568).
Uso MD5 per creare bei colori nei miei script grafici, non per proteggere le password
Forse la cosa più ottimale sarebbe eseguire il tuo hash sia attraverso SCrypt * che * BCrypt e quindi otterrai i vantaggi di entrambi, e le vulnerabilità in uno di essi non banalizzeranno il tuo hash.
@Muhd - Il problema con la tua supposizione è che entrambi gli algoritmi sono progettati per aggiungere una quantità di complessità temporale non banale ma accettabile al calcolo (e la quantità di complessità può essere variata per ottenere questo equilibrio). Eseguirli in serie significa o raddoppiare il tempo che un utente deve attendere per una verifica della password legittima oppure la forza di ogni algoritmo deve essere ridotta della metà. La complessità è nemica della sicurezza; più interferisce con lo status quo, più è probabile che il tuo sistema venga "attaccato" dai tuoi utenti.
@KeithS Usando la stessa quantità di tempo, e presumendo che non ci sia alcun attaccante con un exploit per nessuno dei due algoritmi, avrai una maggiore sicurezza usando la metà del tempo per SCrypt che per usare tutto il tempo per BCrypt. SCrypt è di ordini di grandezza più potente, a condizione che non ci siano vulnerabilità. Inoltre, la "complessità" non è nemica della sicurezza fintanto che le persone che costruiscono / mantengono il sistema possono comprenderla, sebbene possa essere nemica della convenienza. E non ci sono inconvenienti per l'utente finale con l'hashing della password poiché è tutto dietro le quinte.
@mplungjan Bella idea!
Oh mio Dio, odio così tanto le aziende quando richiedono la reimpostazione di una password ogni 90 giorni, è così frustrante.Non farlo.La tua azienda non è speciale, a meno che tu non sia Facebook o Google, è improbabile che i tuoi utenti visitino la tua pagina così spesso, chiedi ai tuoi utenti di reimpostare la password quasi ogni volta che visitano il tuo sito web, il che è assurdo.
#4
+100
dr jimbob
2012-12-18 22:33:10 UTC
view on stackexchange narkive permalink

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 5 ) (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 128 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 128 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 64 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.

#5
+69
Rory Alsop
2012-12-19 17:24:43 UTC
view on stackexchange narkive permalink

enter image description here

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)

Divertente e d'accordo con il sentimento, ma è irrilevante in quanto non ha scritto il suo codice. Ha preso le funzioni crypto-hash esistenti `MD5` e` SHA1` insieme alla funzione di permutazione personalizzata `dumb_perm` (` dumb_perm ('00112233445566778899aabbccddeeff') `va a` 'ccddeeff8899aabb0011223344556677'`), quindi `hash = SHA1per (MD5 (pw))) "e hanno creato il loro sale in un modo eccessivamente complicato. Sebbene abbiano aumentato i costi di manutenzione per nessun guadagno in termini di sicurezza, non stanno creando il proprio codice: il difetto è che gli hash semplici sono troppo veloci al giorno d'oggi, quindi è necessario rafforzare la chiave.
Penso che il problema più grande sia che l'esempio della domanda è più un caso di indebolimento delle chiavi che di rafforzamento delle chiavi. Potrebbe non essere un nuovo codice, ma sta cadendo nelle stesse insidie.
Cifrario @drjimbob! = Hash
@bradley.ayers - Capisco la differenza (i cifrari vengono utilizzati per la crittografia; l'hashing non è crittografia in quanto non è reversibile.) L'immagine del meme ha usato per la prima volta la parola "cifratura" e non ho criticato Rory in quanto funzione di hash crittografica come MD5 e SHA1 si basano su algoritmi simili ai cifrari a blocchi: http://en.wikipedia.org/wiki/Cryptographic_hash_function#Hash_functions_based_on_block_ciphers Tuttavia, Dave non ha creato le proprie funzioni di cifratura / hash o qualcosa di simile. Ha semplicemente eseguito una muta permutazione di un MD5 in un passaggio di uno schema di hashing debole (`sha1 (salt + md5 (pw)`).
Non si scrive semplicemente la propria cifra che suona meglio
Vale la pena sottolineare che Rivest e gli amici non hanno lanciato la propria crittografia. Hanno dedicato parti significative della loro vita a lanciare criptovalute per tutti gli altri. Personalmente, non metterei davanti a una grande azienda con miliardi da proteggere l'assunzione di alcuni crypto guru professionisti per lanciare criptovalute (perché suona come un termine di droga) per l'uso all'interno dell'azienda.
#6
+45
Mark Burnett
2012-12-20 02:58:41 UTC
view on stackexchange narkive permalink

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.

In effetti l'algoritmo di Dave è essenzialmente HMAC salato con una piccola svolta. Sembra essere forte come l'HMAC. Ad esempio, l'attaccante non sarà in grado di utilizzare la tabella arcobaleno di qualcun altro. La mia più grande preoccupazione con questo sistema è dove viene immagazzinato il sale.
@qarma HMAC sta usando il segreto (cioè la password) due volte, questo algoritmo lo sta usando solo una volta.
#7
+30
GdD
2012-12-18 21:11:11 UTC
view on stackexchange narkive permalink

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.

Credi ancora che in tutti i sistemi aperti si trovino e si correggano tutti i buchi e quindi siano i sistemi più sicuri, se si considerano le fughe di notizie degli ultimi anni che hanno rivelato che NSA e CIA tengono per sé le vulnerabilità e sviluppano exploitfuori di loro per vari motivi appena legali?Se possono farlo (i cosiddetti "bravi ragazzi"), non possono farlo anche i cosiddetti "cattivi" ("hacker cinesi / russi" e così via)?
Stai confondendo il design con l'implementazione @a20, in ogni caso non penso che essere chiuso aiuti, la maggior parte delle vulnerabilità su cui si trova il governo degli Stati Uniti sono nei sistemi chiusi, ad esempio i sistemi operativi MS.
"la maggior parte delle vulnerabilità su cui si trova il governo degli Stati Uniti sono in sistemi chiusi" .. punto giusto.Cosa intendevi per confondere il design con l'implementazione?
@a20 Sono davvero in ritardo a questa festa, ma immagino che GdD si riferisse al fatto che quelle vulnerabilità del mondo reale di cui parli sono raramente difetti fondamentali in uno standard crittografico, più spesso sono difetti nelil modo in cui un prodotto software utilizza o implementa lo standard.Ad esempio, se scrivo un'implementazione di un protocollo aperto che è vulnerabile perché ho usato un timestamp invece di un crypto-PRNG come seed, quella vulnerabilità è la prova di una debolezza nella mia implementazione, non necessariamente nel protocollo aperto.E i sistemi chiusi sono probabilmente più suscettibili qui.
#8
+19
Sarel Botha
2012-12-18 22:22:56 UTC
view on stackexchange narkive permalink

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.

Solo perché possono accedere al DB, non significa che abbiano accesso al suo codice.
@jmoreno Still non giustifica il suo schema inutile.
@Thomas: è vero, e il motivo per rifiutare bcrypt è semplicemente insopportabile, ma ciò non significa che il tuo codice non possa aggiungere (o rimuovere) valore dall'utilizzo delle librerie e delle pratiche standard.
@jmoreno In generale, la sicurezza per oscurità è percepita come una stampella per pratiche di crittografia scadenti, e spesso lo è. Ciò non significa che non abbia valore: ha i suoi usi, ma in questa situazione non è garantito.
@jmoreno, ha ragione, ecco perché ho detto "probabilmente". Il punto principale è che l'hashing deve richiedere tempo.
#9
+11
Phillip Schmidt
2012-12-20 22:10:56 UTC
view on stackexchange narkive permalink

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)

Sì, puoi scrivere da solo, ma la maggior parte delle persone che pensano di essere qualificate per scrivere da soli non sono qualificate per scrivere da soli. È facile giudicare quanto siamo intelligenti, ma difficile giudicare quanto siamo stupidi.
Penso che il motivo per il mescolamento sia quello di rendere l'algoritmo diverso da qualsiasi cosa si aspetti un attaccante (che non conosce l'algoritmo). L'uso di un input di sale segreto specifico dell'applicazione (noto anche come "pepe") ha lo stesso effetto ed è più affidabile.
Per quanto riguarda # 3: un hash MD5 mescolato non può essere cercato in una tabella arcobaleno.
#10
+10
LateralFractal
2013-09-11 13:55:10 UTC
view on stackexchange narkive permalink

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

#11
+7
Mark Buffalo
2015-11-17 02:38:46 UTC
view on stackexchange narkive permalink

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.

E se non hai accesso al codice come presumi?
@monster Ovviamente ho accesso al codice. È PHP e sta cercando di proteggere il suo database, che ho già rubato. Lo scopo dell'hashing delle password è proteggere i tuoi utenti una volta che sei stato violato. Se riesco a recuperare il tuo database, ottenere il resto dei file importanti sul server web è un compito banale.
Cerchiamo di [continuare questa discussione in chat] (http://chat.stackexchange.com/rooms/32054/discussion-between-mark-hulkalo-and-monster).
@MarkBuffalo `Ovviamente ho accesso al codice.È PHP e sta cercando di proteggere il suo database` Ci sono molte situazioni in cui SQLi può consentire di scaricare il database senza ottenere i file PHP.Ovviamente, questo significa anche che Dave dovrebbe usare solo un peperone, dal momento che realizza lo stesso modello di minaccia ma non è così ... rotto.


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