Qual è il punto delle password di hashing?

Sì. Per ulteriori analisi, consulta questo post del blog : archiviamo le password con hash perché < em> partial , le violazioni di sola lettura si verificano (anche se solo attraverso un nastro di backup smarrito) e non vogliamo che gli hacker siano in grado di trasformare immediatamente questa violazione in accesso completo in lettura-scrittura.

Inoltre, le password sono dati privati (quindi molti uomini usano il nome della loro ragazza come password e la loro moglie potrebbe non essere soddisfatta), quindi dovrebbero essere protetti dalla divulgazione accidentale agli occhi degli amministratori di sistema (o dei loro stagisti). ). Almeno, guardare un database di password con hash è sicuro.

Is the only reason for hashing to protect user's accounts on other sites in the event of a compromise?

No, non è l'unica ragione. È anche per proteggere l'account su il tuo sito dall'accesso da parte di qualcuno che non dovrebbe avere accesso.

Supponiamo che il tuo sito sia vulnerabile a un attacco di SQL injection, in cui potresti ottenere il campo password del database per un utente arbitrario. Non preferiresti enormemente che il campo della password fosse un hash a senso unico? Forse possono eseguire un lungo attacco di dizionario contro l'hash, ma supponendo che la chiave sia rafforzata (ad esempio, bcrypt) non dovrebbero essere in grado di romperlo a meno che non sia una delle password più deboli / più comuni.

Oppure diciamo che un amministratore di sistema è stato licenziato. Vuoi che lui / lei abbia avuto accesso a tutti i milioni di nomi utente / password? Certo, mentre erano occupati potrebbero aver avuto accesso a vedere le informazioni di qualsiasi utente dal proprio account amministratore, ma ora che non sono più impiegati non dovrebbero più avere alcun accesso. Con le password in chiaro, possono aver memorizzato o rubato alcune password che possono utilizzare in un secondo momento per entrare in account casuali. (Inoltre, al tuo sistema potrebbe essere richiesto di tenere un registro di controllo di chi sta accedendo a quali informazioni quando; quindi c'è una grande differenza tra un amministratore che cerca le informazioni dell'account di un utente e qualcuno che effettua l'accesso al di fuori del sistema propria password). Garantito che un amministratore di sistema può memorizzare i parametri POST dalla pagina di accesso nei registri del server web e ottenere le password in chiaro se lo desidera , ma sarebbe sospettoso e probabilmente rintracciabile a loro.

O forse qualcuno ha trovato uno dei tuoi vecchi backup del database. Vuoi che abbiano un facile accesso a tutte le password?

Bottomline è (a) dovresti usare le password hash per la sicurezza sul tuo sito in modo strong (ad esempio, bcrypt), e (b) non dovresti mai riutilizzare la stessa password su siti diversi (dato che non puoi mai essere sicuro che stanno prendendo le dovute precauzioni con esso).

L'hashing della password ti protegge nei casi in cui la tua infrastruttura non è sicura come pensi.

Nonostante i tuoi migliori sforzi, ti sarai hackerato ad un certo punto della tua carriera IT. La vostra strategia passa quindi dalla prevenzione (che non ha funzionato almeno in questo caso) al controllo dei danni e al disaster recovery. In parte ciò garantisce che anche se un utente malintenzionato si impadronisce di dati sensibili scaricando il database, non può utilizzarlo a suo ulteriore vantaggio (almeno non prima di poter apportare modifiche sufficienti al sistema per rendere tali dati inutili).

Immettere la password con hash. Hashing è progettato per produrre un valore univoco per un messaggio univoco che può ancora essere comparato per l'uguaglianza, ma che non ha apparentemente una relazione matematica o referenziale con il messaggio originale (e quindi non può essere "decodificato" efficientemente quando viene fornito solo il valore hash ). Quindi, il tuo aggressore trova una fessura nell'armatura esterna e si intrufola nella tua rete. Ottiene l'accesso al filesystem del tuo database e tira il tuo file MDF. Lo apre sul suo computer locale e cerca i dati dell'account utente che può usare per entrare ancora di più. Bene, indovina un po '? tutto quello che vede è un mucchio di parole senza senso dove dovrebbero essere le sue password maltrattate. La quantità di conoscenza acquisita dall'aggressore dal vedere gli hash, supponendo che siano stati correttamente salati e che impiegano un hash crittograficamente sicuro, fornirà solo l'aiuto minimo per raggiungere il tuo sistema.

Ora, ci sono modi più semplici per decifrare un hash della password piuttosto che decifrare altri messaggi hash, perché " attraverso 20 anni di sforzi, abbiamo avuto successo ha addestrato tutti a utilizzare password difficili da ricordare per gli umani, ma facili da indovinare per i computer ". Tuttavia, hashing ha ancora valore, specialmente quando si utilizza un hash progettato per essere costoso da calcolare, come BCrypt o PBKDF2. Quando un hash della password impiega un secondo per calcolare, anche una password debole (28 bit di entropia) richiederebbe fino a 8 anni per indovinare per forza bruta, e se imponi agli utenti di cambiare le loro password regolarmente, l'autore dell'attacco deve ricominciare da capo ( dopo aver raggiunto il nuovo dump DB) ogni volta.

Come menzionato dagli altri, una password hash (non reversibile) è migliore perché puoi guardare il database senza la rivelazione della password degli utenti e rallentare un utente malintenzionato. Ma ci sono altri punti che sono possibili quando la password è conosciuta solo dal proprietario dell'account.

Puoi crittografare i dati con una chiave casuale. La chiave casuale viene quindi crittografata con la password dell'utente. Quindi solo l'utente può ottenere l'accesso, anche se qualcuno modifica l'hash nel database. Lo svantaggio è che se l'utente dimentica la password, tutti i dati vengono persi.

Questo può anche essere esteso con i certificati. Tutti possono crittografare, ma hai bisogno della password (che non è reversibile dall'hash) per leggerla di nuovo.

Un tale sistema verrebbe sconfitto se memorizzi le password chiare. Un sistema del genere non è normale, ma certamente possibile. E in un tale sistema, anche con l'accesso completo al r / w, devi intercettare la password oi dati per ottenere i dati, cambiare il sistema, che richiede a) molto tempo b) buona conoscenza del sistema ed è quindi non così facile.

Modifica: Ubuntu utilizza la password dell'utente per de / crittografare la directory home come ho descritto . Se le password fossero archiviate in chiaro, l'amministratore poteva comunque accedere ai dati. Certo, mentre l'utente è loggato o il sistema è cambiato per condividere le chiavi, copiare la directory home ecc., I dati non sono più sicuri.

Ma le password di hashing sono come indossare un giubbotto antiproiettile. Potresti ancora sparare alla testa.

Non riesci a pensare a un compromesso come a uno stato semplice del tuo compromesso o del tuo non. Ci sono diversi livelli di compromesso e diversi livelli di protezione per limitare il compromesso o avvisarti quando sei stato compromesso. Mentre sembra che assistiamo a un aumento dei compromessi attivi e mirati del "crimine informatico", è importante notare che molti, alcuni potrebbero addirittura suggerire una maggioranza, di compromissioni di dati avvenute attraverso accidenti e errata configurazione piuttosto che deliberati "hacking". Sebbene sia ancora limitato, il fatto che la tua password sia hash fornisce una certa protezione quando l'amministratore di sistema cambia accidentalmente le autorizzazioni su un file chiave e qualcuno è in grado di scaricare una copia del database delle password dei siti.

Il tuo punto riguardante gli amministratori di sistema è valido. È qui che la reputazione diventa molto importante. Se usi un provider di posta elettronica che non conosci e non hai fiducia in te stesso, che non ha una vera reputazione, allora dovresti essere molto preoccupato o semplicemente accettare che c'è un'alta probabilità che un amministratore di sistema stia leggendo la tua email. Il punto è che nella vita, spesso dobbiamo fidarci di persone che non conosciamo veramente bene. Lo facciamo sempre. L'ultima volta che eri in un ristorante, ti fidi del cameriere con la tua carta di credito? Quanta fiducia riponi nell'addetto alla tua clinica?

Spesso lo faremo in base alla reputazione e al costo. Sappiamo che una buona sicurezza ha un costo. Sfortunatamente, molte persone non riescono a riconoscere che i fornitori di servizi "economici" o di budget devono tagliare i costi da qualche parte e troppo spesso, da qualche parte c'è sicurezza.

La linea di fondo è che nella maggior parte dei sistemi, a un certo livello, ci sarà qualcuno che ha accesso completo a tutte le tue informazioni e non hanno bisogno della tua password (ci sono alcune situazioni in cui questo non è strettamente vero, ma sono in minoranza, quindi lascia supporre che questo non sia il caso). La domanda diventa quindi una questione se ti fidi di questo fornitore di servizi con i tuoi dati privati. Stai pagando abbastanza per aspettarti un servizio riservato? Il fornitore ha un investimento sufficiente nella reputazione che adotterà misure sufficienti per garantire che i tuoi dati siano sufficientemente protetti, ad esempio un'adeguata verifica del personale, buone piste di controllo e audit dei processi sufficienti a garantire processi adeguati e seguiti, ecc.