1

Suppose you have a lock on your door with a keypad 0-9. A person can enter a digit combination of maximum 10 characters. They get three attempts before the door is locked for 1 hour.

If you had that door on your house, how long of a password/code would you choose? 4-digit, 6-digits etc?

When is secure secure enough? What is the lowest one could go and still consider it secure? What does it mean to be secure?

Real world: A client has requested that we minimize the password requirement on a system for users accounts, preferably down to 4 digits digits and have other measures such as ratelimits/account lockout etc but it feels that a 1 / 10000 chance of entering a correct password is too high of a probability even if they only get X(few) attempts per day. What is the lowest / simplest one could go with additional measures in place and still consider it secure, assuming that an attacker gets three attempts before the account is locked?

Addition:

  • The service is a Skype-like service
  • The lockout would work like no new logins would be allowed for the duration of the lockout
  • If a correct password is provided upon a login when a lockout has occurred in the past, an SMS would be sent to the user with a second token that they would need to enter to login
  • Any client that is already logged in wouldn't be logged out during a bruteforce of their account, hence the chance of them having to go through the SMS secondary validation is slim

closed as primarily opinion-based by a CVn, Xander, Serge Ballesta, TheJulyPlot, Steve Jul 11 '17 at 20:03

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • Not enough context. How important is the system? What's the real-world damage someone guessing the password could cause? I have very different requirements for, example, my library card vs. my bank account... – Joe Jul 11 '17 at 14:39
  • 3
    It's meaningless to talk about "secure enough" if you don't define the threat model. Also, that threat model should absolutely include the threat of denial of service. If I can lock a user out for even a limited period of time by hitting the account a few times, that in itself becomes a trivial attack (which is the problem with all "lock account after X failed tries" schemes). There are far less blunt options available. – a CVn Jul 11 '17 at 15:05
  • Updated with some additional information. The main question here is how secure is defined, what is the highest probability one can accept and still think about it as secure? A one time attempt with 50% probability of succeeding would be deemed insecure, what about 5%? What about 0.5% etc? When does it in general start to become secure? – grandnasty Jul 11 '17 at 16:48
1

I think your client needs to update their threat model. Online password guessing is not the only thing which should drive password complexity. The client needs to understand how how password cracking works. If your password hashes are ever compromised (via SQL injection, improperly stored database backups, etc), an attacker is going to try cracking those passwords offline with a tool like hashcat, rather than guessing them against the website itself, where account lockout could come into play. 4 digits is NOT enough security for any system. Even the slowest hashing algorithm can complete that work in under a second with a modern video card.

If there are concerns about usability regarding passwords, I would suggest that users use a password manager. If that's too much effort, all modern web browsers can also save the user's password if portability is not an issue.

  • They would store them with bcrypt, hence the hashing/guessing from hashes wouldn't be a problem. – grandnasty Jul 11 '17 at 16:37
  • It sounds like you may not understand how password cracking works. Password cracking involves guessing a password, running it through bcrypt, and then seeing if that hashed value matches the hashed value that was stolen from the database. The 1 second estimate I quoted you was the benchmark for bcrypt. Even if you increase the number of rounds that crypt uses, and properly salt your hashes, it's still only going to add a negligible amount of time on to each password. – user52472 Jul 11 '17 at 16:50
  • Yes, sorry, I meant to say a long random salt together with brcrypt. However, as you said, if they get access to the DB and the random salt is stored in the same DB then it doesn't matter, for a specific account the hacker could calculate a 4 digit password quickly. My main question was more a theoretical one, at what probability levels for a password guess attempt does one start to think about a password as being secure? Please see my comment on the initial entry. – grandnasty Jul 11 '17 at 17:00
  • It's not a matter of probability so much a function of time/server resources. Once an attacker has your hashes, its only a matter of time before they are able to crack the passwords. More time = more secure. In this instance, a 10 digit password hashed with MD5 is not as secure as a 5 digit password using bcrypt. – user52472 Jul 11 '17 at 17:10
  • Yes, but as in the original question please assume that they do not have the database. Suppose an american bank, the hacker has the username of the user and will do one, and only one, attempt to login, nothing more. What is the minimum password policy a bank could allow and still call itself secure under the assumption I just wrote? I understand that if the assumption changes, the probability would change as well. – grandnasty Jul 11 '17 at 17:13

Not the answer you're looking for? Browse other questions tagged or ask your own question.