Perché solo l'hash delle password?

Per prima cosa:

• Dimentica immediatamente MD5. È vecchio e debole.
• Idealmente, dimentica anche SHA1. Ci sono SHA2 e SHA3.
• Questi algoritmi di hash nella loro forma pura sono utili per molte cose, ma non per le password. Usali in combinazione con es. PBKDF2, o usare bcrypt (e non dimenticare la salatura).

So, if I am not wrong passwords are hashed so that in a rare situation of your database being compromised a hacker can not see all the passwords in your database as the passwords are hashed.

Una corretta. Anche se questo non aiuterà a rendere il tuo server più sicuro (dopotutto, è già compromesso in tale situazione), impedisce ad es. l'utente malintenzionato che utilizza le password su altri siti. Purtroppo molte persone usano una sola password per più cose.

Is hacking a database that easy? I mean instead of finding new ways to hash, why can't they make their database more secure or "hack-proof"?

Potresti (e dovresti). Ma:

• Anche con tutti i tuoi sforzi, c'è sempre qualche possibilità che l'attaccante possa avere accesso. Bug in software e dispositivi che non conosci e / o che non puoi correggere e molte altre cose.
• Spesso non puoi dare il massimo a causa di manager che non pensano che la sicurezza sia importante, non hanno budget per questo ecc.

If a hacker manages to hack into some database, why would he want to know the hashed passwords? I mean he can change other columns of data. For example, he could search for his username and increase his bank balance. So, shouldn't all the fields be hashed?

Se tutti i campi sono sottoposti a hash, il database è inutile anche per te; quindi non puoi farlo. Ricorda, un buon hash non può essere invertito.

Come detto sopra, non appena il tuo DB / Server è stato compromesso, il danno per te è già accaduto. Le password hash impediscono semplicemente che l'hacker possa accedere anche ad altri account degli utenti (e quindi alcuni utenti ti citano in giudizio, quindi anche l'hashing aiuta te).

MD5 e SHA-1 non sono più sicuri non perché "la maggior parte degli hash delle password è ora su Internet". L'uso di sali per rendere gli hash delle password globalmente unici rende infatti impossibile. Sono obsoleti perché sono troppo veloci e troppe password candidate possono essere testate con un hash rubato troppo rapidamente per maggiore comodità.

Il rovescio della medaglia è che non è reversibile. Questo è il motivo per cui non può essere utilizzato per tutti i dati sensibili. Il tuo conto in banca, ad esempio, non è molto buono né per te né per la banca se si tratta di hash, e nessuno dei due sa di cosa si tratta.

1. Anche se probabilmente non è così semplice con i sistemi ben configurati in mente, molteplici vulnerabilità sul sistema operativo o sul livello di applicazione (come SQL Injection, forse anche l'inclusione di un file) possono portare a compromissioni del database, come spesso accade caso in realtà. Proteggere le password con hashing è un esempio di difesa approfondita. Anche se una linea di difesa fallisce, dovrebbe comunque essere relativamente difficile accedere alle password effettive.

2. Le password sono un buon obiettivo per molteplici ragioni. Da un lato, consentono la rappresentazione degli utenti, piuttosto che leggere, modificare o eliminare dati con l'account dell'attaccante (possibilmente compromesso). Anche gli utenti tendono a riutilizzare le password, quindi una password rubata da un'applicazione ha ottime possibilità di essere valida per altri account dello stesso utente. Per quanto riguarda il motivo per cui gli altri dati non sono hash: l'hashing è unidirezionale, non è possibile recuperare il valore originale da un hash (almeno non banalmente, in realtà e con molte funzioni hash, si hanno buone possibilità, ma ignoriamolo per un momento). Essere a senso unico significa che le funzioni di hash sono utili per verificare se una password immessa è uguale a quella memorizzata, ma non è buona per archiviare i dati effettivamente necessari nella sua forma non crittografata. E questa è la soluzione che potresti aver cercato, crittografia, al contrario dell'hashing. È davvero una buona idea crittografare i dati sensibili in un database, ma anche questo ha i suoi problemi, ad esempio la gestione delle chiavi.

Is hacking a database that easy? I mean instead of finding new ways to hash, why can't they make their database more secure or "hack-proof"?

Spesso un database può essere violato tramite un'applicazione Web utilizzando SQL injection. Dobbiamo assolutamente risolvere SQL injection come priorità. Tuttavia, in un'applicazione di grandi dimensioni, è sufficiente che uno sviluppatore commetta un errore su una riga per introdurre tale vulnerabilità. Quindi, mentre proviamo a fermarlo, pianifichiamo altre difese nel caso in cui una vulnerabilità venga superata.

If a hacker manages to hack into some database, why would he want to know the hashed passwords? I mean he can change other columns of data. For example, he could search for his username and increase his bank balance. So, shouldn't all the fields be hashed?

In molti casi l'SQL injection consente agli aggressori di leggere i dati, ma non di cambiarli. Se le password non sono state sottoposte a hash, potevano accedere come altri utenti e apportare modifiche. L'hashing della password aiuta a prevenire questo. Inoltre, gli utenti spesso riutilizzano le password su molti siti Web, anche se è una cattiva pratica farlo.

Why are only passwords hashed?

In un'applicazione ben progettata, tutti i token di autenticazione sono sottoposti a hash. Ciò include gli ID di sessione e le password che reimpostano i token e le password. Altri dati (ad es. Il tuo saldo bancario) non sono sottoposti a hash, perché l'applicazione necessita dei dati in formato testo per funzionare.

Is hacking a database that easy? I mean instead of finding new ways to hash, why can't they make their database more secure or "hack-proof"?

Perché abbiamo bisogno di ospedali? Perché non possiamo rendere la strada più sicura invece di avere ospedali?

Un sistema totalmente "a prova di hacker" è un'illusione. Ci sono milioni di modi per hackerare un sistema. Devi difenderti contro tutti loro. Un utente malintenzionato deve solo trovarne uno.

Questo richiede che tu sappia tutti i modi. E che non hai commesso un errore (basta guardare l'impostazione predefinita per Mongo-DB: accesso amministratore non autenticato e quindi combinarlo con molti amministratori per impostare il database in modo che sia raggiungibile da Internet per comodità o per manuali scadenti) . E avere le risorse. E per rimanere aggiornato quando vengono scoperti nuovi difetti. E lo stesso per tutti i fornitori di software, servizi e hardware che stai utilizzando. E nessuno di loro aveva cattive intenzioni. E che ci sono aggiornamenti per nuovi difetti scoperti (gli smartphone Android sono noti per non essere molto ben serviti con aggiornamenti di sicurezza). E che non ci sono difetti sconosciuti di cui l'hacker sa.

Sei sicuro di aver difeso contro tutti loro? Di chi ti fidi? Che ne pensi dell'amministratore che è stato rilasciato e ha ancora accesso a una copia del backup del database? Hai cancellato correttamente la memoria prima di rivenderla o gettarla via? Chi ha accesso ai backup?

If a hacker manages to hack into some database, why would he want to know the hashed passwords? I mean he can change other columns of data. For example, he could search for his username and increase his bank balance.

1. Potrebbe essere che ha solo accesso in sola lettura al database. Ad esempio quando ha avuto un backup nelle sue mani quando è stato memorizzato su un server web non protetto o il suo vettore di attacco consente solo la lettura.
2. Potrebbe avere accesso solo a una parte del sistema in cui sono archiviate le password ma non al sistema in cui sono memorizzati i saldi.
3. Molti database professionali hanno una pista di controllo. Supponiamo che tu cambi il tuo saldo nel database. Ciò potrebbe lasciare disattivati i loro allarmi perché il sistema non vede alcuna riduzione corrispondente in un altro equilibrio e nessuna autorizzazione per questa transazione ecc. Ed è facilmente visibile. Se invece accedi come un altro utente e fai clic su trasferisci 1000 $ su un altro account, apparirà più legittimo.
4. Puoi utilizzare i dati di accesso per impersonare un altro utente e lui riceverà la colpa (molti provider più grandi hanno già l'euristica per rilevare tali cose automaticamente o quando richiesto)
5. Tempo di attacco (-vector) e ora di accesso: devi solo attaccare una volta ma puoi usare le credenziali in seguito (molti utenti non cambiano le password per anni o mai più)
6. Molti utenti meno tecnici riutilizzano le password su altri siti
7. Hai più tempo prima che l'aggressore possa impersonare gli utenti dopo aver attaccato

Sono stati i primi motivi a cui ho pensato e ce ne sono molti altri.

shouldn't all the fields be hashed?

È una domanda interessante, quindi consideriamo le ramificazioni se (per esempio) il nome utente è stato anche hash. In questo momento sono "Nick Gammon" su Stack Exchange. Se il mio nome utente è stato sottoposto a hash, invece di un post di Nick Gammon , vedremmo un post di 80a8694f4a2950e075d142e97ddb809b415bf85f084dafd9fb78fed9551905f3 in risposta a una domanda di 76d6d4c28518362c96d55f52cfdf27908baadf6f37973eb42cfd515b4c96294a ¹ . Puoi vedere che sarebbe incredibilmente noioso. (Ricorda, non è possibile invertire un hash per ottenere l'originale indietro).

OK, potresti dire "vabbè, tieni un nome di accesso (che hai cancellato) e anche un nome visualizzato". Ma se hai visto il mio nome di visualizzazione era "Nick Gammon", potresti indovinare che era anche il mio nome di accesso (o qualche semplice variante di esso), quindi l'hashing non ha ottenuto nulla.

Quindi potresti temere che, se qualcuno fosse entrato nel database, potesse vedere anche gli indirizzi e-mail, così anche tu li hai cancellati. Ma non è possibile inviare una e-mail a un indirizzo di posta elettronica con hash (ad esempio per notificare nuovi messaggi o una diminuzione del saldo bancario) in modo che non funzioni. OK, quindi mantieni l'indirizzo email come testo normale, ma ora puoi probabilmente dedurre il nome utente dall'indirizzo email.

why can't they make their database more secure or "hack-proof"?

Nessun progetto supporterà che un dipendente di fiducia venga corrotto per fare una copia del database. Se i dati sono presenti, le persone con sufficiente spazio dovranno essere in grado di raggiungerli, o potrebbe anche non esistere.

Penso che alcune delle recenti fughe di sicurezza siano avvenute a organizzazioni che ritenevano che il loro database fosse così "a prova di hacker" che non avevano bisogno di disturbare l'hashing delle loro password. Oops.

1. Marchi extra per capire chi è. :)

"Difesa in profondità" è il principio che i livelli multipli e ridondanti di sicurezza sono i migliori e, più specificamente, che nessun componente di un sistema sicuro dovrebbe fidarsi di qualsiasi altro componente di un sistema sicuro. In questo caso, il livello di hashing non dovrebbe presupporre che il database stesso sia sicuro.

Hai chiesto ad altre domande tecniche sull'hashing che sono trattate in dettaglio nelle altre risposte, ma il principio più fondamentale della difesa in profondità - "perché chiudi la porta due volte?" - è qualcosa che sembra mancare.

Sono sicuro che hai sentito abbastanza casi di violazioni della sicurezza di alto profilo nel 2016 per sapere che, nel complesso, stiamo facendo troppo poco , non troppo.

Non limitarti solo analizzando l'attacco dall'esterno. Devi vedere l'immagine più grande ... pensa alle misure di sicurezza come strati di una cipolla. Impilerai più che puoi nella speranza di chiudere qualsiasi angolo di attacco. Gli hash delle password sono uno di questi livelli.

Is hacking a database that easy? I mean instead of finding new ways to hash, why can't they make their database more secure or "hack-proof"?

Non importa quanto sia difficile hackerare il database. Considera che l'hashing della password dovrebbe proteggere la password anche dal sistema o dall'amministratore del database.

Nota che anche se provassi a farlo, non è necessariamente facile proteggere il database delle password. Come lo proteggeresti? Con un'altra password? Dove conserveresti quella password principale? Come proteggi la password principale contro qualcuno che è in grado di leggere tutto sul sistema?

If a hacker manages to hack into some database, why would he want to know the hashed passwords?

Bene, per provare ad attaccarli.

Nota come vengono utilizzate le password: l'utente legittimo mette un nome utente e una password in chiaro nella schermata di accesso, il testo in chiaro viene quindi sottoposto a hash e confrontato con l'hash della password.

Ogni utente malintenzionato può fare esattamente la stessa cosa, tranne che farlo sullo schermo di login / prompt effettivo non è efficiente - richiede tempo e viene facilmente rilevato; molti sistemi bloccheranno un account dopo alcuni cattivi tentativi.

Quindi, quando l'attaccante ottiene la lista degli hash delle password, può fare lo stesso hashing nel suo programma - velocissimo in modo accecante, e specialmente con attacchi "dicitonary" o "rainbow", che scambiano RAM / storage contro il tempo.

So, shouldn't all the fields be hashed?

Non puoi cancellare tutti i campi perché l'applicazione deve conoscere il valore degli altri campi, semplicemente. È difficile recuperare il valore da una versione con hash, anche per un utente legittimo.

Ma in effetti, ci sono database che fanno qualcosa del genere - crittografano (non ha hash) anche i dati reali. Vuoi valutare se ne vale la pena dal punto di vista delle prestazioni e devi quindi assicurarti che la crittografia fornisca effettivamente una vera sicurezza. Ad esempio, devi assicurarti che la tua chiave rimanga protetta mentre il DB ha bisogno di accedervi, e così via.

La crittografia non è appropriata per le password perché in realtà non vogliamo che le password possano essere decifrate (stesse idee come all'inizio = > lavori interni e la difficoltà di rendere la chiave di crittografia più sicura delle password effettive volevi assicurarti in primo luogo.

Perché non è solo l'accesso remoto e non autorizzato che deve essere protetto. A volte intero dati di dati scompaiono. Una volta che i cattivi hanno i dischi che contengono i file del database, possono essere letti nel tempo libero. Quindi tutti i dati non crittografati possono essere presi: numeri di carta di credito, nomi, indirizzo, e-mail, numeri di telefono, cronologia degli acquisti. Tutto e tutto ciò che facilita il furto di denaro o il furto di identità.

Le buone pratiche attuali sono criptare tutto ciò che è personalmente identificabile o finanziariamente sensibile. Diversi DBMS supportano la crittografia a riposo (vale a dire sul disco) e in volo (durante il trasferimento dal server DB all'applicazione).

Is hacking a database that easy?

No, non è così facile. Una configurazione mal configurata è ciò che rende vulnerabili i database e li espone agli autori di attacchi. Si dovrebbero applicare le patch disponibili per la versione del database utilizzata e, se possibile, eseguire l'ultima versione.

I mean instead of finding new ways to hash, why can't they make their database more secure or hack-proof?

Le persone continuano a provare a trovare nuovi algoritmi per l'hashing perché le collisioni vengono rilevate nell'algoritmo di hashing corrente. Non è che non siamo in grado di trovare modi per proteggere i database.

why Hashing?

1. L'hashing garantisce all'utente finale che i suoi token e password segrete sono archiviati in un formato irreversibile.

2. L'hashing garantisce che l'applicazione che accede al database non abbia accesso ai dati segreti in forma di testo trasparente.

3. L'hashing impedisce anche ai dati segreti di essere esposti anche agli amministratori di database e di sistema.

If a hacker manages to hack into some database, why would he want to know the hashed passwords? I mean he can change other columns of data. For example, he could search for his user name and increase his bank balance. So, shouldn't all the fields be hashed?

Determinare il database nascosto attraverso le applicazioni che hanno accesso ad esso è diverso dall'interruzione nel server dei database. Se un utente malintenzionato fa breccia nel server che ospita il database, ovviamente può fare qualsiasi cosa consentita per qualsiasi livello di privilegio a cui abbia accesso.

Ma non pensi che ottenere le password in chiaro sia pericoloso in una forma che è irreversibile, perché l'unica possibilità rimasta per l'attaccante è quella di lanciare la forza bruta passiva per trovare le password, il che dà abbastanza tempo per le vittime di cambiare le loro password compromesse.

Puoi ben vedere la differenza di forza delle sfide crittografiche che l'attaccante dovrà affrontare per raggiungere questo hash.

Why are only passwords hashed?

L'autenticazione delle password viene utilizzata per dimostrare l'autenticità di un'entità, quindi il possesso di una password è sufficiente per consentire a un utente malintenzionato di impersonare un altro utente. Quindi esiste un rischio per la sicurezza del furto di identità, se non lo è.

Esistono alcune soluzioni che crittografano tutti i dati sensibili nel database, ad esempio Azure . Ma la sicurezza non è gratuita e costa denaro, tempo e puoi ottenere prestazioni peggiori a causa della crittografia. Nessun pranzo è gratis.

Immagina un'azienda di e-shop individuale con budget ridotto. Questa azienda non può permettersi una soluzione costosa. La loro scelta è scegliere il più economico o niente. La sicurezza non è una scelta, perché non hai soldi per questo. La sicurezza sta iniziando a essere importante man mano che l'azienda cresce.