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

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

Ma, cosa ancora più importante, questo non riguarda te. Il fatto che tu possa essere fregato se qualcuno ha accesso completo al tuo database è irrilevante. Molto più importante è il tuo dati dell'utente.

Se recuperi il tuo database, l'hacker ha ancora accesso all'account dell'utente.

E chissà che altro? Cosa succede se usano la stessa password su Google? O PayPal? Cosa succede se questo consente a un hacker di accedere al nome da nubile della madre o alle ultime 4 cifre della loro carta di credito?

Che cosa succede se li ottiene in altri account? Non passare a un hacker per passare attraverso un sistema di supporto utente e ottenere maggiori informazioni .

Solo ... proprio no. Quelle sono le informazioni private dell'utente e non è necessario essere in grado di vederlo. È anche la tua reputazione. Criptalo.

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

Se intendi crittografare (nel senso più stretto del termine), devi utilizzare una coppia di chiavi pubblica / privata , che va bene, ma rende la vita un po 'più difficile per te e per il tuo utente.

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

Se ti viene violato puoi ripristinare il sito dai backup e risolverlo. Ma l'hacker ha ancora le password per gli account di tutti! Ci sono esempi documentati di questo evento (Sony, Linked-in), dove se le tabelle delle password erano state correttamente hash e salate, fissando e ripristinando il sevice rapidamente sarebbe stato molto più facile.

Probabilmente è una buona idea presumere che sarà essere hackerato, e progettare la tua strategia di backup e crittografare i dati sensibili tenendo presente questa ipotesi. E non sono solo gli hacker che devi proteggere. Disgraziati, disonesti o semplicemente incapaci, i dipendenti potrebbero dare via le password in testo semplice.

Senza hashing dovrai disabilitare l'accesso per tutti finché non cambieranno la loro password (il che, anche se possibile, sarà un enorme mal di testa per tutti). Se la password fosse stata sottoposta a hash e salata, potresti ripristinare il servizio web e sarebbe molto più difficile per un utente malintenzionato accedere agli account delle persone.

Una password correttamente hash e salata è fondamentalmente a senso unico. Non è facile indovinare la password dalla password con hash. Anche tu, dato che il fornitore di servizi non sarà in grado di indovinarlo, puoi ripristinarlo solo.

Inoltre, come ha detto Elin, non tentare di eseguire il proprio hashing (o crittografia). Utilizza una libreria standard.

But I have other problems if someone gets in my database, i.e. deleting data.

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

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

... e dal momento che le password hash sono così facili da usare, non hai scuse per non seguire le best practice del settore.

Gli attacchi evidenti come l'eliminazione dei dati sono di solito di proprietà dei dilettanti e sono l'ultima delle tue preoccupazioni. Una delle prime cose che un attaccante esperto farà è tentare di ottenere un accesso legittimo, quindi anche se si patch 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 Se si lasciano passare le password in modo non veritiero, è possibile rendere il proprio lavoro molto più semplice. Hai anche reso più difficile individuare e isolare il suo futuro comportamento malevolo.

Inoltre, non tutti i compromessi ti danno accesso completo alla shell. Cosa fare se la vulnerabilità utilizzata da un utente malintenzionato è solo un'iniezione SQL di sola lettura nella tabella users ? Lasciare unhashed alle password gli ha dato praticamente accesso completo.

Questo è in aggiunta 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 una risposta qui su un errore nella domanda stessa. Stai chiedendo se le password dovrebbero 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:

In cryptography, encryption is the process of encoding messages (or information) in such a way that only authorized parties can read it.

E hashing:

A hash function is any algorithm that maps data of arbitrary length to data of a fixed length.

In altre parole, la crittografia è una conversione a due vie e l'hashing è una conversione a una sola direzione , quindi a meno che non decifri per visualizzarli in un secondo momento, questo non è crittografia.

Inoltre, non solo hash, salt ! Leggi questa pagina intera prima di cancellare le tue password.

Come per gli algoritmi di hashing, su cui l'OP sta ora esaminando, suggerirei qualsiasi dei variet di SHA-2 di fascia alta, come SHA-384 o SHA-512.

Assicurati di utilizzare cicli di hashing . Non eseguire l'hash una volta sola, hash più volte.

Prova a leggere questa pagina per proteggere la tua procedura di accesso di più.

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

Il altri punti pdr sono esattamente ciò che altro direi: la gente che usano la stessa password per ogni sito web, hacker che utilizzano l'ingegneria sociale per ottenere maggiori informazioni, ecc. ecc.

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

Sicuramente non include 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 dimostrare che l'utente conosce effettivamente la password, che è un problema non banale da risolvere in modo puro.

La soluzione pura è 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. Una implementazione di questo sarebbe chiedere all'utente di firmare digitalmente alcuni dati appena generati con la loro firma digitale, e potremmo provare matematicamente che hanno usato la stessa coppia di chiavi crittografiche che hanno usato per creare originariamente l'account.

In pratica, le soluzioni pure richiedono un'infrastruttura e un'elaborazione lato client sostanziali e, per molti siti Web, spesso non è appropriato per i dati protetti.

Una soluzione più comune potrebbe essere:

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

La stringa originale viene quindi sovrascritta in memoria e da questo punto in poi, l'hash salato viene memorizzato 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 relativi hash calcolati) è reso più difficile perché l'hash risultante è dipende sia dal nome utente che dalla password.

Devi "cifrare" (in realtà, "hash", per una nozione corretta di hashing) le password come secondo livello di difesa : ciò serve a impedire a un utente malintenzionato di ottenere un visione di sola lettura del database, dall'escalation di questo in accesso in lettura-scrittura e, precisamente, iniziare a modificare i dati. Le violazioni parziali di sola lettura si verificano nel mondo reale, ad es. tramite alcuni attacchi SQL injection da un account con accesso in sola lettura o recuperando un disco rigido scartato o un vecchio nastro di backup da un dumpster. Ho scritto a lungo su questo argomento lì .

Per quanto riguarda i metodi corretti per le password hash, vedi questa risposta . Ciò implica sali, iterazioni e, soprattutto, non che inventa i tuoi algoritmi (la crittografia fatta in casa è una ricetta sicura per il disastro).

Non ripeterò ciò che hanno detto altre persone, ma supponendo che tu abbia PHP 5.3.8 o meglio, tu dovrebbe usare il PHP nativo bcrypt per memorizzare le tue password. Questo è integrato in PHP. Se hai PHP 5.5 puoi usare la migliore costante di password disponibile. Puoi anche usare una libreria per fare 5.3.8 o meglio comportarti come 5.5.

Domanda Stack Overflow Come si usa bcrypt per le password di hashing in PHP? lo spiega, e le altre risposte ci spiegano di più. Per favore non scherzare provando a farlo da soli.

Sono d'accordo con la risposta del pdr, per i motivi indicati in quella risposta.

Vorrei aggiungere quanto segue: dovresti farlo perché è facile da fare e generalmente accettato come best practice per qualsiasi applicazione. Più in particolare, le password devono sempre essere salted e hash prima di scrivere in qualsiasi archivio persistente. Ecco un buon riferimento all'importanza della salatura e alla scelta di un buon hash crittografico (che fornisce anche codice sorgente gratuito in diverse lingue popolari): link

La piccola quantità di tempo di sviluppo extra vale la protezione che fornisce ai tuoi utenti e alla tua reputazione di sviluppatore.

The scenario I can think of is that you are hacked.

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 fornire loro le password degli utenti. O ingegneri sociali qualche stagista per farlo.

Quindi usano queste password per accedere a Gmail dell'utente ... o al sito di commercio ... (perché le persone sono ... meno intelligenti di quanto si possa dire - e usano la stessa password tra i siti).

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

NESSUNO (comprese le persone nella tua azienda) dovrebbe essere in grado di leggere la password in testo semplice. Mai. Non c'è alcuna necessità aziendale o tecnica legittima per questo.

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

Beh, è sorprendente che nessuno abbia ancora menzionato questo, ma per quanto riguarda la sicurezza FISICA del tuo database?

Potresti avere la migliore sicurezza IT al mondo, ma ciò non impedisce a chiunque possa accedere fisicamente ai tuoi supporti di archiviazione. Cosa succede quando la tua squadra vince il Superbowl questo pomeriggio e una piccola sommossa esplode nell'area del centro della tua città dove si trova il tuo ufficio / fornitore di servizi di hosting? (Dato che è Seattle vs Denver, due grandi aree IT negli Stati Uniti, non penso che sia irragionevole). La folla si schianta contro il tuo edificio e mentre le autorità sono sopraffatte, qualcuno afferra un po 'del tuo hardware con un DB su di esso che contiene password di testo libero?

Cosa succede quando i federali si presentano e sequestrano le tue attrezzature perché alcuni dirigenti di alto livello stavano usando la sua posizione nella società per eseguire transazioni di azioni illegali? Quindi i federali usano quelle password per indagare sui tuoi clienti, sebbene non abbiano fatto nulla di sbagliato. Poi si rendono conto che è TU che li ha lasciati vulnerabili.

Cosa succede quando il reparto IT dimentica di cancellare le vecchie unità RAID che contenevano il DB quando eseguivano sostituzioni pianificate prima di "distribuire" le vecchie unità agli stagisti, e quindi i loro compagni di stanza dormitorio trovavano ciò che era rimasto indietro e capivano possono "venderlo" e mai risalire a loro?

Che cosa accade quando il server DB fa saltare una scheda madre, IT ripristina un'immagine sul nuovo server e la "carcassa" del vecchio server viene gettata nell'heap del riciclaggio? Quelle unità sono ancora buone e quei dati sono ancora lì.

Qualunque architetto decente sa che la sicurezza non è qualcosa che ti "inculca" più tardi con i firewall e le politiche operative. La sicurezza deve essere una parte fondamentale del progetto sin dall'inizio e ciò significa che le password sono hash a un solo senso, NEVER trasmesse senza crittografia (anche all'interno dei propri data center) e mai recuperabili. Tutto ciò che può essere recuperato può essere compromesso.

Metti da parte il caso in cui il tuo database viene 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 ce l'hai a disposizione per l'interrogazione ogni volta che vuoi.

Se le password sono memorizzate in testo normale significherebbe che sono note all'utente e chiunque abbia accesso a quella tabella. L'intera idea di implementare utenti e password è quella di assicurare che una certa sessione nel tuo sistema appartenga a una determinata persona, sia per ragioni di privacy che di sicurezza.

Se un nome utente / password sono conosciuti da un gruppo di persone diventa inutile inequivocabilmente identificare una persona e questo crea molti scenari possibili per il furto d'identità, la frode ...

Ecco perché le password vengono archiviate utilizzando i protocolli di crittografia asimmetrica, per assicurarti di poterle convalidare 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 preso come un dato di fatto che ci sono difetti nel vostro sistema da qualche parte che potrebbe consentire agli utenti malintenzionati di accedere a dati arbitrari sui vostri server. Heartbleed è un eccellente esempio, essendo un exploit che era in circolazione 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 si interessa a te, ti viene violato. È importante fare del tuo meglio per evitare di essere hackerati in primo luogo, ma anche per mitigare il danno che viene fatto quando accade mettendo il maggior numero di ostacoli possibile. Inserisci le tue password. Non è così difficile da configurare, e stai facendo un cattivo servizio ai tuoi utenti non prendendo sul serio la loro privacy. È superbo pensare di essere in qualche modo meglio protetto dagli attacchi dannosi di aziende come Yahoo , o Sony , o Target , tutti sono stati violati.