Is it secure to allow an account to use `test123!` as their password?

Question

I'm working on tightening up security for the auth layer of my app and I'm currently making a call on the complexity I'll require for passwords.

Is there a 'standard' recommendation for complexity?

The current requirement is like so:

8 char minimum
a-z
At least one number
At least one of the following: !@#$%^&*

So if anyone were to choose test123! as their password, my app would allow them to use that as their password.

This is about "twice" the complexity my bank requires for my account login. They still allow 5 char, a-z, 0-9 for passwords, which seems nuts to me. But they also don't seem to be suffering from an epidemic of attacks, so it must thwart hacks just fine, 'somehow'.

Question: As an infosec professional, what minimum complexity would you require Gmail to have if it was your call?

How do I use an entropy estimator effectively?

I just found out what an Entropy Estimator is and they are wowsers cool. I haven't been this jazzed by software for a long time now.

No, I didn't input any of my passwords into any of them.

No, I don't really understand how they work.

And I'm not entirely sure how to use the information that they give me. For example, I entered test123! into the GRC Password Haystacks estimator and got these results:

GRC Password Haystacks

Search Space Depth (Alphabet):  26+10+33 = 69
Search Space Length (Characters):   8 characters
Exact Search Space Size (Count): 521,354,232,876,120 
Search Space Size (as a power of 10):   5.21 x 1014

**Time Required to Exhaustively Search this Password's Space:**
Online Attack: (100,000 guesses per second) 1.66 hundred centuries
Offline Fast Attack: (100 billion guesses per second)   1.45 hours
Massive Cracking Array: (100 trillion guesses per second)   5.21 seconds

So, ostensibly those seem like pretty good results. The likelihood of one my users being targeted by a blackhat with a massive cracking array at their disposal seems highly unlikely.

I've also implemented rate-limiting and a blacklist lockout mechanism with the following config:

- IP is used as the ID
- Rate-Limited with a max of 10rps from any given IP
- A maximum of 5 failed login attempts are allowed every 60s before an IP is blacklisted
- Blacklist duration is 5 minutes

Question: Considering the defences I've put in place, should I consider my login endpoint secure if any user decides to pick test123! as their password?

What about a Dictionary Attack?

Obviously test123! is going to be tried very close to the beginning of the attack.

If I'm allowing 5 attempts every 60s before blacklisting an IP, and the blacklist duration is 5 minutes, it seems reasonable that a determined attacker would attempt to either rate-limit their guesses to 5 per minute and then it would just take them longer to grab this low-hanging fruit, or if they really, really wanted in they could grab a new IP every 5 attempts, or string together 10,000 machines to attack with 5 attempts every minute to speed things up. Highly unlikely, but not impossible.

And this leads me to believe that there really isn't any way to protect from a dictionary attack except to force Passwords of Unusual Complexity on my users, which I really don't want to do.

And considering that Facebook, Google, etc. don't seem to have these requirements there must be some way to protect against a long-term, low-guesses-per-second dictionary attack? Or is it just that no one really bothers to do this because it's not worth it?

Question: Is there any reliable way to protect from dictionary attacks? Would adjusting the params of my rate-limit and blacklist modules improve the security of my endpoint?

Thanks in advance for any help or opinions.

Answer 1

You've almost answered your own question(s). First off, it's important to note that password complexity typically only comes into play for offline attacks. As your entropy report showed, a password that can be easily cracked offline would take much longer as an online attack. As for your bank only requiring a minimum of 5 characters, obviously the short passwords could be easily cracked in an offline attack, and as such one could argue that perhaps it would be better practice for them to have a longer minimum password length. That being said, as any bank should, they probably have very tight security on their servers and data, meaning that the chances of someone gaining access to perform an offline attack are extremely low. As long as they have good brute force prevention measures in place for the login pages (lockouts and/or 2-factor authentication for unknown devices), then this could explain why they don't have accounts regularly being compromised. (Though arguably even if they did, they would be individual accounts and likely not publicized anyway.)

Regarding your question about preventing the distributed password attempts, the simple solution is instead of locking out attempts from an IP after 5 failed attempts, just temporarily lock out the account after 5 tries regardless of IPs. This would completely thwart a distributed attack. It does have the unfortunate side effect of potentially locking out the actual user if someone tried to hack into their account, but as the lockout would be temporary the attack would have to be pretty much constant for the user to even notice in the first place. Most attackers would not gain anything from doing this, so I believe you're right that the reason it doesn't happen more often is they don't bother wasting their time on something that has an extremely low chance of success.