Come conserveresti un codice pin a 4 cifre in modo sicuro nel database?

Se sei preoccupato per uno scenario di "database trapelato" (piuttosto che per il vettore di cracking online, che può essere attenuato da per utente, per IP, limite di velocità per sito e blocco), allora hai ragione non è sufficiente.

Anche usando la sequenza più complessa di hash & salatura ad es. bcrypt (pbkdf2 (sha256 (pin), salt1), salt2) sarai ancora vulnerabile a chiunque possa vedere (ad esempio da una perdita di codice sorgente / docs) quali algoritmi vengono utilizzati e chi può trovare i tuoi sali (normalmente memorizzati in lo stesso DB / tabella) - possono solo eseguire la stessa serie di hash, e anche se ci vuole un minuto per ciascuno è solo 7 giorni per provarli tutti. Quindi baseresti fondamentalmente sulla sicurezza per oscurità.

In questo caso sarebbe opportuno crittografare gli hash delle password con una chiave segreta (che può essere mantenuta separatamente dal codice sorgente, accessibile solo agli utenti fidati "operazioni di sicurezza di produzione", mai riutilizzata negli ambienti di pre-produzione, cambiato regolarmente, ecc.). La chiave segreta dovrà essere presente sul server che convalida / aggiorna i codici PIN, ma può essere tenuta separata dal database utente / pin (ad esempio in un file di configurazione crittografato), il che significa che Little Bobby Tables non otterrà automaticamente accedi ad esso quando snarfs l'intero T_USERS tramite SQL injection, o quando qualcuno prende un DVD con un backup del DB su di esso dalla scrivania del tuo sysadmin.

[Normalmente, la crittografia degli hash non è consigliata, perché è meglio usare un hash sicuro, una buona password e una buona password / frasi e la crittografia degli hash può dare un falso senso di sicurezza. Ma se non puoi avere password sicure, non ci sono molte altre opzioni - i mendicanti non possono essere selezionatori ...]

Potresti combinare il PIN con una password, ma in tal caso perché preoccuparti del PIN? Basta richiedere una password alfanumerica strong. (Se il PIN viene utilizzato in combinazione con una smartcard o un token o simili, ovviamente, può essere aggiunto alla sicurezza generale.)

Potremmo usare un PIN più grande (6/8 cifre). Non è fattibile rendere sicuro un PIN di sola cifra dalla forza bruta: a 1 B hash al secondo, avremmo bisogno di 16 o più cifre per spingere il tempo di forza bruta oltre un anno. Ma aggiungere qualche cifra in più potrebbe essere sufficiente per rendere più facile il rilevamento e il blocco dell'attacco online - con solo 10K combinazioni sarà difficile impostare soglie di "forza lenta" sufficientemente basse da rendere un attacco non fattibile. Sfortunatamente, probabilmente hai dei vincoli fisici (selezione dell'hardware) che precludono PIN più lunghi.

Gli schemi di hashing delle password come bcrypt hanno lo scopo di fornire una certa sicurezza nel seguente contesto: l'utente malintenzionato può leggere qualsiasi informazione memorizzata per verificare la password (ad esempio ottiene un dump del database tramite un attacco SQL injection). Con un PIN di 4 cifre, l'entropia è troppo bassa per fornire molta resistenza in questa situazione, anche con enormi sali e conteggi di iterazione di grandezza biblica. Pertanto, se si utilizza un PIN di 4 cifre, si presume che l'utente malintenzionato non possa accedere alle informazioni di verifica della password, nel qual caso è possibile semplicemente archiviare i PIN "così come sono".

Anche se l'attaccante deve passare attraverso il normale processo di autenticazione per ogni ipotesi (si tratta di un attacco del dizionario online : per ogni ipotesi, l'attaccante deve interagire con l'utente o il server, o entrambi), 10000 possibili PIN sono una cifra molto bassa. Quindi una sicurezza adeguata può essere raggiunta solo imponendo ritardi arbitrari - il caso estremo è quello che le smartcard di solito fanno, cioè si bloccano dopo tre PIN errati (una smart card bloccata è come un ritardo infinito). Questo è delicato con i servizi di rete, perché non vuoi che le persone siano in grado di bloccare i conti di altre persone.

Le due cose comuni che limitano questo tipo di attacco sono:

• per le applicazioni sensibili il PIN è spesso aggiunto a una password
• il forzamento bruto non è consentito, di solito da un blocco dopo 3 o 5 tentativi. A volte il dispositivo di input impone anche l'inserimento lento del PIN oltre al blocco, come ulteriore difesa.

Non dici quale sia la tua applicazione, ma potresti considerare di utilizzare un server back-end dedicato per verificare i pin.

È quindi possibile limitare l'accesso a quel server più del possibile per il server Web front-end. È possibile implementare restrizioni come la limitazione della velocità sul server di controllo pin in modo che anche se il server front-end viene rilevato da un utente malintenzionato, avranno problemi con i pin forzanti.