Perché le password dovrebbero essere crittografate se vengono archiviate in un database sicuro?

Ho un servizio web. In questo momento, ho le password memorizzate in testo normale in una tabella MySQL sul mio server. So che questa non è la migliore pratica ed è per questo che ci sto lavorando.

Perché le password dovrebbero essere crittografate se vengono archiviate in un database sicuro? Mi rendo conto che se qualcuno entra nel mio database otterrà la password di tutti. Ma ho altri problemi se qualcuno entra nel mio database, ad esempio, eliminando i dati.

Lo scenario a cui riesco a pensare è che sei stato violato. Hai ripristinato un database da un paio d'ore fa e tutto va bene. Tuttavia, se le tue password sono in chiaro ... Il ladro ha tutte le password e devi reimpostarle tutte. Non preoccuparti per i tuoi utenti.

Se le password fossero crittografate, è possibile ripristinare il database precedente. È questo il pensiero corretto?

Innanzitutto, dovresti essere più libero con i diritti di accesso in sola lettura rispetto alla lettura / scrittura. Potrebbe essere possibile che un hacker abbia accesso ai tuoi dati ma non sia in grado di modificarli.

Ma, cosa molto più importante, non si tratta di te. Il fatto che potresti essere fregato se qualcuno ha pieno accesso al tuo database è irrilevante. Molto più importanti sono i dati dell'utente.

Se ripristini il tuo database, l'hacker ha ancora accesso all'account del tuo utente.

E chi sa cos'altro? Cosa succede se utilizzano la stessa password su Google? O PayPal? Che cosa succede se questo dà a un hacker l'accesso al cognome da nubile della madre o alle ultime 4 cifre della sua carta di credito?

E se ciò li inserisse in altri account? Non superare un hacker per passare attraverso un sistema di supporto utente e ottenere maggiori informazioni .

Solo ... solo non farlo. Queste sono le informazioni private del tuo utente e non devi essere in grado di vederle. È anche la tua reputazione. Crittografalo.

EDIT: un commento in più, per salvare qualsiasi lettore futuro dalla lettura di ogni risposta e commento ...

Se stai per crittografare (nel senso più stretto) allora devi usare una coppia di chiavi pubblica / privata , il che va bene ma rende la vita un po 'più difficile sia per te che per il tuo utente.

Una soluzione più semplice e altrettanto efficace è quella di random salt e hash della password. Hash da solo non è abbastanza; se l'utente utilizza una password comune, verrà visualizzata nelle tabelle con hash inverso, che sono prontamente disponibili con una semplice ricerca su Internet.

Se vieni violato, puoi ripristinare il sito dai backup e risolverlo. Ma l'hacker ha ancora password per gli account di tutti! Ci sono esempi documentati del mondo reale di ciò che accade (Sony, Linked-in), in cui se le tabelle delle password fossero state correttamente hash e salate, proteggere e ripristinare rapidamente il servizio sarebbe stato molto più semplice.

È probabilmente una buona idea presumere che verrai hackerato, progettare la tua strategia di backup e crittografare tutti i dati sensibili tenendo presente questo presupposto. E non sono solo gli hacker che devi proteggere. Dipendenti scontenti, disonesti o semplicemente all'oscuro potrebbero rivelare password in chiaro.

Senza hashing dovrai disabilitare l'accesso per tutti fino a quando non cambieranno la loro password (che, anche se possibile, sarà un grosso mal di testa per tutti). Se le password fossero state sottoposte a hash e salate, è possibile ripristinare il servizio Web e sarebbe molto più difficile per un utente malintenzionato ottenere l'accesso agli account delle persone.

Una password correttamente hash e salata è sostanzialmente a senso unico. Non è possibile indovinare facilmente la password dalla password con hash. Anche tu, poiché il fornitore di servizi non sarà in grado di indovinarlo, puoi solo ripristinarlo.

Inoltre, come ha detto Elin, non provare a creare il tuo hashing (o crittografia). Utilizzare una libreria standard.

Ma ho altri problemi se qualcuno entra nel mio database, cioè l'eliminazione dei dati.

Non riguarda i problemi che hai, riguarda i problemi che potrebbe causare a tutti gli altri utenti. Si tratta di rimuovere la tentazione (o peggio, la potenziale responsabilità) per le persone che lavorano sul sito di abusare dei dati memorizzati lì.

Vedi, anche se le persone dovrebbero usare password diverse su sistemi diversi, la realtà è che non lo fanno .

... e poiché è così facile eseguire l'hashing delle password, non hai scuse per non seguire le migliori pratiche del settore.

Gli attacchi evidenti come l'eliminazione dei dati sono generalmente roba da dilettanti e sono il minimo delle tue preoccupazioni. Una delle prime cose che un utente malintenzionato esperto farà è tentare di ottenere un accesso legittimo, quindi anche se correggi la vulnerabilità originale che ha usato, sarà comunque in grado di entrare. Farà tutto il possibile per evitare di attirare l'attenzione su di sé fino a quando realizza ciò che desidera. Lasciando immutate le password, hai potenzialmente reso il suo lavoro molto più semplice. Hai anche reso più difficile rilevare e isolare il suo comportamento dannoso futuro.

Inoltre, non tutti i compromessi offrono un accesso completo alla shell. Cosa succede se la vulnerabilità utilizzata da un utente malintenzionato è solo un'iniezione SQL di sola lettura sulla userstabella? Lasciare le password invariate gli ha dato praticamente pieno accesso.

Ciò si aggiunge alle ragioni fornite da altre risposte sulla tua responsabilità di salvaguardare i dati dei tuoi utenti. Il mio punto è che non sono solo i tuoi utenti che hanno qualcosa da perdere.

Devo pubblicare qui una risposta su un errore nella domanda stessa. Stai chiedendo se le password devono essere crittografate. Nessuno crittografa le password; nessuno, ad eccezione di servizi e programmi come Firefox Sync e Roboform, il cui unico scopo è crittografare le password.

Diamo un'occhiata alle definizioni:

Nella crittografia, la crittografia è il processo di codifica dei messaggi (o delle informazioni) in modo tale che solo le parti autorizzate possano leggerlo.

E hashing:

Una funzione hash è qualsiasi algoritmo che associa dati di lunghezza arbitraria a dati di lunghezza fissa.

In altre parole, la crittografia è una conversione a due vie e l'hash è una conversione a una via , quindi a meno che non si decifri per visualizzarle in un secondo momento, questa non è crittografia.

Inoltre, non solo hash, sale ! Leggi l'intera pagina prima di inserire le tue password.

Per quanto riguarda gli algoritmi di hashing, che ora sta esaminando l'OP, suggerirei una delle varietà di fascia alta SHA-2, come SHA-384 o SHA-512.

E assicurati di usare round di hashing . Non hash una volta, hash più volte.

Prendi in considerazione la possibilità di leggere questa pagina per proteggere maggiormente la procedura di accesso.

In secondo luogo, il tuo database non può mai essere abbastanza sicuro. Ci saranno sempre falle nella sicurezza e rischi in continua evoluzione. Dovresti seguire la Legge di Murphy e prepararti sempre alla peggiore eventualità.

Gli altri punti che pdr sottolinea sono esattamente cos'altro direi: persone che usano la stessa password per ogni sito Web, hacker che usano il social engineering per ottenere maggiori informazioni, ecc. Ecc.

C'è un principio importante in gioco qui. C'è solo una persona che ha un'attività che conosce una password utente. Questo è l'utente. Non la moglie / il marito, il medico o il prete.

Non include sicuramente il programmatore, l'amministratore del database o il tecnico di sistema responsabile del servizio che stanno utilizzando. Ciò crea una sfida, poiché il programmatore ha la responsabilità di ricevere la prova che l'utente conosce effettivamente la password, che è un problema non banale da risolvere in modo puro.

La soluzione pura è quella di avere un meccanismo in cui l'utente è sfidato con alcuni dati nuovi e imprevedibili, e quindi deve restituire una risposta basata su questi dati e sulla loro password. Un'implementazione di questo sarebbe chiedere all'utente di firmare digitalmente alcuni dati appena generati con la loro firma digitale e potremmo dimostrare matematicamente che hanno usato la stessa coppia di chiavi crittografiche che hanno usato per creare originariamente l'account.

In pratica, le soluzioni pure richiedono una sostanziale infrastruttura ed elaborazione lato client e, per molti siti Web, ciò spesso non è appropriato per i dati protetti.

Una soluzione più comune sarebbe:

Nel momento in cui una password viene ricevuta per la prima volta nell'applicazione, la password viene passata alla funzione di hashing, insieme al valore 'salt' casuale dell'applicazione nella funzione di hash.

La stringa originale viene quindi sovrascritta in memoria e da questo punto in poi l'hash salato viene archiviato nel database o confrontato con il record del database.

Gli aspetti chiave che forniscono sicurezza qui sono:

1. La conoscenza dell'hash non fornisce direttamente l'autenticazione.
2. Il calcolo inverso della password dall'hash non è pratico.
3. L'uso di tabelle arcobaleno (lunghi elenchi di password e loro hash calcolati) è reso più impegnativo perché l'hash risultante dipende sia dal nome utente che dalla password.

È necessario "crittografare" (in realtà "hash", per una corretta nozione di hashing) le password come secondo livello di difesa : ciò ha lo scopo di impedire a un utente malintenzionato, che ha avuto una visione di sola lettura del database, di aumentare che in accesso in lettura e scrittura e, precisamente, iniziano a modificare i dati. Nel mondo reale si verificano violazioni parziali di sola lettura, ad esempio attraverso un attacco di iniezione SQL da un account con accesso di sola lettura o recuperando un disco rigido scartato o un vecchio nastro di backup da un cassonetto. Ho scritto a lungo su questo argomento lì .

Per quanto riguarda i modi corretti di hash delle password, vedi questa risposta . Ciò comporta sali, iterazioni e, soprattutto, non inventare i propri algoritmi (la crittografia fatta in casa è una ricetta sicura per il disastro).

Non ripeterò ciò che hanno detto altre persone, ma supponendo che abbiate PHP 5.3.8 o migliore, dovreste usare il nativo PHP bcryptper memorizzare le password. Questo è integrato in PHP. Se hai PHP 5.5 puoi usare la migliore costante di password disponibile. Puoi anche usare una libreria per far sì che 5.3.8 o meglio si comporti come 5.5.

Stack Overflow question Come usi bcrypt per le password di hashing in PHP? lo spiega, e le altre risposte lì spiegano di più. Per favore, non scherzare cercando di farlo da solo.

Concordo con la risposta di pdr, per i motivi indicati in tale risposta.

Vorrei aggiungere quanto segue: dovresti farlo perché è facile da fare e generalmente accettato come best practice per qualsiasi applicazione. Più specificamente, le password devono sempre essere salate e cancellate prima di scrivere su qualsiasi archivio persistente. Ecco un buon riferimento sull'importanza della salatura e della scelta di un buon hash crittografico (che fornisce anche codice sorgente gratuito in diverse lingue popolari): https://crackstation.net/hashing-security.htm

La piccola quantità di tempo di sviluppo aggiuntivo merita la protezione che offre ai tuoi utenti e alla tua reputazione di sviluppatore.

Lo scenario a cui riesco a pensare è che sei stato violato.

Un altro scenario a cui devi pensare: qualcuno ha fatto scivolare il tuo DBA (o chiunque altro può eseguire query selezionate sul tuo DB) $ 100, per dare loro le password degli utenti. O ingegneri sociali qualche stagista per farlo.

Quindi usano quelle password per accedere a Gmail ... o al sito commerciale dell'utente (perché le persone sono ... meno intelligenti che dovremmo dire - e usano la stessa password su tutti i siti).

Quindi l'utente irato fa causa alla tua azienda per aver esposto la sua password.

NESSUNO (comprese le persone della tua azienda) dovrebbe essere in grado di leggere la password in testo semplice. Mai. Non c'è bisogno legittimo di affari o tecnici per quello.

Per uno, anche gli amministratori di database non dovrebbero vedere le password degli utenti. Hashing li impedirà nel caso in cui l'amministratore decida di cercare una password e accedere all'account dei propri utenti.

Bene, è sorprendente che nessuno lo abbia ancora menzionato, ma che dire della sicurezza FISICA del tuo database?

È possibile che sia impostata la migliore sicurezza IT al mondo, ma ciò non impedisce a nessuno di ottenere l'accesso fisico ai supporti di archiviazione. Cosa succede quando la tua squadra vince il Superbowl questo pomeriggio e una piccola rivolta esplode nel centro della tua città, dove si trova il tuo ufficio / fornitore di hosting? (Dato che si tratta di Seattle contro Denver, due grandi aree IT negli Stati Uniti, non credo sia irragionevole). La folla si schianta contro il tuo edificio e mentre le autorità sono sopraffatte, qualcuno prende un po 'del tuo hardware con un DB che contiene password in chiaro?

Cosa succede quando i federali si presentano e sequestrano la tua attrezzatura perché alcuni dirigenti di alto livello stavano usando la sua posizione nella compagnia per eseguire operazioni illegali? Quindi i federali usano quelle password per indagare sui clienti, anche se non hanno fatto nulla di male. Poi si rendono conto che sei stato TU a renderli vulnerabili.

Cosa succede quando il tuo reparto IT si dimentica di cancellare le vecchie unità RAID che contenevano il tuo DB quando eseguono sostituzioni pianificate prima di "distribuire" le vecchie unità agli stagisti, e poi i loro compagni di stanza del dormitorio trovano ciò che è rimasto indietro e scoprono che possono " venderlo "e non gli hai mai fatto risalire?

Cosa succede quando il tuo DB Server fa esplodere una scheda madre, l'IT ripristina un'immagine sul tuo nuovo server e la "carcassa" del vecchio server viene gettata nell'heap di riciclaggio? Quelle unità sono ancora buone e quei dati sono ancora lì.

Qualsiasi architetto decente sa che la sicurezza non è qualcosa che "si attacca" in seguito con i firewall e le politiche operative. La sicurezza deve essere una parte fondamentale del progetto fin dall'inizio, e ciò significa che le password sono unidirezionali, non vengono MAI trasmesse senza crittografia (anche all'interno dei propri data center) e mai recuperabili. Tutto ciò che può essere recuperato può essere compromesso.

Mettere da parte il caso in cui il tuo database sia stato violato: come cliente non vorrei che TU conoscessi la mia password. So che puoi facilmente catturare la password quando arriva su una richiesta, ma ho una sensazione migliore quando non la hai a disposizione per interrogare ogni volta che vuoi.

Se le password sono memorizzate in testo semplice, ciò significa che sono note all'utente e a chiunque abbia accesso a quella tabella. L'idea generale sull'implementazione di utenti e password è quella di garantire che una determinata sessione nel proprio sistema appartenga a tale persona, sia per motivi di privacy che di sicurezza.

Se un nome utente / una password sono conosciuti da un gruppo di persone, diventa inutile identificare una persona in modo inequivocabile e ciò crea molti scenari possibili per il furto di identità, la frode ...

Ecco perché le password vengono archiviate utilizzando protocolli di crittografia asimmetrica, per essere sicuri di poterle validare senza essere in grado di leggerle.

Penso che ci sia un difetto fondamentale nella domanda. Il fatto è che non esiste un "database sicuro". Dovrebbe essere considerato come un dato di fatto che ci sono difetti nel tuo sistema da qualche parte che potrebbero consentire agli utenti malintenzionati di accedere a dati arbitrari sui tuoi server. Heartbleed è un eccellente esempio, essendo un exploit che è stato in natura per oltre due anni prima che fosse notato dai ricercatori. Potresti aver fatto tutto ciò che sai come fare per proteggere i dati, ma non puoi tenere conto di tutti gli altri software che stai utilizzando sui tuoi server e dei modi complicati con cui interagiscono.

Se qualcuno ti interessa, verrai violato. È importante fare del proprio meglio per evitare di essere hackerati in primo luogo, ma anche per mitigare il danno che viene fatto quando si verificano mettendo più ostacoli possibili. Hash le tue password. Non è così difficile da configurare e stai facendo un cattivo servizio ai tuoi utenti non prendendo sul serio la loro privacy. È arrogante pensare di essere in qualche modo meglio protetti contro gli attacchi malevoli di aziende come Yahoo , Sony o Target , che sono state tutte hackerate.