I have a PHP site that has user accounts. Note that this is not a banking site or anything particularly sensitive but I am reviewing it since I have been asked to do some work on it.
The hashing uses strength 10 bcrypt, so no MD5 or SHA going on thankfully — so I think the site would fare quite well in an offline attack, i.e. if the database was stolen.
For online attacks the site blocks them for 15 minutes after 5 failed logins. I’m not a massive fan of locking accounts, even if they unlock automatically as I think it riles the user.
Let’s assume for a minute the firewall won’t block them for brute-forcing do you think it is secure enough to disable the account locking but throttle the logins per account to one every two seconds. The password policy is a minimum of 8 characters with at least 1 number, 1 uppercase character and 1 special character.
Let’s go with 10 special characters and we could say there are 46^8 possible password combinations = 20,047,612,231,936 or ~20 trillion possibilities.
If they tried the maximum number of password combinations (one every 2 seconds) they could try 15,778,800 per year. So, it would take them approximately 1,270,540 years to try every combination.
I appreciate they would try patterns first but given this is not a banking site or anything sensitive do you think replacing the 15 minute lock out after 5 failed attempts with a 2 second attempt limit is good enough?
Personally I’m a fan of device cookies. Basically if you’ve logged in succesfully before you’ll get a cookie marking the device you used to log in as trusted.
Then when a bot tries to brute-force the account, the account will be locked, but only for non-trusted users.
So legitimate users will still be able to log in to their account, provided they’re using a device they’ve used before to successfully log in.
Thanks for the suggestion. If I understand that correctly though that is an improved version of the situation I am avoiding above. I am looking to remove account locking altogether while keeping security acceptably high.
You have so far posted twice on this and offered absolutely nothing, other than a bit of passive-aggresion. If you don’t know anything about the subject then don’t post. This is a discussion forum for developers; if you can’t form an opinion on security based on the information I provided I think you’re in the wrong place.
I’ve offered an opinion, that the best security would be best. You’ve come back to every post in this thread and said ‘no i dont want that’. So clearly you dont actually want peoples opinions, you’ve already formed one.
This is a discussion forum. If you don’t want discussion, then you are in the wrong place.
And since I apparently don’t know anything about security or am not a developer (btw i’m a developer in the banking industry, so you take as much sarcasm as you want with that statement and take your assumptions and shove them),
I wont bother pointing out that a requirement of an uppercase, digit, and special character chops your permutations of allowable passwords down from 46^8 (which is actually 72^8, because you’ve got two sets of alphabets, 10 digits, and 10 special characters) by removing all passwords that contain:
No uppercase (46^8)
No digit (62^8)
No special character (62^8)
and then readd the double-removed ones once and then subtract the ones in the center of the diagram again
and end up with approximately 1/20th of your estimated number. Though if you took out lowercase characters as your original math did, you’d come out with a value much smaller if you actually did the math. Yaknow. Like a developer does.
You asked if it’s good enough. You then proceeded to ignore the statements about how we’d still lock the accounts. The consensus, therefore, seems thus far to be ‘no’, but the only true answer anyone can give to a nebulous question such as “is it good enough” is… “Is it good enough for you?”
Thank you for your recent post, which is very useful.
I did not say that you knew nothing but that I wrongly inferred that from your responses. I apologise if this was framed in an unclear way or you perceived it as rude.
It is a discussion forum, as you point out, and I was hoping for either agreement or constructive criticism (as you gave in your recent post) of my alternative. I feel I gave two specific scenarios and was clear about my question: was the decrease in security worth it for the better user experience? If that wasn’t clear, fair enough.
I don’t think you can say there was a consensus here as only you explicitly said not to lock and a consensus would require more than one person. I have read about this on Stack Overflow et al and I couldn’t find a consensus — quote the opposite — hence this question.
Anyway, thanks again for your post correcting me on my calculations.
Well you dismissed rpkamp’s suggestion on the grounds that it advocated locking the accounts (in a better way). So… two out of two. I agree it’s not a statistically strong sample, but so far it’s 100%. shrug
You are, of course, not asking an objective question, but a subjective one.
Let me ask this; have you gotten data to support removing a lockout? How often do users trigger your lockout? How often do they even get their password wrong? I’d advise logging failed attempts (not the password values entered, mind you, but simply a timestamp of “failed account login for User X”. Then you can analyze the impact on your user base.
If your users aren’t failing their passwords on a regular basis, then the question is perhaps even moot, as there is no ‘user experience’ for something that users (other than hackers) don’t experience.
I didn’t actually dismiss it. I found the idea interesting and will consider it if I kept account locking. I have considered adding a CAPTCHA after x failed logins but again I am concerned about the user experience. I like adding a short delay between each login because the user won’t know they’re being tested. I’m just making the point that I am considering other things but specifically was asking about this alternative in this question.
So, I wanted someone to validate or falsify the stats on method 1 vs method 2. I’m kicking myself with those calculations that you corrected me on but if people are getting locked out do you not agree it’s worth considering?
We have some data on lockouts but not enough to make an informed choice (better than 2 though, ha ha). It’s more anecdotal evidence from feedback the client has had and the fact that under an account locking system it is easy for someone else to lock someone out of their account.
You do make a very good point though and that is something we should consider.
Let me ask you a direct question, if you’ll indulge me. In your experience in banking, if someone could try a password every two seconds (via an online attack) and there was no account locking, what would you consider a secure password policy?
A secure password policy, or a secure login procedure? Because those are two entirely different things.
You’ve got a (fairly) secure password policy as it is. You can’t account for human stupidity, regardless of the password policy you set. Someone will inevitably make their password with your requirements P@ssw0rd and think they’re being clever.
The simple answer is that most attacks will not come in the vector of brute force, but of logical attacks. Social engineering (Your password is your birthdate, with the name of your dog attached.) attacks, and the like. A 2-second policy is less of a deterrent then - instead of trillions of passwords they have to try, they’ve only got a few thousand.
Let’s say it’s going to take a hacker 500 attempts to guess a user’s password. (Probably not a realistic number, but it makes the maths less brain-hurt)
A 2-second lockout between attempts means it’s going to take 1000 seconds (16 2/3 minutes) for the hacker to get in. You have no idea it’s happened, because he’s just doing what a ‘normal’ user would do, and try every 2 seconds.
A lockout after 5 failed attempts of 15 minutes means it’s going to take that same hacker 15x60x100 = 90,000 seconds (a day and an hour) to get in, and he’ll trigger 99 lockouts before he does.
If your security isn’t alerted after 99 lockouts on a single account…you’ve got another hole in your security plan.
Much has to do with compromise. A balance between easy for real users and hard for any other.
IMHO, if you wanted to do away with locking out accounts you could have more “requireds”. Many sites use some type of CAPTCHA as an additional input when the user name and password are not enough. Many sites also use things like IP, user agent, etc. (“fingerprints”) as evidence that a user is who they purport to be. Others have “questions and answers” such as mother’s maiden name etc.
Theoretically a site could have a login that has so many required inputs it would be near impossible for any other than the real user to have a successful login. There could be no lock outs, but the possibility of a real user making a mistake or forgetting one of the values increase. I imagine it would be annoying to have a lot of repeated “unsuccessful login” messages. Some would be annoyed at having to enter a lot of inputs every login. True, getting locked out for a period of time is also annoying.
My point is what level of security is needed should be considered. eg. a bank account, much so, a blog comment not so much. And then it’s a matter of deciding what hurdles you want to put in front of real users in the effort to not allow false users. There is no easy one-size-fits-all approach that is both easy enough and difficult enough.
A blog comment, perhaps not. A blog profile password? If I get your blog password and you’ve linked to your facebook in any of your posts, i’ve now got a pretty good attack vector on your facebook account…thanks, blog-a-million!
(Which is why every person who’s ever looked into password security ever tells you never to reuse a password…)
Just because your site isn’t handling banking details, doesn’t mean you should be lax.
There are some suggestion on SO that you double the lockout period after each failed attempt. So you start at 1s, then 2, 4, 8, 16 ad infinitum.
I’ve always thought that regardless of the type of site the database should use decent salted hashed passwords (e.g. bcrypt) and encourage a decent password. As has been mentioned though a password policy isn’t the be all and end all.
password_hash() uses a strong hash, generates a strong salt, and applies proper rounds automatically. password_hash() is a simple crypt() wrapper and compatible with existing password hashes. Use of password_hash() is encouraged.
Back in the day — I think it was PHP 5.4 and earlier — you had to create the salt yourself, put $2y$ at the beginning, etc.
password_hash() should definitely be used for password hashing if you’re using PHP, which is what I assume you meant. Encryption, that’s an entirely different thing…
Do you know of a reliable online tool that does these calculations for you? I looked last night but none seem to allow you to apply a password policy and have it remove ones that aren’t allowed under the policy as you have done. The one I played around with seemed to calculate the same way I did — though they seemed to allow a higher number of special characters (I know there are lots more but people don’t necessarily use them).
I know, as you mentioned, brute forcing isn’t the likely first choice for hackers, but I’m interested all the same.