Limita il tentativo di accesso utente a PBKDF2

1) Is my rationale for wanting to limit the number of tries a user can login reasonable ??

No, assolutamente non nel modo in cui lo descrivi. Va bene limitare il numero di tentativi non riusciti in un breve periodo di tempo e ridimensionarlo da lì, ma non dovresti mai impostare un limite rigido per un lungo periodo come un intero giorno. Chi sei tu per dirmi che non posso accedere al mio account per la ventesima volta oggi?

2) Are there any flaws in my argument

Sì. MD5 / SHA1 / SHA256 / SHA512 ecc è stupidamente imperfetto per l'hashing della password. Inoltre, PBKDF2 è stato ampiamente utilizzato per un certo numero di anni. Non ci sono segni che sarà rotto "in pochi anni". Vedi questa risposta per ulteriori dettagli.

3) Is my boss correct ???

Assolutamente sì.

Penso che il punto che stai confondendo qui è la differenza tra gli attacchi di forza bruta online e offline . Essenzialmente i due controlli che stai guardando sono progettati per attacchi diversi e dovrebbero essere entrambi applicati (cioè non è l'uno o l'altro)

La tua idea di limitare i login degli utenti prima del blocco si riferisce a un attacco di forza bruta online. ciò si verifica quando un utente malintenzionato tenta di indovinare la password tramite l'applicazione. Di solito raccomando 10 login errati prima del blocco, il ragionamento è che se un utente non può indovinare la password in 10 tentativi l'hanno dimenticato :).

L'algoritmo di hashing utilizzato per archiviare le password difende principalmente dagli attacchi di forza bruta offline. Questi si verificano quando l'utente malintenzionato ha accesso alle password con hash e può provare a craccarle direttamente (ad esempio non tramite l'applicazione). Qui sarebbe corretto utilizzare PBKDF2 (o bcrypt o scrypt) poiché sono progettati specificamente per questo scopo e rallenterà il processo di induzione degli hacker.

Il problema dell'utilizzo di MD5 o SHA-1 è che questi non sono progettati per la memorizzazione di password, sono (parzialmente) progettati per essere veloci, che è una proprietà che non vogliamo quando si previene un attacco di forza bruta offline.

1) Is my rationale for wanting to limit the number of tries a user can login reasonable?
2) Are there any flaws in my argument?

Abbastanza , ma non completamente. Prima di tutto, 200 tentativi sono un numero enorme - la maggior parte delle persone lo manterrà sotto i 20 al giorno, e penso a 50 per un numero ragionevole di tentativi.
Tuttavia, il difetto nella tua "logica" sta bloccando le persone dai loro account. Come qualcuno ha già notato, un utente malintenzionato che conosce questa vulnerabilità potrebbe usarlo per bloccare le persone dai loro account (questo è più un troll che un attacco). Quello che ho implementato sul mio sito web è:

1. Store the number of attempts in a file (the md5 hash of the attempted username) and update it if needed
2. Retrieve the current number of attempts. If it is bigger than, say, three, ask the user to answer a CAPTCHA first.

Penso che dovresti seguire questo tipo di algoritmo, cioè Allow a reasonable number of "free" attempts, then challenge or otherwise slow down the user before logging him in .

3) Is my boss correct?

Non vedo perché seguire un particolare algoritmo, ma si , è corretto - PBKDF2 è attualmente una funzione sicura (non sono previsti attacchi). Inoltre, avere un "numero di iterazioni desiderate" è una funzionalità molto interessante, poiché aumenta lo spazio in cui vengono distribuiti gli hash (le chiavi) [questa funzione è praticamente inutile se un utente può registrarsi al servizio].
Se è davvero il caso di un ambiente ad alta sicurezza, in cui la sicurezza viene prima delle prestazioni, potresti impiegare REALMENTE PARANOID STRONG come Generazione della chiave ElGamal , insieme a bcrypt.