La risposta breve

La risposta breve è: "Così non sarai colpito da una azione legale collettiva da $ 5 milioni." Questo dovrebbe essere un motivo sufficiente per la maggior parte dei CEO. L'hashing delle password è molto più economico.

Ma ancora più importante: il semplice hashing delle password come suggerito nella tua domanda non è sufficiente. Avrai comunque la causa. Devi fare di più.

Perché devi fare di più richiede un po 'più di tempo per spiegarlo. Quindi prendiamo per un momento la strada più lunga in modo che tu capisca cosa stai spiegando, quindi faremo il giro per la sinossi di 5 minuti.

L'hashing è solo l'inizio

Ma iniziamo con quello. Supponiamo che tu memorizzi le password dei tuoi utenti in questo modo:

  # id: user: password1: alice: pizza2: bob: passw0rd3: carol: baseball  

Adesso , supponiamo che un utente malintenzionato riesca a ottenere più accesso al tuo sistema di quanto desideri. È lì solo per 35 secondi prima di rilevare il problema e chiudere il buco. Ma in quei 35 secondi è riuscito a impossessarsi del database delle password. Sì, hai commesso un errore di sicurezza, ma ora lo hai risolto. Hai corretto il buco, corretto il codice, aggiornato il tuo firewall, qualunque esso fosse. Quindi va tutto bene, ora, giusto?

Beh, no, ha il tuo database di password.

Ciò significa che ora può impersonare ogni utente sul tuo sistema. La sicurezza del tuo sistema è distrutta. L'unico modo per recuperare è ricominciare da capo con un NUOVO database di password, costringendo tutti a cambiare la propria password senza utilizzare la password esistente come una valida forma di identificazione. Devi contattarli fuori banda attraverso un altro metodo (telefono, e-mail o qualcosa del genere) per verificare la loro identità per ricreare le loro password e, nel frattempo, l'intera tua operazione è morta nell'acqua.

E se non lo vedessi rubare il database delle password? In retrospettiva, è abbastanza improbabile che tu lo veda effettivamente accadere. Il modo in cui probabilmente lo scoprirai è notando attività insolite sugli account di più utenti. Forse per mesi è come se il tuo sistema non avesse alcuna sicurezza e non puoi capire perché. Questo potrebbe rovinare il tuo business.

Quindi abbiamo hash

Invece di memorizzare la password, memorizziamo un hash della password. Il tuo database ora è simile a questo:

  # id: user: sha11: alice: 1f6ccd2be75f1cc94a22a773eea8f8aeb5c682172: bob: 7c6a61c68ef8b9b6b061b28c348bc1ed7921cb533eea8f8aeb5c682172: bob: 7c6a61c68ef8b9b6b061b28c348bc1ed7921cb533eea8f8aeb5c682172: bob: 7c6a61c68ef8b9b6b061b28c348bc1ed7921cb533eea8f8aeb5c682172: bob: 7c6a61c68ef8b9b6b061b28c348bc1ed7921cb533d si memorizza è un token opaco che può essere utilizzato per  verificare  se una password è corretta, ma non può essere utilizzato per  recuperare  la password corretta.  
 Bene, quasi. Google quegli hash, ti sfido. 
 
 Quindi ora siamo passati alla tecnologia degli anni '70. Congratulazioni. Possiamo fare di meglio. 
 
 Quindi saliamo 
 
 Ho passato molto tempo a rispondere alla domanda sul perché salare gli hash, inclusi esempi e dimostrazioni di come funziona nel mondo reale. Non ripeterò la discussione sull'hash qui, quindi vai avanti e leggi l'originale: 
 
  Perché gli hash salati sono più sicuri? 
 
 Piuttosto divertente , eh? OK, quindi ora sappiamo che dobbiamo salare i nostri hash o potremmo anche non aver mai hash le password per cominciare. Ora siamo alla tecnologia degli anni '90. Possiamo ancora fare di meglio. 
 
 Quindi iteriamo 
 
 Hai notato quel bit in fondo alla risposta che ho collegato sopra, giusto? Qualcosa su bcrypt e PBKDF2? Sì, si scopre che è davvero importante. Con la velocità con cui l'hardware può eseguire i calcoli di hashing oggi ( grazie, bitcoin!), un utente malintenzionato con hardware pronto all'uso può far saltare in aria l'intero file di password con hash in poche ore , calcolando miliardi o addirittura trilioni di hash al secondo. Devi rallentarli. 
 Il modo più semplice per rallentarli è semplicemente fargli lavorare di più. Invece di calcolare un hash per controllare una password, devi calcolare 1000. O 100.000. O qualunque numero si adatti alla tua fantasia. Puoi anche usare  scrypt  ("ess-crypt"), che non solo richiede molta potenza della CPU, ma anche molta RAM per fare il calcolo, rendendo l'hardware dedicato che ho collegato sopra in gran parte inutile . 
 
 Questo è lo stato dell'arte attuale. Congratulazioni e benvenuto nella tecnologia  odierna . 
 
 Abbiamo finito? 
 
 Quindi ora cosa succede quando l'aggressore prende il tuo file di password. Bene, ora può batterlo offline invece di fare tentativi online contro il tuo servizio. Purtroppo, una buona parte dei tuoi utenti (dal 4% al 12%) avrà utilizzato la password "123456" o "password" a meno che tu non glielo impedisca attivamente e l'aggressore proverà a indovinarle prima. 
 
 Se vuoi mantenere gli utenti al sicuro, non lasciare che utilizzino "password" come password. O uno qualsiasi degli altri primi 500, se è per questo.  È disponibile un software per rendere facile (e gratuito) il calcolo accurato della sicurezza della password. 
 
 Ma anche l'autenticazione a più fattori non è mai una cattiva idea. È  facile da aggiungere a qualsiasi progetto. Quindi potresti farlo anche tu. 
 
 Ora, i tuoi 5 minuti di gloria 
 
 Sei di fronte al tuo capo, ti chiede perché devi  usare PBKDF2 o simili  per sottoporre ad hashing le tue password. Citi la class action di LinkedIn e dici: "Questo è il livello minimo di sicurezza  legalmente  previsto nel settore. Qualcosa di meno è letteralmente negligenza". Questo dovrebbe richiedere molto meno di 5 minuti e, se il tuo capo non è convinto, non stava ascoltando. 
 Ma potresti continuare: "Il costo di implementazione della tecnologia di hashing è trascurabile, mentre il costo di  non  implementazione potrebbe essere di milioni o superiore". e "In caso di violazione, un database con hash adeguato consente di posizionarsi come un'organizzazione ben gestita e attenta alla sicurezza, mentre un database sottoposto ad hashing in modo improprio è un imbarazzo molto pubblico che, come la storia ha dimostrato molte volte,  non  essere ignorato o trascurato minimamente dai media. "
 
 Se vuoi essere tecnico, puoi ri-modificare quanto sopra. Ma se stai parlando con il tuo capo, dovresti saperlo meglio di così. E le analogie sono molto meno efficaci del semplice mostrare gli effetti della vita reale che sono perfettamente visibili senza il rivestimento di zucchero necessario. 
 
  Non si fa in modo che le persone indossino guanti protettivi raccontando una buona analogia . Invece metti un po 'di carne per il pranzo nel becher e quando esplode in fiamme verdi e blu dici "è quello che succederà al tuo dito".  
 
 Usa lo stesso principio qui. 

Questo thread è un po 'corto di analogie, quindi ecco qui:

Una password senza hash è come un lucchetto trasparente, chiunque la esamini adeguatamente può progettare la chiave di corrispondenza.

Per iniziare, ne fornirò uno con cui iniziare:

Immagina di gestire una banca. Non vuoi consentire ai tuoi clienti l'accesso diretto al denaro. Quindi hai un cassiere che ha solo un computer e una piccola somma di denaro per gestire prelievi e depositi quotidiani. Non può accedere a tutto, né può passare segreti al cliente, perché non ha accesso a questi segreti.

Un cassiere va tutto bene e dandy, ma a volte c'è una persona che lo vuole rapina la banca e non verrà fermato dal cassiere. Per contrastare questo problema, hai una cassaforte davvero grande nel seminterrato che contiene tutti i soldi veri dei tuoi clienti. questa cassaforte ha un sacco di sicurezza, come uno scanner di impronte digitali, riconoscimento vocale, pressostati, serrature a tre chiavi e una serratura temporizzata. è progettato per tenere fuori tutti coloro che non dovrebbero essere presenti e che non sanno come superare i controlli di sicurezza.

Questa cassaforte fermerà il 99% dei ladri, ma c'è sempre quell'1% che riesce a superare tutta quella sicurezza, aggirandola o brutalizzandola. Nel caso in cui ciò accada, una banca immagazzina i propri soldi in contenitori con trappole esplosive, che li rendono inutilizzabili, attraverso mezzi come farli saltare in aria o spruzzare vernice dappertutto. In questo modo, il ladro non può utilizzare il denaro o deve impiegare molto tempo per renderlo nuovamente utilizzabile.

Anche un'applicazione software ha questi sistemi: il programma che l'utente usa è il cassiere: non può fargli fare quello che vuole a meno che non trovi un modo per parlarne dolcemente in cooperazione. la configurazione hardware e software che protegge il programma e il database è il caveau della banca: tiene lontane le persone che non sanno quali sono i punti deboli della configurazione di sicurezza utilizzata. Memorizzare la password in chiaro significa che se qualcuno supera il programma e la configurazione di sicurezza, ha libero accesso alle password. Proprio come una banca conserva il denaro in un contenitore che rende l'accesso al denaro molto più difficile, l'hashing della password offre alla persona che compromette le tue password un enorme ostacolo che deve superare. Significa anche che i dipendenti (sia la banca, il software e quelli della nostra stessa azienda) non possono essere messi sotto pressione, costretti o chiacchierati con dolcezza per aggirare la sicurezza per un truffatore, perché nemmeno loro possono accedere direttamente ai soldi / password. Possono accedere solo ai contenitori / hash.

Mi piace l'analogia come un modo per spiegare la tecnologia, tuttavia in questo caso probabilmente non è realizzabile in quanto l'analogia sarebbe troppo complessa.

La maggior parte dei manager è più motivata a evitare rischi personali per la propria posizione piuttosto che a fare la cosa giusta, quindi piuttosto che un'analogia utilizzerei esempi in cui la memorizzazione delle password in testo normale si è riflessa negativamente su un'azienda. Direi solo qualcosa come

"Memorizzare le password in testo normale ci farebbe sembrare molto cattivi, rischiando la nostra reputazione e possibilmente aprendoci a contenzioso. È considerata una pessima pratica in qualsiasi settore e lì sono siti web dedicati a nominare e svergognare le aziende che memorizzano le password in chiaro. Personalmente, non mi piacerebbe essere quello in piedi di fronte al consiglio / capo / CTO a spiegare perché non abbiamo messo in atto un controllo di sicurezza di base. Se eseguiamo l'hashing delle password dei nostri clienti, una violazione dei dati non provocherebbe una fuga immediata di password che gli hacker potrebbero utilizzare e si vedrebbe che stiamo proteggendo le informazioni dei nostri clienti. L'hashing delle password mitiga un grosso rischio con poco sforzo. "

Includere link a trasgressori di testo normale, quindi inviare Mi piace ad alcune notizie come Cupid Media, Microsoft India Store, ecc. .

Usare le analogie può essere potente, ma in questo caso, penso che sarebbe molto più semplice spiegare con un linguaggio semplice cosa sta succedendo. Qualcosa di simile dovrebbe essere efficace, ma probabilmente dovrebbe includere diapositive powerpoint con illustrazioni e caratteri aziendali di grandi dimensioni.

Come sai, richiediamo alle persone di utilizzare le password in modo da sapere chi sono quando sono utilizzando il nostro prodotto. Dobbiamo tenere traccia di queste password per consentire alle persone di accedere. Il problema è che non possiamo memorizzare le password esattamente come vengono inserite, perché gli aggressori hanno trovato il modo di vederle e rubarle.

Inoltre, non possiamo semplicemente riscrivere le password in un codice intelligente e credere che saremo gli unici a saper tradurre il codice, perché questo ancora non lo garantisce gli aggressori determinati non riescono a capire il codice e inoltre non protegge dagli attacchi dall'interno della nostra organizzazione, come ex dipendenti disonesti.

Per risolvere questo problema, noi deve utilizzare un hash della password unidirezionale . Un hash della password è come usare un codice, tranne per il fatto che è impossibile decodificarlo. * In questo modo, solo l'utente conosce la propria password. Memorizziamo solo l'hash della password e lo controlliamo quando l'utente effettua il login. Ciò mantiene i nostri utenti al sicuro e riduce la nostra responsabilità in caso di violazione dei dati, che può avere gravi ripercussioni. [Includi esempi di aziende che sono state citate in giudizio per archiviazione insicura delle password]

* [So che non è impossibile, ma probabilmente il profano non ha bisogno di così tanto dettaglio.]

Tutte le spiegazioni finora sono un po 'lunghe, eccone una breve:

Alcune persone che non riescono a ricordare il loro spillo bancario, tengono una nota nel portafoglio.

Se un ladro o un conoscente riuscissero a guardare dentro il portafoglio, avrebbero un problema, A MENO CHE il pin non sia scritto in un modo che non possono leggerlo.

L'hashing è fondamentalmente scrivere del testo in un modo che nessun altro può leggerlo.

Immagina di essere il buttafuori di un club. Per sapere se far entrare le persone, hai un codebook di nomi / alias delle persone (alcune persone preferiscono essere discrete e sono conosciute solo da un alias) e le proprie password private; non puoi riconoscere che le persone sono o non sono chi dicono di essere dalla loro voce o aspetto (ci sono troppe persone e, a causa degli pseudonimi, i controlli d'identità sono un no-go), quindi devi solo andare fuori dal libro (il server web non può dirti guardandoti che sei la persona sbagliata) . Le persone devono dirti sia il loro nome che la password per entrare e, se non corrisponde al tuo libro, vengono respinti.

Se qualcuno ottiene una foto del tuo libro dei codici (il tuo DB è trapelato) , possono impersonare chiunque voglia , senza che tu sia in grado di dire che stanno mentendo. Alcuni dei tuoi clienti usano lo stesso nome e la stessa password anche presso la loro banca (che hanno cassieri che lavorano con codebook proprio come te), e quindi avrebbero rubato soldi in quel modo. Saresti quindi licenziato per aver consentito una violazione così grave, facendo sembrare il club molto brutto e costato loro denaro.

Fortunatamente, puoi acquistare una scatola nera (funzione hash) che prende il loro nome (salt) e la password e ti dà un lungo numero dall'aspetto casuale (hash) che sarà sempre lo stesso per un determinato nome e password e diverso per qualsiasi altra combinazione di nome e password. Quindi ora invece del tuo codebook contenente [nome e password], puoi farlo contenere solo [nome e numero]! Quando una persona vuole entrare, ti dice il suo nome e la password, li inserisci nella tua scatola nera e cerchi il suo nome nel tuo codebook per verificare che il numero che la tua scatola nera ti ha dato corrisponda a quello registrato.

Ora, se qualcuno ottiene una foto del tuo codebook, non sarà ancora in grado di entrare! Non sarà nemmeno in grado di dire se metà delle tue persone usa la stessa password, perché ogni combinazione [nome e password] inserita nella scatola nera era unica. Hanno una scatola nera proprio come la tua e possono inserire un certo nome e password casuali fino a quando non trovano il numero giusto, ma devono farlo individualmente per ogni persona.

Se scopri che era trapelato, dovresti comunque chiedere ai tuoi clienti di cambiare le loro password per la massima sicurezza, ma gli aggressori non avranno un momento facile per entrare.

Spiegalo in termini di linee di difesa.

Ovviamente, farai tutto il possibile per assicurarti che il tuo codice sia sicuro. Ma il fatto è che il tuo server non eseguirà solo il codice che hai scritto e non hai alcun controllo sul codice scritto da altre persone. Anche se tutto il resto del codice sulla macchina è open-source, dovresti assumere altri 2-3 sviluppatori a tempo pieno per assumerti la responsabilità dei tuoi rami di tutto. Dal momento che -non ci prendiamo in giro- si suppone che l'intera faccenda sia una misura di riduzione dei costi, non è fattibile.

Quindi, anche se avessi assoluta fiducia nel tuo codice, ci sarebbe c'è ancora molto spazio perché le cose vadano male. È quindi necessario un modo per garantire che anche se un utente malintenzionato entra nella macchina, le tue password siano comunque al sicuro. È qui che entra in gioco l '"hashing" (tra virgolette perché gli algoritmi corretti da usare al giorno d'oggi non sono realmente algoritmi di hashing , ma è comunque un termine utile e generico) .

In termini militari, questo è essenzialmente come (e perché) imposti più linee di difesa. Nessun generale mette l'intero esercito nello stesso punto, perché devi tenere conto della possibilità che qualcosa che non avevi previsto permetta di sconfiggere o aggirare le tue linee del fronte. L'hashing è la tua guardia di casa: la cosa che proteggerà le tue password quando tutto il resto ha fallito. Speri che questo non sia mai necessario, ma il costo di non averlo quando ne hai bisogno è semplicemente troppo alto: le cause multimilionarie sono solo l'inizio.

Come spiegare.

• Gli esseri umani sono umani, non importa quanto siano modernizzati; lì le password saranno qualcosa come la data di nascita o il nome della ragazza / fidanzato / animali da compagnia ecc. ecc.

Quindi, è una minaccia salvare la password in chiaro. Chiunque può leggerlo.

• L'hashing aiuta a renderli illeggibili per gli esseri umani (incluso il fedele amministratore di sistema).

Una volta che una password è stata sottoposta ad hashing, è praticamente impossibile recuperare indietro. quindi, non c'è paura che la tua password venga rubata da qualcuno. Anche se qualcuno ottiene l'hash, è inutile.

• Possiamo dire che se la password è un "frutto", l'hashing sarà "succo". quindi, il succo è sufficiente per verificare la password dell'utente quando prova ad accedere.

Lo svantaggio dell'hashing della password è : nessuno può recuperare il pass originale. In tal caso, il sistema deve richiedere all'utente di inserire Nuova password

.

1. Spiega che le password vengono sempre rubate e, quando accade, le aziende sono VERAMENTE imbarazzate e aperte a cause legali se le password sono in chiaro.
2. Spiega che l'hashing è davvero facile da fallo oggi.
3. Ora per l'analogia:

La migliore analogia di una funzione hash unidirezionale con i non esperti è semplicemente usare una ricerca numerica analogia: dimentica la complessa crittografia. Quando un utente ti fornisce originariamente la password, assegni un numero univoco alla password utilizzando una scatola nera e memorizzi il numero come password dell'utente invece della password originale.

Quando l'utente ti dà di nuovo una password in seguito per l'autenticazione, passi la password fornita nella scatola nera e ottieni un numero. Ora puoi confrontare quel numero con il numero che hai salvato in precedenza: se i due numeri corrispondono, le password sono le stesse, se i due numeri non corrispondono, le password non sono le stesse.

Ogni password univoca passato nella casella ottiene il suo numero univoco e ogni volta che la stessa password viene passata nella casella nera esce lo stesso numero.

Il modo in cui la casella nera esegue la ricerca del numero è molto noto e qualsiasi problema con la scatola nera viene risolto dal settore - tutte le vulnerabilità vengono risolte dal settore - LA TUA azienda non è responsabile se c'è un problema con la scatola nera.

Infine, se il il numero viene rubato dal database dell'azienda, la scatola nera ben nota non funziona al contrario: non puoi prendere un numero rubato e recuperare la password (supponendo che la password originale fosse forte).

La risposta fondamentale, che non ho ancora visto affermare direttamente da nessuno, è che le azioni di chiunque sia in grado di scoprire una password non possono essere distinte in modo affidabile dalle azioni del suo legittimo proprietario. Se si vuole essere in grado di dimostrare che il legittimo proprietario ha eseguito un'azione o tramite la propria azione ha esposto la password a una persona non autorizzata, è necessario assicurarsi che il legittimo proprietario non sia mai tenuto a fare qualcosa che consentirebbe a qualcun altro di determinare la password.

Se la password di Fred è memorizzata in un database in un modo che non è codificato oltre il recupero, allora Fred potrebbe contrastare qualsiasi accusa di illecito affermando che la sua password potrebbe essere stata utilizzata o trapelata da qualcuno con accesso al database delle password. A meno che non venga utilizzato hardware specializzato per memorizzare le password , non ci sarebbe modo di confutare la contro-affermazione di Fred.

Nota che per una sicurezza reale, Fred non dovrebbe mai esporre la sua password a nient'altro rispetto alle apparecchiature antimanomissione di cui ha motivo di fidarsi. Altrimenti, ci sarebbe il rischio che l'attrezzatura in cui Fred digita la sua password venga manomessa in modo tale da far trapelare la password senza hash ad un avversario.

Immagina di essere Scrooge McDuck. È da un po 'che tieni le tue pile di soldi in un caveau gigante, ma c'è un problema con questo: se un ladro riesce ad accedere al caveau, tutti i tuoi soldi andranno persi in una volta! Non va bene. Quindi, anatra intelligente che sei, decidi di dividere i tuoi soldi in tante pile più piccole e metterle ognuna nella sua cassaforte separata. Ora, se il ladro riesce mai ad accedere a un caveau, andrà perso solo una piccola quantità del tuo denaro e potrai facilmente sostituire il caveau compromesso. Molto meglio! Tranne che ora hai un nuovo problema: come ricordare le combinazioni di tutte quelle diverse volte? Non puoi usare la stessa combinazione per ognuna, perché se il ladro ci mettesse le mani sopra avrebbe accesso a tutti i tuoi soldi e non staresti meglio che se lo avessi lasciato in un gigante mucchio!

Decidi di scrivere tutte le combinazioni (insieme al caveau a cui vanno a finire ognuna) su un foglietto di carta, e poi metti quel foglio nel suo caveau separato. Ora devi solo ricordare una combinazione, ma i tuoi soldi sono comunque tenuti separati. Questo è un miglioramento, ma è comunque problematico, perché se un ladro riuscisse a trovare e aprire la cassaforte con dentro la carta, sarebbe ancora in grado di prendere tutti i tuoi soldi. Non vuoi che ciò accada mai!

Allora cosa fai? Ebbene, la soluzione ideale sarebbe scrivere le combinazioni in una sorta di codice. Vorresti un codice che un ladro non può utilizzare per recuperare tutte le combinazioni originali, ma che puoi comunque utilizzare per accedere ai tuoi soldi. Sfortunatamente, non c'è davvero un modo per farlo per soldi nei caveau. Fortunatamente, è possibile per gli account utente protetti da password, perché in realtà non abbiamo bisogno di conoscere le password dei nostri utenti, dobbiamo solo sapere che loro le conoscono.

Tenere i tuoi soldi in una gigantesca cassaforte è come avere un'unica password principale per l'intero sistema. Tenere i soldi in diverse casseforti e annotare tutte le combinazioni è come tenere separati i dati dei tuoi utenti in account protetti da password, ma poi mantenere tutte le loro password in chiaro in un'unica posizione: fintanto che un utente malintenzionato conosce o può indovinare dove quella posizione è, non è davvero diverso dall'avere un'unica password principale. Hai bisogno di un modo per codificare il tuo elenco di password in modo tale da poterlo ancora utilizzare per verificare che un utente abbia la password corretta , assicurandoti che un utente malintenzionato non possa utilizzare il list per recuperare le password stesse . In poche parole, questo è ciò che fa l'hashing.

Supponiamo che il tuo database con le password sia trapelato o rubato:

Se le password sono in testo normale, tutte le tue password appartengono a noi.

Se le password sono sottoposte ad hashing, tutte le password sono ancora in un caveau di una banca condiviso che deve essere violato.

Se le password vengono sottoposte ad hashing e salate, ciascuna password si trova nel proprio caveau di una banca privato.

Ora dell'analogia:

1. Memorizzare password in chiaro è come lasciare la casa sbloccata.
2. Crittografare il database delle password è come conservare la chiave sotto lo zerbino.
3. L'hashing delle password è come usare un blocco numerico a 3 cifre condiviso da tutti gli utenti.
4. Salare gli hash delle password fornisce a ogni utente il proprio blocco numerico.
5. PBKDF fornisce quei blocchi numerici più cifre.

Nessuno dovrebbe effettivamente decidere questioni di sicurezza sulla base di un'analogia, ma queste potrebbero aiutare a spiegare a un profano perché è importante prendere precauzioni.

Per le funzioni di hashing, nessuna analogia pronta si trova nella sfera del calcio o delle automobili. Il meglio che possiamo fare è svelare i fatti reali.

Caro capo,

In un mondo perfetto, gli utenti dovrebbero essere attenti alla sicurezza e non userebbero mai lo stesso (o anche un simile ) password per due o più siti o servizi diversi. In quel mondo perfetto, una password avrebbe poco valore per un aggressore. Dopo aver compromesso il database degli utenti e aver appreso le password, quelle password non sarebbero utili per ottenere l'accesso ad altri sistemi.

Nel mondo reale, gli utenti riutilizzano le password, quindi la segretezza delle password deve continuare ad essere sorvegliato anche quando un sistema è stato violato, al fine di limitare i danni.

L'hashing aiuta a proteggere le password, perché l'unico modo per ottenere una password dall'hash è un calcolo di forza bruta che richiede tempo. Quel calcolo prima romperà le password deboli che sono brevi o basate su parole del dizionario e frasi comuni. Ci vuole molto più tempo per violare password complesse, ma dato abbastanza tempo, anche quelle cadranno.

Tuttavia, poiché ci vuole tempo per decifrare le password con hash, gli utenti del sistema compromesso che tendono a riutilizzarli le password, o utilizzare password simili, potrebbero avere tempo sufficiente per essere avvisate e modificare le proprie password su altri sistemi, prima che l'aggressore tenti di accedere ai propri account. (Quelli con password molto deboli avranno poco o nessun tempo, sfortunatamente, perché le password deboli possono essere "violate" dagli hash molto rapidamente. La difesa contro sono le protezioni nel sistema che impediscono agli utenti di utilizzare password deboli.)

Senza hashing, l'attaccante può passare immediatamente ad accedere ad altri sistemi dopo aver rubato le password dal sistema compromesso. Quando gli amministratori vengono a conoscenza della violazione, è già stato eseguito l'accesso ad altri sistemi, almeno per quegli utenti che riutilizzano le password.

Esiste una seconda minaccia: quella dell'accesso surrettizio. Ciò riguarda anche quegli utenti che non riutilizzano le password. Supponiamo che il database delle password di un sistema sia trapelato, ma questo evento non venga rilevato. L'autore dell'attacco può utilizzare le password per accedere di nascosto al sistema per mesi o anni dopo la violazione. Non solo l'aggressore ha rubato informazioni che erano attuali al momento dell'incidente, ma può continuare a rubare informazioni semplicemente accedendo a quegli account per i quali ha password, fintanto che queste non cambiano.

Le password con hash aiutano a proteggersi da questa minaccia, in particolare se combinate con una politica di modifiche regolari delle password e password complesse. Le password con hash che sono forti assicurano che l'attaccante debba eseguire un lungo calcolo per scoprire una password dall'hash. La politica di modifica della password aiuta a garantire che, al termine di questo calcolo, la password scoperta sia probabilmente inutile perché è stata modificata.

Analogia: in qualità di fabbro, posso (con il permesso dei clienti) tenere traccia di ciò che ho fatto per loro, inclusi i dettagli delle loro chiavi. Ma questo mi mette a rischio che il mio negozio venga irrotto e l'elenco rubato (o che un dipendente malvagio lo faccia) - nel qual caso il truffatore potrebbe creare le chiavi di molte case, e sarei responsabile di non averlo protetto informazioni migliori.

La soluzione per le chiavi è di non memorizzare MAI le informazioni sulla chiave in testo normale. Memorizzalo crittografato e non annotare mai le informazioni necessarie per decodificare questi dati. Se qualcuno ruba l'elenco crittografato, non può danneggiarlo.

Ovviamente, per un computer, "non scrivere mai" significherebbe che non può decodificare le password. Ma possiamo risolvere questo problema creando un sistema in cui non dobbiamo effettivamente decodificarli. Invece, prendiamo la password digitata dall'utente, la codifichiamo e confrontiamo la versione codificata con la password codificata che abbiamo memorizzato. Se corrispondono, l'utente ha digitato la password corretta. Esistono "codici" (hash crittografici) che consentono la codifica ma non la decodifica, quindi questo può essere reso rispettabilmente sicuro.

Gli elenchi di password con hash a volte possono ancora essere violati, ma è TREMENDO più costoso farlo - e, cosa più importante, puoi dimostrare di aver compiuto uno sforzo ragionevole per proteggere i dati degli utenti, quindi la tua responsabilità è molto inferiore.

L'importanza tecnica dell'hashing è ampiamente sopravvalutata.

La ragione pratica per cui hai bisogno dell'hash è perché lo fanno tutti gli altri; è considerata "best practice". Se hai una violazione, è molto più facile difendere una posizione in cui stai facendo lo stesso dei tuoi colleghi. Fare qualcosa di diverso, anche se è la cosa giusta, è molto più difficile da difendere. Quindi consiglio sempre ai siti web di seguire il metodo di hashing standard, anche se penso che sia sciocco.

Allora perché l'importanza dell'hashing è enormemente sopravvalutata? Iniziamo pensando a un sito Web con password senza hash. Le password verrebbero archiviate in testo normale nel database. Il database è protetto: su un server fisicamente sicuro, crittografia completa del disco, firewall, amministrazione sicura ed è protetto dalla logica dell'applicazione sul server web. Quelle password sono fondamentalmente sicure.

Perché eseguiamo l'hash? Fornisce un'ultima linea di difesa. Supponiamo che tutte quelle difese siano state ostacolate. Forse la NSA ha utilizzato un exploit del browser zero-day per ottenere malware sulla workstation di sys-admin, ha aspettato che accedesse al database e da lì ha preso il controllo remoto ed estratto tutti i dati. In tal caso, la NSA ottiene tutte le password in chiaro. Ed è qui che l'hashing aiuta: se usi l'hashing, l'NSA ottiene solo gli hash e dovrebbe condurre un attacco di forza bruta per ottenere le password.

Ed è per questo che le persone consigliano l'hashing. Ma questo è difettoso per tre motivi:

1. Dati personali : il sito web conserva le tue password e contiene anche dati personali. Che si tratti di messaggi, foto, cronologia degli acquisti. Il motivo per cui hai una password in primo luogo è proteggere i tuoi dati personali. L'hashing può proteggere la password, ma non fa nulla per proteggere i tuoi dati personali.

2. Acquisizione dal vivo : sebbene nel database siano archiviati solo hash, ogni volta che qualcuno accede, la sua password viene inviata al server web. L'NSA può rimanere in silenzio sul server catturando la password di tutti. L'hashing non fa nulla per impedirlo.

3. Riutilizzo della password : è importante evitare il riutilizzo della password per altri motivi. Quindi, quando LinkedIn viene violato, non importa se ottengono la mia password o meno. Gli hacker hanno già i miei dati personali da LinkedIn. E se recuperano la mia password, ottengono l'accesso solo a LinkedIn e hanno già quei dati.

Considerato tutto ciò, i vantaggi dell'hashing della password sono marginali. Non so perché la comunità di InfoSec continui a parlare di hashing delle password, sarebbe molto più sensato concentrarsi sulla prevenzione delle violazioni del database in primo luogo. In generale, i costi dell'hashing sono relativamente bassi, ma c'è un'eccezione: gli hash fortemente iterati. Il costo tecnico di questo è alto e il vantaggio è basso, quindi questo consiglio è piuttosto male interpretato. Tuttavia, devo consigliare alle persone di seguirlo, perché è "best practice".

Cosa dire al capo: "Ecco il problema. Sono uno sviluppatore di software esperto e ti sto dicendo che archiviare password non crittografate è rischioso a un livello di assoluta stupidità imperdonabile. Anche archiviare password non salate è rischioso a livello di grave incompetenza. E te l'ho appena detto. Puoi ordinarmi di memorizzare le password non crittografate e lo farò, ma se dovessimo mai incontrare problemi dirò a chiunque voglia sentire che non è perché sono incompetente , ma perché mi hai ordinato di farlo contro un serio consiglio. A quel punto, ti prometto che sarai ritenuto personalmente responsabile e avrai avvocati dopo di te che vogliono ogni singolo centesimo che personalmente proprio.