Domanda:
Perché solo le password vengono sottoposte ad hashing?
Aman Kothari
2016-10-29 02:26:48 UTC
view on stackexchange narkive permalink

Ho appena imparato alcune cose sugli algoritmi di hashing: MD5 e SHA-1. Quindi, se non sbaglio, le password vengono sottoposte ad hashing in modo che in una rara situazione in cui il tuo database venga compromesso, un hacker non può vedere tutte le password nel tuo database mentre le password sono sottoposte ad hashing. MD5 non è più sicuro poiché la maggior parte delle password comuni e dei relativi valori hash sono disponibili su Internet. E quindi le persone ora usano altri algoritmi di hashing.

Quindi, le mie domande sono:

  1. È facile hackerare un database? Voglio dire, invece di trovare nuovi modi per eseguire l'hash, perché non possono rendere il loro database più sicuro o "a prova di hacker"?

  2. Se un hacker riesce ad hackerare un database , perché dovrebbe voler conoscere le password con hash? Voglio dire che può cambiare altre colonne di dati. Ad esempio, potrebbe cercare il suo nome utente e aumentare il suo saldo bancario. Quindi, non dovrebbe essere eseguito l'hash di tutti i campi?

Hai un malinteso su ciò che MD5 non è sicuro.Vedere [qui] (http://security.stackexchange.com/q/19906/46979).Si tratta di velocità, non di risultati pubblicati.(Quest'ultimo può essere superato con un sale lungo e casuale.) SHA-1 soffre dello stesso problema.
Molte volte gli hacker non riescono effettivamente a "hackerare il database", ovvero gli hacker non riescono ad accedere al database.Invece riescono solo a scaricare il database.Quindi non possono cambiarlo ma possono ottenere le password con hash.Quindi "perché dovrebbe volere l'hashish" è perché è quello che ottiene.Da lì vorrebbe provare a invertire l'hash usando le tabelle arcobaleno ecc.Per ottenere almeno alcune password che corrispondono ad alcuni degli hash.Quindi può accedere.Nota che non sarebbe quasi MAI in grado di ottenere tutte le password.Solo alcuni.Ma poi sarebbe stato in grado di accedere.
Possibile duplicato di [Come eseguire l'hashing sicuro delle password?] (Http://security.stackexchange.com/questions/211/how-to-securely-hash-passwords)
Vorrei davvero che la mia banca effettuasse l'hash del mio saldo.Troverei una collisione numerica stupidamente alta per l'hash e comprerei il mondo.
@ceejayoz hai molte più probabilità di vincere alla lotteria che di trovare una collisione numerica del tuo saldo, se l'hash non ha alcuna debolezza nota di resistenza alle collisioni.
@tsukumogami Sì, ma OP menziona MD5 e SHA1.Quindi, sono un multi-quintillionario in erba!
Questa domanda mi ha fatto pensare: in realtà anche i nomi utente sono una sorta di "informazione preziosa" (è probabile che gli utenti utilizzino lo stesso nome utente su servizi diversi, quindi è più facile associare una password crackata a un altro servizio conoscendo il nome utente).Pertanto, questa è una cosa valida da chiedersi e l'hashing dei nomi utente potrebbe davvero valere la pena.Solo ... come prevenire le collisioni?I nomi utente devono essere univoci e, sebbene improbabile, le collisioni hash su nomi utente diversi _sono_ possibili ...
@Damon: Vedi [Perché le persone non usano hash e salt nomi utente prima di memorizzarli] (http://security.stackexchange.com/q/25374/8715)
"È così facile hackerare il database?".No. L'hacking si verifica nei molti livelli di persone e sistemi tra l'hacker e il database.La tua bella porta del caveau è inutile se la guardia darà a qualcuno la chiave.
@tsukumogami: Sì, ma con hardware informatico immediatamente disponibile, posso calcolare un milione di hash al secondo.Non posso acquistare i biglietti Powerball così velocemente perché sono limitato dal prezzo di acquisto di $ 2.
Vorrei affrontare il malinteso sottostante qui: l'hashing non è per proteggerti.Il tuo database è compromesso e probabilmente lo sono anche altri sistemi.Troppo tardi per te.L'hashing delle password viene eseguito per proteggere i tuoi UTENTI, perché probabilmente utilizzano le stesse password su più siti.
Se hai eseguito l'hashing del saldo bancario dell'utente, come farebbe il computer a conoscere il suo saldo bancario?L'utente deve digitare il proprio conto in banca e poi farlo controllare dal computer?
@dan04 Se il tuo hash non ha alcuna debolezza nota, non importa se puoi calcolare un milione o un miliardo di hash al secondo, la possibilità di trovare una collisione è ancora molto inferiore alla possibilità di vincere la power ball,molti ordini di grandezza.
@tsukumogami La domanda è se siano * sufficienti * ordini di grandezza per avere ancora una minore possibilità di ottenere una collisione su $ 2 di tempo sul server rispetto a vincere il powerball con un biglietto.
@Random832 Sì, è più che sufficiente, a meno che non abbiamo alcune nuove scoperte fondamentali in matematica e / o fisica.Ma penso che siamo abbastanza lontani.Se vuoi un calcolo dei dettagli, forse possiamo portare questa conversazione in chat?
Pensa a qualcuno che ruba il tipo di backup del database e al fatto che molti dei tuoi utenti avranno la stessa password sul tuo sistema che hanno sulla loro banca ...
Per lo stesso motivo, spesso è meglio pagare un'altra azienda per memorizzare i dettagli del credito dei tuoi clienti, quindi memorizzi solo il "token", quindi non sei responsabile se i dettagli della carta escono.
Undici risposte:
deviantfan
2016-10-29 03:44:30 UTC
view on stackexchange narkive permalink

Prima alcune cose:

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

Quindi, se non sbaglio le password vengono sottoposte ad hashing in modo che in una rara situazione in cui il tuo database venga compromesso un hacker non possa vedere tutte le password nel tuo database come le password sono hash.

Corretto. Anche se questo non aiuterà a rendere il tuo server più sicuro (dopotutto, è già compromesso in una situazione del genere), impedisce ad es. l'attaccante che utilizza le password su altri siti. Purtroppo la maggior parte delle persone usa una password per più cose.

È facile hackerare un database? Voglio dire, invece di trovare nuovi modi per eseguire l'hash, perché non possono rendere il loro database più sicuro o "a prova di hacker"?

Potresti (e dovresti). Ma:

  • Nonostante tutti i tuoi sforzi, c'è sempre qualche possibilità che l'attaccante possa ottenere l'accesso. Bug in software e dispositivi che non conosci e / o che non puoi risolvere e molte altre cose.
  • Spesso non puoi dare il meglio a causa di manager che pensano che la sicurezza non sia importante, non hai budget per farlo ecc.

Se un hacker riesce ad hackerare un database, perché dovrebbe voler conoscere le password con hash? Voglio dire che può cambiare altre colonne di dati. Ad esempio, potrebbe cercare il suo nome utente e aumentare il suo saldo bancario. Quindi, non dovrebbe essere eseguito l'hash di tutti i campi?

Se tutti i campi sono sottoposti ad hashing, anche il database è inutile; quindi non puoi farlo. Ricorda, un buon hash non può essere annullato.

Come detto sopra, non appena il tuo DB / Server viene compromesso, il danno per te è già avvenuto. Le password con hash impediscono semplicemente che l'attaccante abbia accesso anche ad altri account dei tuoi utenti (e quindi alcuni utenti ti farebbero causa, quindi l'hashing ti aiuta).

Sono d'accordo con la maggior parte della tua risposta, tranne che raccomandando bcrypt: ci sono scrypt e argon2, perché dobbiamo ancora raccomandare algoritmi obsoleti?Inoltre, potresti probabilmente usare la parola d'ordine "sicurezza in profondità" quando rispondi al motivo dell'hash.
@axapaxa Aspetta, cosa?argon2 ha solo 1 anno e ci sono già due attacchi pubblicati su di esso, e scrypt è [dimostrabilmente più debole] (http://blog.ircmaxell.com/2014/03/why-i-dont-recommend-scrypt.html) dibcrypt per le applicazioni più comuni.Non c'è assolutamente niente di sbagliato nel consigliare bcrypt, anche nel 2016.
@axapaxa La crittografia (cioè la matematica) non diventa obsoleta solo perché è vecchia.In effetti diventa più forte man mano che più persone lo esaminano e non riescono a trovare difetti.[Blowfish] (https://en.wikipedia.org/wiki/Blowfish_ (cipher)), come utilizzato da bcrypt, rimane sicuro.[bcrypt] (https://en.wikipedia.org/wiki/Bcrypt) è ulteriormente progettato per evitare l'obsolescenza consentendo di ridimensionare il costo della funzione di hashing.Gli utenti di bcrypt possono difendersi da attacchi di forza bruta sempre più potenti o potenziali difetti futuri in Blowfish aumentando il fattore di ridimensionamento.
Per aggiungere al "perché" dell'hash: anche in uno scenario di sicurezza perfetto, si desidera comunque eseguire l'hash, perché ** nessuno tranne l'utente stesso ** deve conoscere quella password.Gli amministratori di database e altri occhi legittimi sul database non dovrebbero ** mai ** vedere la password dell'utente.
@axapaxa in crittografia, se un algoritmo è più recente, allora questo è uno * svantaggio * e se tutte le altre cose sono uguali, allora l'algoritmo più vecchio dovrebbe essere preferito.Se la forza è comparabile e non ci sono vulnerabilità attualmente note, l'algoritmo "obsoleto" è più affidabile e il nuovo algoritmo ha maggiori probabilità di scoprire nuove vulnerabilità perché non è stato esaminato molto.
Nessuno sano di mente userebbe MD5 o SHA1 per l'hashing delle password in qualsiasi nuovo sistema.Ma i punti deboli di MD5 e SHA1 non sono ancora abbastanza gravi da rappresentare una minaccia per l'hashing delle password.Quando le password protette tramite uno di questi hash sono state violate, è sempre stato dovuto al fatto che l'hash è stato applicato in modo errato piuttosto che a punti deboli nell'hash stesso.In altre parole, se quei sistemi avessero usato SHA2 o SHA3 nello stesso modo insicuro con cui usavano MD5 o SHA1, la vulnerabilità sarebbe stata altrettanto grave.
@kasperd "Ma i punti deboli di MD5 e SHA1 non sono ancora abbastanza gravi da costituire una minaccia per l'hashing delle password."- questo non è vero.L'MD5 può essere sottoposto ad hash su una singola GPU dal prezzo contenuto a una velocità di circa 10 ^ 9 hash al secondo.Ciò significa che qualsiasi password del dizionario può essere violata quasi istantaneamente e semplici modifiche delle parole del dizionario in pochi secondi.Anche una passphrase di 4 parole con hash da MD5 può essere indovinata entro pochi mesi.Non riesco a trovare cifre precise per l'hashing SHA-1 sull'hardware di oggi, ma nel 2012 era circa 1/3 più veloce dell'MD5, quindi non molto meglio.
@PeriataBreatta ** La velocità non è un punto debole in una funzione hash crittografica. ** MD4, MD5, SHA0, SHA1, SHA2, SHA3, ecc. Sono tutti progettati per essere il più veloci possibile.Non è un punto debole che siano veloci da calcolare.Se basi la tua sicurezza sul presupposto che un utente malintenzionato debba impiegare millisecondi per computer la funzione di compressione (o spugna) di uno di questi, hai un design imperfetto.Devi assicurarti che l'attaccante debba valutare l'hash molte più volte per attaccare il tuo sistema, altrimenti il tuo sistema non è sicuro.
@PeriataBreatta Quei casi in cui gli hash MD5 sono stati effettivamente forzati ** non ** erano dovuti all'utilizzo di MD5.E le note debolezze dell'MD5 non hanno avuto alcun ruolo in quegli attacchi.I punti deboli di queste password non erano causati da MD5 ma piuttosto da altri due problemi: ** 1. ** Gli hash non utilizzavano sale.** 2. ** Le password erano così deboli che nessun hash della password poteva proteggerle.
Vorrei aggiungere al commento di @kasperd's sulla velocità, che un algoritmo più lento può anche aiutare a compromettere il tuo sistema rendendolo più suscettibile agli attacchi DoS.Più risorse si assorbono durante l'hashing di un input, più facile è vincolare tutte le risorse disponibili.
@kasperd La mia comprensione è che le password trapelate dall'attacco di Ashley Madison, ad esempio, provenivano dal cracking di un database MD5 salato.Poiché oltre 11 milioni di loro sono stati violati, molti dei quali erano 10 caratteri o più e / o contenevano simboli o cifre, certamente non possono essere * tutte * password deboli.
@kasperd - Sono d'accordo che la velocità non è un punto debole in una funzione hash.Tuttavia, è un punto debole in un meccanismo di verifica della password, motivo per cui una semplice funzione hash * non dovrebbe essere utilizzata a tale scopo * e perché abbiamo algoritmi progettati specificamente per il lavoro, come bcrypt o PBKDF ..
@all, bcrypt è obsoleto, non solo perché è vecchio (ecco perché non usiamo 3DES anche se sappiamo che è sicuro - e ha ricevuto di gran lunga la maggior parte delle criptoanalisi), ma perché l'autore di blowfish ha dichiarato che è obsoleto.corsiKa: argon2 ha pubblicato due attacchi, entrambi i quali non hanno mostrato molto, ed entrambi erano contro un punto di una variante (dire che è rotto è teso come chiamare AES rotto).e l'articolo a cui hai indicato afferma che scrypt è sicuro quanto bcrypt o altro.E il punto finale di quell'articolo era che bcrypt> scrypt per ora (2014) ... Quindi mantengo ancora la mia opinione.
@kasperd - altri recenti hack che coinvolgono MD5 salato includono i forum DOTA2, da cui apparentemente sono stati recuperati circa 1,6 su un totale di 2 milioni di password.Eppure, quando 43 milioni di password weebly.com (bcrypt) sono state rilasciate un paio di settimane fa, * quasi nessuna * è stata violata.Vuoi ancora sostenere che l'MD5 salato è abbastanza buono?
@PeriataBreatta Brute forzare 11 milioni di hash di password salate di password di 10 caratteri non è un'impresa facile per nessun hash, nemmeno MD5.Se assumiamo 6 bit di entropia per carattere, ciò sarà l'equivalente della forzatura bruta a 83,5 bit.Si tratta del lavoro svolto da tutto l'hardware specializzato utilizzato per il mining di bitcoin in un periodo di due mesi.Non che tu possa usare lo stesso hardware, perché dovresti progettare hardware specificamente mirato all'hash della password.Non credo che qualcuno investirà così tanto nel violare un database di password.
@axapaxa Gli algoritmi crittografici non vengono mai abbandonati a causa dell'età.Vengono abbandonati solo quando si trovano prove di debolezze.Più vecchio diventa un algoritmo senza che vengano trovati punti deboli, più motivi ci sono per continuare a usarlo, fino al punto in cui l'hardware diventa abbastanza efficiente da forzarlo.Il motivo per smettere di usare 3DES è che non è particolarmente veloce e la dimensione del blocco è di soli 64 bit, che è troppo piccola per i casi di utilizzo più moderni.Un algoritmo troppo nuovo dovrebbe essere utilizzato OTOH solo con molta cautela.
@PeriataBreatta Non ho usato le parole abbastanza buone su MD5.Quello che ho detto è che nessuno dei punti deboli di MD5 ti aiuterà nemmeno un po 'a rompere gli hash delle password.Si sono verificate perdite di hash MD5 non salati e solo le password più forti possono sopravvivere a questo.Ma fintanto che si utilizza una password complessa, sopravviverà a una perdita di un hash MD5 non salato.Se gli hash sono salati, le password possono essere più deboli di alcuni bit e sopravvivere.Trovo ironico che tu consideri forte una password con meno di 70 bit di entropia e consideri debole un hash a 128 bit.
"Anche se questo non aiuterà a rendere il tuo server più sicuro" - potrebbe essere compromesso separatamente dal DB - ad esempio da SQL injection o solo un sistema slave di replica è stato compromesso in sola lettura - dal resto del sistema.Ma una corretta memorizzazione delle password ti consente di avere un po 'di tempo per bloccare tutto e notificare agli utenti di cambiare immediatamente la password invece di farla aumentare fino alla compromissione completa del sistema.
Xander
2016-10-29 03:48:36 UTC
view on stackexchange narkive permalink

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

Lo svantaggio dell'hashing è 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 vantaggioso né per te né per la banca se si tratta di hash, e nessuno di voi sa cosa sia.

Giusto per mettere qualche cifra: nel 2009, una GPU di fascia alta potrebbe calcolare circa 200 milioni di hash MD5 al secondo.Oggi puoi ottenere una GPU 6 volte più veloce di quella GPU per meno di £ 100, con un guadagno di oltre 10 ^ 9 hash al secondo.È probabile che le cifre per SHA-1 siano leggermente inferiori, forse 1/3 o 1/4 di più.Se hai denaro da spendere per il progetto, puoi ottenere una [singola macchina che può eseguire l'hashing di oltre 6x10 ^ 10 hash SHA-1 al secondo] (http://www.zdnet.com/article/25-gpus-devour-password-hash-fino-a-348-miliardi-al-secondo /), e questo è stato 4 anni fa.
Che ne dici di una funzione invertibile molto lenta per altri dati?Diciamo, la decrittazione richiede l'ordine 1s.Va bene per una singola ricerca dei miei dettagli, ma doloroso per sfogliare tutto.È mai utile?
@innisfree Direi che stai pensando nella giusta direzione, almeno per alcuni sistemi.Generalmente i sistemi rientrano in uno dei due modelli.Nel primo modello, qualcuno (proprietari, amministratori, ecc.) Ha bisogno di accedere ai dati aggregati, nel qual caso questo tipo di funzione sarebbe proibitivamente costoso.
@innisfree Nel secondo modello, in cui solo i proprietari dei dati hanno bisogno di accedere ai propri dati, oppure i dati non vengono mai aggregati tra più utenti, potrebbe effettivamente funzionare, ma abbiamo un meccanismo alternativo che utilizziamo già che è ancora migliore .... Un PBKDF (come PBKDF2, bcrypt, scrypt, ecc.) viene utilizzato per derivare una chiave, e quel processo è dove entra in gioco il fattore lavoro che suggerisci.
@innisfree La chiave viene quindi utilizzata (generalmente indirettamente) per decrittografare i dati.Questo ha il vantaggio aggiuntivo in quanto non solo è lento trovare la chiave corretta, ma la chiave corretta è corretta solo per i dati di un utente.Non solo rende la forzatura bruta dei dati per più utenti lenta, ma impossibile.
SHA-1 è in realtà probabilmente peggiore dell'MD5, data la proliferazione di macchine minerarie Bitcoin che hanno silicio dedicato per eseguire hash SHA1.In questo momento, puoi ottenere carte Bitcoin che possono eseguire 14 milioni di MHash / secondo.Sono 1,4 * 10 ^ 12 hash SHA-1 al secondo e non costano più di 2500 USD.È un grande potere di hashing.L'intera rete Bitcoin esegue circa 10 ^ 18 hash SHA-1 al secondo, 24 ore su 24, 7 giorni su 7
Gabor Lengyel
2016-10-29 03:42:38 UTC
view on stackexchange narkive permalink
  1. Anche se probabilmente non è così facile con sistemi ben configurati in mente, più vulnerabilità a livello di sistema operativo o applicazione (come SQL Injection, forse anche l'inclusione di file) possono portare alla compromissione del database, così com'è abbastanza spesso il caso nella realtà. Proteggere le password mediante l'hashing è un esempio di difesa in profondità. Anche se una linea di difesa fallisce, dovrebbe essere comunque relativamente difficile ottenere le password effettive.

  2. Le password sono un buon obiettivo per diversi motivi. Da un lato, consentono di impersonare gli utenti, piuttosto che leggere, modificare o eliminare i dati con l'account dell'aggressore (eventualmente compromesso). Inoltre 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 altri dati non vengono sottoposti a hash, l'hashing è un modo, non è possibile recuperare il valore originale da un hash (almeno non banalmente, in realtà e con molte funzioni hash, hai buone possibilità, ma ignoriamolo per un momento). Essere unidirezionali significa che le funzioni hash sono utili per verificare se una password inserita è uguale a quella memorizzata, ma non è utile per memorizzare i dati di cui hai effettivamente bisogno nella sua forma non crittografata. E questa è la soluzione che potresti aver cercato, la 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.

Il nome utente, ad esempio, non è sottoposto ad hashing perché è probabile che questo sia il modo in cui l'applicazione trova _quale_ hash della password deve essere confrontato: richiede "restituisci l'hash dalla riga in cui user = _entered-user-name_" e hash la password inserita econfronta tale hash con l'hash restituito.
@DoktorJ Per non parlare del fatto che i nomi utente utilizzati per gli accessi devono essere univoci.Gli hash non hanno una garanzia di unicità.Può sembrare ovvio, ma molti candidati al colloquio mi hanno convinto del contrario - a quanto pare, un hash di quattro byte di una sequenza casuale di cento byte sarà sempre unico: / Mi chiedo perché non usiamo invece tali funzioni di hashing come algoritmi di compressione: D
paj28
2016-10-29 03:59:31 UTC
view on stackexchange narkive permalink

È così facile hackerare un database? Voglio dire, invece di trovare nuovi modi per eseguire l'hashing, perché non possono rendere il loro database più sicuro o "a prova di hack"?

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

Se un hacker riesce ad hackerare un database, perché dovrebbe voler conoscere le password con hash? Voglio dire che può cambiare altre colonne di dati. Ad esempio, potrebbe cercare il suo nome utente e aumentare il suo saldo bancario. Quindi, non dovrebbe essere eseguito l'hash di tutti i campi?

In molti casi l'iniezione di SQL consente agli aggressori di leggere i dati, ma non di modificarli. Se le password non fossero state sottoposte ad hashing, potevano accedere come altri utenti e apportare modifiche. L'hashing della password aiuta a prevenire ciò. Inoltre, gli utenti spesso riutilizzano le password su molti siti web, anche se è una cattiva pratica farlo.

Perché solo le password vengono sottoposte ad hashing?

In un'applicazione ben progettata, tutti i token di autenticazione vengono sottoposti ad hashing. Ciò include ID di sessione e token di reimpostazione delle password, nonché le password. Altri dati (ad es. Il tuo saldo bancario) non vengono sottoposti ad hashing, perché l'applicazione necessita di dati in formato di testo normale per funzionare.

La difesa in profondità è davvero un concetto chiave.Inoltre, potresti menzionare che l'hashing impedisce agli utenti legittimi (come DBA) di conoscere la password.
@spectras - Tendo ad evitare questa affermazione.Gli hash arrestano gli amministratori di database in alcune circostanze, ma un amministratore di sistema dannoso potrebbe modificare il sistema per registrare le password in chiaro.
H. Idden
2016-10-29 15:35:52 UTC
view on stackexchange narkive permalink

È così facile hackerare un database? Voglio dire, invece di trovare nuovi modi per l'hashish, perché non possono rendere il loro database più sicuro o "a prova di hacker"?

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

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

Ciò richiede che tu conosca 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 che impostano il database in modo che sia raggiungibile da Internet per comodità oa causa di manuali scadenti) . E avere le risorse. E per rimanere aggiornati quando vengono scoperti nuovi difetti. E lo stesso per tutti i fornitori del software, dei servizi e dell'hardware che stai utilizzando. E che nessuno di loro aveva cattive intenzioni. E che ci sono aggiornamenti per nuovi difetti scoperti (è noto che gli smartphone Android non sono molto ben serviti con gli aggiornamenti di sicurezza). E che non ci sono difetti sconosciuti di cui sia a conoscenza l'attaccante.

Sei sicuro di esserti difeso da tutti loro? Di chi ti fidi? Che ne dici dell'amministratore che è stato rilasciato e ha ancora accesso a una copia del backup del database? Hai cancellato correttamente lo spazio di archiviazione prima di rivenderlo o buttarlo via? Chi ha accesso ai backup?

Se un hacker riesce a entrare in qualche database, perché dovrebbe voler conoscere le password con hash? Voglio dire che può cambiare altre colonne di dati. Ad esempio, potrebbe cercare il suo nome utente e aumentare il suo saldo bancario.

  1. Potrebbe essere che abbia solo accesso in sola lettura al database. Ad esempio quando ha 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 archiviati i saldi.
  3. Molti database professionali hanno una traccia di controllo. Supponiamo che tu modifichi il saldo nel database. Ciò potrebbe disattivare i loro allarmi perché il sistema non vede alcuna riduzione corrispondente in un altro saldo e nessuna autorizzazione per questa transazione ecc. Ed è facilmente visibile. Se invece accedi come un altro utente e premi il trasferimento di 1000 $ su un altro account, sembrerà più legittimo.
  4. Puoi utilizzare i dati di accesso per impersonare un altro utente e lui avrà la colpa (molti provider più grandi già dispongono di euristiche per rilevare queste cose automaticamente o quando vengono rivendicate)
  5. Ora dell'attacco (-vettore) e ora dell'accesso: devi attaccare solo 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
  8. ol>

    Queste sono state le prime ragioni a cui ho pensato e ce ne sono molte altre.

Nick Gammon
2016-10-31 09:56:03 UTC
view on stackexchange narkive permalink

non dovrebbe essere eseguito l'hash di tutti i campi?

È una domanda interessante, quindi consideriamo le ramificazioni se (diciamo) anche il nome utente è stato sottoposto ad hashing. In questo momento sono "Nick Gammon" su Stack Exchange. Se il mio nome utente fosse sottoposto ad hashing, invece di un post di Nick Gammon , vedremmo un post di 80a8694f4a2950e075d142e97ddb809b415bf85f084dafd9fb78fed9551905f3 in risposta a una domanda di 76d6dfc5dfc5fc52df96dfc52fcf96dfc52dfc96d96dfc52dfcf96dfc52df96dfc52dfc96d96dfc52dfc96d96dfc sup> 1 . Come puoi vedere, questo sarebbe incredibilmente noioso. (Ricorda, non puoi invertire un hash per recuperare l'originale).

OK, potresti dire "oh, va bene, mantieni un nome di accesso (che hai hash) e anche un nome visualizzato". Ma se hai visto che il mio nome visualizzato era "Nick Gammon" potresti immaginare che fosse anche il mio nome di accesso (o qualche semplice variante di esso), quindi l'hashing non ha ottenuto nulla.

Allora potresti preoccupati che se qualcuno accede al database potrebbe anche vedere gli indirizzi email, quindi fai l'hash anche di quelli. Ma non puoi inviare un'e-mail a un indirizzo e-mail con hash (ad es. Per informarti di nuovi post o di un calo del tuo conto 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.


perché non possono rendere il loro database più sicuro o "a prova di hacker"?

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

Penso che alcune delle recenti falle di sicurezza siano successe ad organizzazioni che pensavano il loro database era così "a prova di hacker" che non avevano bisogno di preoccuparsi di hashing le loro password. Oops.


  1. Punteggi extra per capire chi è. :)
_Marchi extra per capire chi sia_ Questa è una domanda trabocchetto poiché l'hash che hai fornito non è per "Nick Gammon", ma è per "Nick Gammon \ n" ... Dopo averlo capito, è stato facile capire chiquell'hash appartiene a :) - ci sono voluti solo 2 tentativi.Un'altra cosa bella degli hash è che mi permette di mostrare che so chi è senza rivelare la risposta dandoti un hash del suo nome invertito (senza newline): c4354c3d27541e605c2cab2a661ef17fb7fb3d404d61f71a903f9a119a1bf0a4
Ah, vedo il problema.Ho fatto `eco a 'Nick Gammon' |sha256sum` dove avrei dovuto aggiungere l'opzione `-n`.Hai davvero ragione come hai confermato.:)
La prossima persona che vuole confermare potrebbe fare una versione tutta maiuscola o una versione tutta minuscola del nome.Tuttavia dicendo che sto trapelando alcune informazioni.;)
djechlin
2016-10-29 18:01:59 UTC
view on stackexchange narkive permalink

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

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

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

AnoE
2016-10-30 04:05:40 UTC
view on stackexchange narkive permalink

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

È facile hackerare un database? Voglio dire, invece di trovare nuovi modi per eseguire l'hash, perché non possono rendere il loro database più sicuro o "a prova di hacker"?

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

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

Se un hacker riesce ad hackerare un database, perché dovrebbe voler conoscere le password con hash?

Bene, per provare ad attaccarli.

Nota come vengono utilizzate le password: l'utente legittimo consegna un nome utente e una password in chiaro alla schermata di accesso, il testo in chiaro è quindi hash e confrontato con l'hash della password.

Ogni utente malintenzionato può fare esattamente lo stesso, tranne che farlo sulla schermata / prompt di accesso effettivo è inefficiente: richiede tempo ed è facilmente individuabile; molti sistemi bloccheranno un account dopo alcuni tentativi sbagliati.

Quindi, quando l'attaccante ottiene l'elenco degli hash delle password, può eseguire lo stesso hashing nel suo programma - incredibilmente veloce, e specialmente con "dicitonary" o attacchi "arcobaleno", che scambiano RAM / memoria con il tempo.

Quindi, non dovrebbe essere eseguito l'hash di tutti i campi?

Non è possibile eseguire l'hash di tutti perché la tua applicazione ha bisogno di conoscere il valore degli altri campi, semplicemente. È difficile recuperare il valore da una versione con hash, anche per un utente legittimo.

Ma in realtà, ci sono database che fanno qualcosa del genere: crittografano (non hash) anche i dati effettivi. Vuoi valutare se ne vale la pena dal punto di vista delle prestazioni e devi quindi assicurarti che la crittografia fornisca effettivamente una sicurezza reale. Cioè, 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 decrittografate (stesse idee dell'inizio => all'interno dei lavori e la difficoltà di rendere la chiave di crittografia più sicura di le password effettive che volevi proteggere in primo luogo).

Michael Green
2016-10-31 07:29:23 UTC
view on stackexchange narkive permalink

Perché non è solo l'accesso remoto e non autorizzato che deve essere protetto. A volte interi data center scompaiono. Una volta che i malintenzionati hanno i dischi che contengono i file del database, possono essere letti a loro piacimento. Quindi tutti i dati non crittografati possono essere presi: numeri di carte di credito, nomi, indirizzi, e-mail, numeri di telefono, cronologia degli acquisti. Qualsiasi cosa che faciliti il ​​furto di denaro o il furto di identità.

La buona pratica corrente è crittografare tutto ciò che è identificabile personalmente o finanziariamente sensibile. Diversi DBMS supportano la crittografia a riposo (cioè sul disco) e in volo (durante il trasferimento dal server DB all'applicazione).

Arjun sharma
2016-10-29 08:08:59 UTC
view on stackexchange narkive permalink

È così facile hackerare un database?

No, non è così facile. Una configurazione mal configurata è ciò che rende i database vulnerabili e li espone agli aggressori. Si dovrebbe applicare qualsiasi patch disponibile per la versione del database che viene utilizzata e, se possibile, eseguire l'ultima versione.

Voglio dire invece di trovare nuovi modi per l'hash, perché non possono rendere il loro database più sicuro oa prova di hacker?

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.

perché l'hashing?

  1. L'hashing garantisce all'utente finale che i token e le password segreti siano archiviati in un formato irreversibile.

  2. L'hashing garantisce che l'applicazione che sta accedendo al database non abbia accesso ai dati segreti in formato di testo non crittografato.

  3. L'hashing anche impedire che i dati segreti vengano esposti anche agli amministratori di database e di sistema.

Se un hacker riesce ad entrare in qualche database, perché vorrebbe conoscere le password con hash? Voglio dire che può cambiare altre colonne di dati. Ad esempio, potrebbe cercare il suo nome utente e aumentare il suo saldo bancario. Quindi, non dovrebbe essere eseguito l'hash di tutti i campi?

Deturpare il database nascosto attraverso le applicazioni che vi hanno accesso è diverso dall'entrare nel server del database. Se un utente malintenzionato viola il server che ospita il database, ovviamente può fare tutto ciò che è consentito per qualsiasi livello di privilegio a cui ha avuto accesso.

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

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

Perché solo le password vengono sottoposte ad hashing?

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

Tomas Kubes
2016-10-30 23:38:39 UTC
view on stackexchange narkive permalink

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'attività di e-shop individuale con un budget limitato. Questa azienda non può permettersi una soluzione costosa. La loro scelta è scegliere quella più economica o niente. La sicurezza non è una scelta, perché non hai soldi per farlo. La sicurezza inizia a essere importante con la crescita dell'azienda.

La domanda parla di hash, ma la tua risposta riguarda la crittografia.


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