Dovrei cancellare una password se è generata casualmente

Il punto delle password di hashing è che se l'utente malintenzionato può accedere al file della password (irrompendo nel server, rubando i supporti di backup, hackerando il provider di hosting, ecc.), non può ancora recuperare la password da l'hash e accedi come utente.

Ci sono due livelli:

1. Hai bisogno di un hashing come seconda linea di difesa, in modo che ciò che memorizzi sul server (chiamo "server" il sistema che esegue l'autenticazione con verifica una determinata password) non è sufficiente per impersonare realmente gli utenti. Ciò evita l'escalation di una violazione parziale e di sola lettura (ad esempio il nastro di backup rubato) in un accesso più completo e in lettura-scrittura. Vedi questo post del blog per una discussione più lunga.

2. Se hai cancellato la password, allora potrebbe aver bisogno di usare un funzione di hashing della password se la password di origine ha bassa entropia. Le password scelte dagli utenti umani hanno una bassa entropia. Se si generano le password "casualmente", allora può ottenere password ad alta entropia. O no. Il buon punto di generare password attraverso un processo noto e sistematico che si nutre di un PRNG crittograficamente sicuro è che puoi calcolare l'entropia, invece di limitarla semplicemente. Tuttavia, devi comunque assicurarti di averne abbastanza.

Ad esempio, se si genera una password come una sequenza di 10 caratteri casuali (lettere minuscole e maiuscole e cifre) e tutti i caratteri sono scelti in modo uniforme e indipendentemente l'uno dall'altro, allora ci sono 62 ¹⁰ possibili password e ognuna di esse ha la stessa probabilità di essere scelta rispetto a qualsiasi altra. Entropia è quindi uguale a log (62 ¹⁰ ) (logaritmo in base 2), cioè 59,54 bit. Non è male, ma forse è ancora un po 'troppo basso per il comfort se viene utilizzata una semplice funzione di hash, dal momento che una buona GPU può eseguire miliardi di MD5 o SHA-1 al secondo. Dovresti quindi aggiungere sali e iterazione, ad esempio bcrypt (ma un piccolo conteggio dell'iterazione andrebbe bene).

Se le tue password hanno almeno 80 bit di entropia, allora puoi considerare che sono abbastanza forti da sconfiggere anche attaccanti ricchi e determinati, e puoi usare un semplice hashing (cioè puoi scappare con una semplice chiamata hash < em> e anche con non usare i sali). Con lettere e cifre casuali, questo si traduce in 14 caratteri . Insisto che questo è vero solo se i 14 caratteri sono scelti casualmente, in modo uniforme e indipendentemente l'uno dall'altro. Questi sono requisiti che puoi soddisfare con il tuo generatore di password, ma non puoi realisticamente aspettarti da una password scelta dall'utente.

Dovresti trattarlo come qualsiasi altra password.

Non puoi garantire che l'utente non riutilizzerà la tua password su altri sistemi a meno che tu non li controlli - ad esempio quando dovevo scegliere una password per il mio nuovo server di posta degli ISP ho usato quello generato automaticamente dal precedente sistema in modo che lo ricordassi (per un periodo temporaneo piuttosto lungo del previsto).

Se costringi l'utente a usare una password generata casualmente, è ancora moderatamente probabile che la utilizzi per altre cose: un numero significativo la annota o la memorizza in testo in qualche luogo, ed è più facile mantenere tale lista in breve. Non puoi dare per scontato che i tuoi utenti abbiano almeno un indizio sulla sicurezza della password, e anche quelli che lo fanno potrebbero non dare abbastanza valore al tuo servizio per preoccuparti di una sicurezza decente.

Nello scenario indicato, l'avere hash password potrebbe proteggerti nel caso in cui l'utente malintenzionato ottenga l'accesso in lettura all'archivio password, ma non l'accesso in scrittura o l'accesso a nessun altro dato. In tal caso, potrebbero utilizzare la password per accedere e ottenere l'accesso a più dati.

Quando l'utente malintenzionato ottiene l'accesso in scrittura all'archivio delle password, sarà in grado di sostituire semplicemente l'hash con quello della propria password, quindi l'hashing non ti proteggerà in quel caso.

Inoltre, quando il database delle password è compromesso, si può presumere che anche altri dati sul server siano compromessi, quindi l'autore dell'attacco potrebbe non avere nemmeno un motivo per accedere.

La risposta semplice è sì.

una cosa che sembra essere ricorrente è l'idea che se l'utente ha accesso alla sezione password del db, allora ha accesso all'intero db. Questa è una buona supposizione da fare quando si proteggono i dati, ma non una buona supposizione da fare quando si tenta di giustificare le password di hashing. Quella stessa logica in teoria potrebbe essere applicata nel caso di uso normale in cui l'utente può modificare la password.

Le password in generale (non solo quelle informatiche) sono una forma di verifica rispetto a una variabile nota sulla tua estremità. Memorizzare le password in testo semplice porta a perdite di sicurezza interne e ridurrà la fiducia senza motivo.

Pensa a questo, ti fiderei delle tue informazioni personali su un sito che non ha hash le password, anche se la password aveva gli stessi requisiti?

Non penso che tu debba. L'unica cosa che devi cercare è questa: Se il tuo database è compresso, un hacker è in grado di accedere a qualsiasi account molto velocemente ed eseguire qualsiasi azione per cui i tuoi utenti hanno il permesso. Se questo sistema è collegato ad un altro servizio che potrebbe creare un casino molto velocemente. È una tua chiamata, personalmente non lo farei, ma lo considererei in base agli altri servizi a cui i miei utenti possono accedere tramite il mio programma.