Ho la password "data / hash", dopo cosa?

Aumentare il valore del lavoro, che renderà esponenzialmente più difficile la vita di un hacker. Usa un salt casuale per ogni password, che lo renderà tale che un hacker deve generare dizionari di attacco unici per ciascun utente. Usa un pepe codificato nell'applicazione per aggiungere un elemento nascosto agli hash che l'hacker sarebbe forzato alla forza bruta.

Qualsiasi tentativo di nascondere il metodo utilizzato per hash la password è la sicurezza tramite l'offuscamento, che di per sé non è realmente la sicurezza.

Ci sono diversi scenari che possono verificarsi se un utente malintenzionato accede al tuo database, ne analizzerò alcuni.

Nessun sale / stesso sale per ogni voce. In questo scenario, l'utente malintenzionato può rompere tutti i password degli utenti in un colpo solo. Dato che l'unica variazione di cui devo preoccuparmi è la password stessa, posso eseguire l'hash una sola volta e controllare tutti i 10.000 utenti.

Sale unico per ogni voce, sale aggiunto all'hash. In questo scenario, posso solo violare le password degli utenti una alla volta. Diciamo dei tuoi 10.000 utenti, 300 avevano la password "password". Invece di pensare che 300 dei tuoi utenti avessero quella password in una sola volta, avrei dovuto ripassare con gli utenti 100.000 volte per controllarli tutti.

Sale unico + pepe hardcoded. Questo scenario dipende dalla profondità di un'intrusione che soffri. Se ottengono l'accesso ai server delle applicazioni, potrebbero annusare il pepe. Se non è così, invece di dover indovinare la password, devo anche indovinare il pepe. L'unico problema è che non ho modo di dire se sono vicino. Se dovessi scegliere di usare un pepe lungo 128 caratteri, inizialmente generato usando una libreria crittograficamente protetta, dovrei forzare la parte superiore della password, praticamente distruggendo gli attacchi basati sul dizionario.

Il nostro obiettivo è quello di rendere infernale l'attacco da parte di un aggressore alle password, facendo le cose in modo tale che l'attaccante non abbia altra scelta che sedersi e aspettare un'eternità.

Nota a margine, se il database delle password è stato mai compromesso, è necessario contrassegnare immediatamente tutti gli account e al successivo accesso richiedere all'utente di seguire la procedura di reimpostazione della password, non la procedura di modifica della password. Ciò ti consente di verificare l'identità degli utenti utilizzando un canale laterale per garantire l'autenticità della richiesta.

Se vuoi tempo, usa il contatore salino e iterativo alto per calcolare i costi. Opzionalmente, anche un pepe che viene memorizzato sul lato server, possibilmente al di fuori della radice dell'app e chiamarlo quando necessario. Dipende dal tipo di app che hai ma per i siti web è importante farlo nel caso in cui PHP smetta di analizzare il codice.

In tal caso, un utente malintenzionato otterrà anche la formula su come viene generato l'hash in primo luogo. Ma mancherebbe ancora il pepe. Se il server viene violato, d'altra parte, l'utente malintenzionato ottiene entrambi, oltre all'accesso al database.

Da questo punto in poi, sei in guai seri perché l'attaccante ora sa come generare l'hash, sa quali sono i valori di sale e pepe, il che significa che può facilmente cambiare temporaneamente l'hash della password con la sua password preferita e accedere al conto di sua scelta.

Potrebbe anche decidere di scansionare o esportare l'intero database, il che significa rubare le informazioni dalla fonte. Dipende da quanto è grande il tuo database e se la tua app utilizza un solo database.

Quindi, in sostanza, le password di cracking vengono per ultime in previsione che molti utenti usano ancora le stesse password per più account. Il che ci riporta alla risposta originale. Usa sale unico e da 5k a 10k di iterazioni per rendere il calcolo degli hashard costoso. Puoi salire fino a un milione ma qualsiasi valore superiore a 10k potrebbe causare problemi di prestazioni. In questo modo, potrebbero volerci anni per rompere le password ragionevoli. È per questo che alcuni siti web richiedono l'utilizzo di lettere maiuscole, numeri e caratteri speciali ... semplicemente per aumentare il pool di risorse.

Da una nota a margine, invece di andare a tali lunghezze, un utente malintenzionato dovrebbe piuttosto estrarre la tua password semplice per qualsiasi account che desidera con un keylogger o un attacco di reindirizzamento DNS a un sito fasullo. Verrà dopo il dispositivo invece di cercare di violare il server. Se questo è lo stesso, è meglio proteggere il tuo server, il che significa proteggerlo sia da remoto che fisico.