9
exerceo
297d

Your three-second password retry delay is far more likely to annoy users than preventing a brute-force attack.

If you insist on a retry delay, let the user enter a password five times without any delay. This would make no difference in the grand scheme, the trillions of retries needed for a brute-force attack, and guessing a password takes longer than three seconds of thinking anyway.

Another alternative is a tenth of the password retry delay but one added character. One added character slows down a brute-force attack by at least sixty-two (62) times, so one more character but a tenth of the password retry delay would still mean more than six (6) times the protection against brute-forcing.

On Linux, the password retry delay can thankfully be reduced by changing a value inside /etc/pam.d/common-auth or /etc/pam.d/login (out of scope for this post, you can search online for more details).

Comments
  • 5
    Wouldn’t be surprised if the delay was implemented on the frontend, making it even more idiotic.
  • 2
    Brute forcing by just creating strings is bs. Tried to hammer a zip file once. Six chars was how far my patience went and imagine, this was so fast as computer could go. Via an API or with delay, impossible. Useless.

    On topic: just write your password right
  • 1
    @retoor slightly smarter than simply irritating over every possible combo and cloud computing makes it feasible.
  • 0
    If the delay is in fact part of the algorithm, pin based systems or the hash is highly protected while the interface is rather public it's actually really helpful. Outside of that it's a waste of effort
  • 0
    @hjk101 cloud computing won't do a thing to brute forcing when on dem network. It goes one by one
Add Comment