Per che cosa ho hash password utente con PDKDF2 quando i dati dell'utente sono memorizzati nello stesso database?

Un utente malintenzionato potrebbe non dover accedere al tuo database per ottenere le password dei tuoi utenti.

In base alla progettazione, i dati memorizzati in un database sono separati dalle tabelle. Informazioni come nomi utente e password dovrebbero trovarsi in una tabella diversa dai dettagli dell'utente come nome e così via. Questa è la progettazione dello schema del database di base.

Se un utente malintenzionato compromette la tua applicazione utilizzando tecniche come le iniezioni SQL, potrebbe essere in grado di accedere solo alla tabella contenente le password.

Anche supponendo che l'attaccante riesca a ottenere l'accesso all'intero database, ci sono altri fattori da considerare. Le informazioni dell'utente non sono l'unica cosa importante nella tua applicazione. Se l'attaccante cambia direttamente le informazioni nel database, molto probabilmente le sue azioni verranno registrate. Ciò rende relativamente facile trovare e correggere eventuali modifiche indesiderate.

Tuttavia, se l'utente malintenzionato accede a un account utente tramite la pagina di accesso dell'applicazione, sarebbe difficile differenziare l'accesso previsto e non intenzionale. Potrebbe causare un sacco di danni potenziali.

Inoltre, molti utenti usano le stesse combinazioni nome utente / password su più siti. Se un utente malintenzionato compromette le informazioni dell'account sul tuo sito, potrebbe potenzialmente accedere a tutti gli altri account online dell'utente. Questo è male.

Elimina sempre le tue password.

Le persone tendono a riutilizzare le password per siti diversi. Non riescono a ricordare 20 diverse password sicure per 20 siti diversi! L'utilizzo di un hash password sicuro è un modo responsabile per limitare il danno nel caso sfortunato di un compromesso del sito. I loro dati sul tuo sito saranno esposti, ma non subiranno compromessi su account di alto valore (sia per loro stessi che per gli aggressori) come Facebook (spam), Gmail (compromissione completa dell'identità online) o Amazon (consente acquisti tramite i dettagli della carta di credito salvati automaticamente dell'utente, senza richiedere CVV).

(No, i nomi completi e i nomi utente non dovrebbero essere in tabelle separate come una questione di "progettazione dello schema di base del database". Ogni utente ha un nome e un nome utente, quindi dovrebbero essere nella stessa tabella. i dati come una rubrica degli indirizzi e-mail degli amici sono probabilmente suddivisi tra più tabelle, quindi sono d'accordo che l'uso di PDKDF2 potrebbe aiutare a limitare il danno di un'iniezione SQL solitaria).

Se le tue password non sono hash, ma memorizzate "così come sono", un utente malintenzionato che ottiene un accesso di sola lettura al database impara immediatamente tutte le password, permettendogli di accedere come qualsiasi utente e fai tutto ciò che questi utenti possono fare, il che include, come dici tu, modificare le loro informazioni personali. Ciò significa che l'utente malintenzionato può eseguire l'escalation dell'accesso in sola lettura a un accesso in lettura-scrittura.

L'accesso in sola lettura non è uno scenario improbabile. Questo è ciò che l'aggressore ottiene quando ruba un vecchio nastro di backup.

Vedi questo post del blog per ulteriori dettagli.