Number of attempts to brute force an average password / non intrusive yet meaningful limits?

前端 未结 3 1834
无人共我
无人共我 2021-02-03 13:44

There are several useful answers on SO regarding prevention of brute forcing a password of a web service by applying throttling. I couldn\'t find any good numbers though and I h

3条回答
  •  没有蜡笔的小新
    2021-02-03 14:06

    I generally like @Tower's answer, but prefer a variant that doesn't use CAPTCHA, mostly because I hate it as a user experience.

    In addition to his fail tracking fields, also add a lockout field with a timestamp. I agree that locking out a user forever (or until manual reset) makes for a bad experience, but locking out an account for an hour (while mildly painful) is an effective deterrent.

    The change would then be that when the fail count is incremented beyond the threshold, the lockout field is set to now + 1 hour. Whenever auth is being performed, it looks at this field and if lockout > now, then it fails.

    Manually locking out accounts from an administrative perspective then becomes just a matter of setting the lockout field to some distant future value like 9223372036854775807l (max 64-bit signed long).

提交回复
热议问题