Jeff Atwood, founder of the popular coding site Stack Overflow, has published an extended and entertaining rant about the lamentable state of password policy among developers. The post, subtly titled "Password rules are bullshit," points out that the current format for password rules, such as including a certain mix of …
Password complexity is not the issue (to a certain point), the systems controlling them are. Rate limiting attempts, max tries per minute, hour day, pattern detection (such as logging the failures IP/MAC to multiple UIDs) and 2FA massively reduce brute force. Don't get my wrong blocking most used passwords is also required.
I do have to echo a few other posters.
"First, assume that the hackers have the encrypted password database"
That means they have completely powned the site. They likely have my address, credit card numbers, history and preference in sexual aid size, texture and color.
And they have probably left keyloggers and transaction loggers to make their future data collection painless.
And you are worried about my password? Why?
Instead, why don't you focus on securing the site. Separate out the information display from financial transactions. Isolate the potentially-compromising details from the "who cares" data.
My power company website is a prime example of stupidity. The only thing I usually want to do is check my usage data. But they require a complex password, and prevent using a password manager. They they load a whole complex active page, referencing external sites and immediately showing me a bunch of static account details. Details that I don't care about, except in the rare case that I want to modify my account, but that could be useful for causing problems with the account. Clearly real security isn't the priority, rather 'security theater' implemented with password pain.
>That means they have completely powned the site. They likely have my<
It means they have an /encrypted copy/ of your "address, credit card numbers, history and preference in sexual aid size, texture and color.". Of course, if they can guess your password, because you've used a line from your favourite song, /then/ they can decrypt your data.
Are you alleging with a straight face those records are likely to be actually encrypted while it's unfortunately still common* to see sites that can mail you your password back...?
* Yes it is - it last happened to me yesterday on an e-commerce site no less, not much I could do beyond immediately changing it to an old one I no longer use anywhere...
Um, how else can they deal with unknown hacked accounts, then? Forced password changes either close those doors (the hacked details aren't valid anymore) or draw them into the open (because the hacker is forced to changed the particulars and the real user gets locked out).
We keep hearing from security "experts" that passwords can be cracked in no time thanks to fast processors. This is, however, total bullshit for any reasonably secure system because such a system will lock an account at least temporarily should the incorrect password be used more than a certain number of times. So I care not that you have a brute forcing system that can generate five bazillion passwords a second. Even a fairly loose system will lock your account for a few minutes after half a dozen attempts. This being the case your amazing password generating breast will take years to crack even a fairly simple password.
The whole problem of measuring security through password entropy is that you are putting the emphasis on the security on the weakest link and the area you have least control. The only reason that this seems to happen is that it reduces the provider liability.
As has already been stated, far better than longer and longer passwords is to introduce 2FA and login delays on incorrect logins. But this takes effort on the providers part, so we blame the users for choosing relatively easy to remember passwords.
The argument that if users choose short passwords means that passwords files are easy to decrypt again misses the point. It is not the users fault if a password file is stolen, nor is it there fault is the password is not stored in a salted method which should be at laest as good protection against dictionary attack as other password methods
So you get to a site with a password field required. You type in an arbitrary password, containing commas, spaces, emoji, and swear words in Russian, of arbitrary length.
Browser extension catches the password, cryptographically hashes it, and creates the password that is actually sent. For this, it does have to know about password rules specific to the site ("can send a maximum of 15 characters from the following set; must contain something from this other set"). Rules for widely known sites are provided with the extension, along with tools for adding the rules for new sites.
The site (which, if it's like most sites, would promptly lose your password to hackers) only sees and gives hackers the hashed result.
Drawback: if the extension exists only for browser X, you're screwed on browser Y. There are probably other drawbacks.
@Charles9 : If hackers can attack the browser, they can log keystrokes. The solution I propose is not a panacea; the only things it really addresses are removing site-specific limits on passwords and ensuring that sites never see an unhashed password. As a result, they cannot lose an unhashed password, something they currently do routinely. If the hash is salted -- you'd hope this would be a no-brainer -- then anything you lose can only be used on that one site, so it provides some security against password re-use.
This scheme does _not_ protect against other hazards; hackers can, for example, intercept the hashed password and send it to log into that particular site (i.e., you still need HTTPS) and can keylog, shoulder-surf, etc. I don't see any panaceas. You need complex passwords, salted and hashed so they can't be easily deciphered, limits on how many password attempts are allowed in a particular time interval, 2FA, and HTTPS... even though no one or two of these alone are sufficient.
"This scheme does _not_ protect against other hazards; hackers can, for example, intercept the hashed password and send it to log into that particular site (i.e., you still need HTTPS) and can keylog, shoulder-surf, etc. I don't see any panaceas. You need complex passwords, salted and hashed so they can't be easily deciphered, limits on how many password attempts are allowed in a particular time interval, 2FA, and HTTPS... even though no one or two of these alone are sufficient."
Except if you make things TOO complicated, you force people to create shortcuts that malcontents can exploit. You need a solution that's strong enough to block anything short of an insider or state yet simple enough that even the dullest drone can and will do it nigh-automatically.
in an environment where not everything is under a nice web front end using common platforms...
mainframes choke on currency symbols in passwords
some mid range systems use completely different character sets
multi language character sets don't translate nicely - never mind the platform
lazy UI code doesn't help matters either where chars that may be considered delimiters can end your strong password after the first few characters while letting you type in the rest
strong passwords are not always easy for poor humans to remember either, particularly if you are changing them regularly.
just delivering single sign on/single identity in a single organisation is a tough ask, never mind a standard that will work across the board.
Surely someone somewhere has spent the time to create standards, perhaps for their own purposes and not published. Not just "whats a secure password" but the whole end to end login process taking into account everything in this discussion and more - i.e. that a secure password is useless if the site in question is sloppy with their logon procedures, that people can't memorize dozens of 16 random character passwords, that we don't always have our 2fa token etc.
On gripe not yet mentioned here I think is what about when you travel to a place with a different keyboard layout so the local currency symbol in your password isn't represented on the keyboard of hotel guests 'net terminal. (And while we're at it, the situation of access from a possibly compromised terminal like that should be catered for). And when I travel to Moscow the keyboard is in Cyrillic... HELP!
Before you rush in and change everything to be made up of U+1F4A9 'PILE OF POO', here's a cautionary tale:
I worked on a 'secure email' client for a large US company and discovered, following some work on the UI, that the code which takes 'what you type' and turns it into 'what gets hashed' when setting a password had managed to pass on only the first byte of the UTF-8 encoding of each character. So, for instance, an 8-character word in Arabic might have been squashed to 0xD8 0xD8 0xD8 0xD8 0xD8 0xD8 0xD8 0xD8, and would match countless other words.
We were only saved from disaster when it emerged that there was a separate copy of the code used when verifying your password, and this was broken in a different way. The effect was that any password containing a non-ASCII character could never be verified after you'd set it.
So: Unicode - great. Programmers' general ability to write correct internationalized code - needs improvement.
U+1F4A9 'PILE OF POO'
(Groan) You _didn't_ make that up. Unicode has well and truly jumped the shark.
I'd describe that situation as a "stupid programmer mistake" rather than a Unicode mistake. (In fairness, I've made my share of SPMs... if one hasn't, one probably hasn't written much code to begin with.)
I use a password manager, so length and complexity are no problem. However, once I did get the following message about my new password - "Password strength: Outstanding!" and then below it a password failure message saying: "Password must contain one number or symbol."
A perfect example of what he's on about.
much better solution all around, but getting the systems we use to change to use a common 2FA device (eg TOTP with Authy app) is an uphill battle because everyone seems to think their system is better (until it's cracked).
my bank for instance requires a 2FA app which can only be activated on a single phone (sucks to be me as I have a personal phone I can't even carry on some work locations, and a work phone which is locked down to 'approved' apps, and while they approve Authy they've not yet (after 9 months) approved the bank app because it uses a non-appstore updating process
Ironically my work 2FA solution is probably the easiest ... a simple 6 digit PIN that I only have to change if I think it's compromised, a 2FA app that I can install on both my phones and an intelligent (Active Directory based) threat level determination that does profiling and if I go off-script requires some additional verification before allowing corp access
Somewhere I worked implemented a 6-month timeout on passwords AND bullshit rules AND non-reuse.
So after 6 months of using your nice strong password you were forced to give it up and try and remember another one.
Of course being a programmer, it took me a few minutes to discover I could change it 5 times and back to the original.
So every 6 months I have to spend a half hour or so resetting my password back to where it was in the first place. I book the time to "computer outages". Ho hum.
ONLY five. Many have enough memory to go back at least ten, by which time you've probably lost track of your original password. And some go even further by not allowing any PARTS of an original password (blocking Password0 -> Password1 as "Password" is in both).
Like I said, there's at least a valid reason to have a change policy: to close or expose undetected breaches.
Ha ha - ten passwords where you can't reuse parts of the password?
Let me see - i recon I could go round the loop and use up 9 passwords in such a way that a tenth password would be impossible.
Then make the IT guys reset the whole thing - social engineering, job done.
In the case above an undetected access would go undetected for 6 whole months - so why not age the password once a week? Or once a day? Surely, 6 months is an intolerable amount of time to let your attacker in unfettered?
One other thing that I haven't seen mentioned above - apologies if I missed it - every login system should tell you when you last logged in as a matter of course. That helps the end user spot intrusions and then they can help the process by changing their password. Most do not do this, notable exceptions being HMRC (wow - they do one thing right!) although they too use the easily hackable SMS method of 2FA.
I see he suggests blocking stuff even in the top 1mill most common passwords.
Assuming my server's current SSH password fits that, you'll have a fairly poor chance. Even if you "get lucky" and would've hit on it in your first 1,000 tries... Fail2ban kicks you out for at least 5 hours after 3 failed tries on any service (not sure if it combines all services ie fail HTTPS login, fail SMTP, fail IMAP = ban). Denyhosts(more focused on SSH IIRC) kicks you out by blacklisting your IP, and said IP is blacklisted until I remove it if I remove it. When I used to care if I was seeing lots of IP's from a similar range or host (including things like AWS) or Comcast I'd contact the ISP but also block them till I heard back except NZ ISP's (didn't want to risk blocking a significant chunk of potential customers!). I must say Comcast were actually the best at dealing with complaints in my experience, while NZ ISPs were collectively the worst, usually didn't even respond (Actrix were pretty good though).
I digress. I use tools to rate limit and ban IP's either for several hours or indefinitely for failed login attempts. The vast majority of script kiddies/bots etc are going to go elsewhere. If I were a juicier target then perhaps a more determined attacker would be willing to try again after 5 hours, but it's unlikely what I have running today warrants that level of attention/effort.
Oh, my bank doesn't do 2fa, but it does have a pretty decent login system and only 3 failures before you have to visit a branch to get your access restored.
TL;DR Good rate limiting can means you can only make a couple of attempts every few hours, or even have to get your account manually reset.
But the problem becomes when they STEAL an account, get in first try, and use that to troll your system, perhaps smurf your password database, crack it at their leisure, and find ways to get into admin accounts in so doing?
Seriously, are you for real? What web sites allow their users to get the password database? What websites let normal users get into admin accounts? If anyone finds such a site, who (other than spammers and low-skill hackers) is going to want to stay there since it'll be spammed beyond belief and have no worthwhile content?
Come on Ch, er, AC.. Instead of your rather formulaic (and often extremely unrealistic) negative posts ("oh but what happens WHEN they put a GUN to your HEAD and DEMAND you GIVE THEM you 2FA TOKEN that you LOST because PEOPLE can't REMEMBER things?") how's about coming up with some solutions eh? If you can think of a problem (and I mean an actualy realistic one likely to affect real people, not your unrealistic 'any user can "smurf" your password database' crud) then mention it, sure, but also suggest possible solutions. I've seen you post some great stuff and I do look forward to seeing more of that from you, but sometimes this negative formula you apply to so many posts (especially security ones) gets a bit old.
(Oh, and if the AC I'm replying to isn't the person I'm pretty sure they are, then that person has more to worry about than someone using his unused throwaway accounts to mimic him, he also has to worry about other's using his posting style, which can be a bigger issue than using real accounts!)
"Seriously, are you for real? What web sites allow their users to get the password database? What websites let normal users get into admin accounts? If anyone finds such a site, who (other than spammers and low-skill hackers) is going to want to stay there since it'll be spammed beyond belief and have no worthwhile content?"
So tell me, Einstein, how are they getting out in the first place given we're now to the point of a megahack about once a month?
And losing things? I regularly encounter people with memories THAT DAMN bad but they still have jobs. Some have since given up carrying cell phones because they keep losing them (they even keep their credit cards at home). Plenty other keep calling me for their passwords which they can't remember yesterday. ONE password they need everyday, and they can't remember. Try that with ten and they'll be contemplating suicide. And no, I can't abandon them; some are FAMILY. So I'm speaking from FIRSTHAND experience on just how BAD people can be re: security.
So tell me, Einstein, how are they getting out in the first place given we're now to the point of a megahack about once a month?
Really? Well come on then, where can I find proof that even one of my sites got a "megahack about once a month"? Well? All websites are getting a "megahack about once a month"?
No? So only just a few sites get hacked? And then usually from significantly bad errors in the configuration or unpatched bugs (which usually is administrator error as well). Given the millions of servers out there, maybe those that get hacked are only a tiny %age, and those that leak their password files are only a really tiny %age of the tiny %age that get hacked?
How about some citations for your claims for a change? No? Course not, no surprises there.
Some have since given up carrying cell phones because they keep losing them (they even keep their credit cards at home).
So JUST because YOUR family ARE a bit LACKING in MENTAL CAPACITY, the REST of US should LOWER our STANDARDS? Several BILLION people AROUND the WORLD don't HAVE the PROBLEMS of YOUR family MEMBERS. Why SHOULD the REST of US limit OURSELVES just BECAUSE they're NOT CAPABLE of FUNCTIONING NORMALLY?
If you cannot figure out a way to give them a single password that they can remember, perhaps it is you who is the problem? Maybe write it down for them and stick it to the side of their screen? If they're not in a place where others can see it, there's no issue and it'd certainly be safer than the daily passing of the password over the phone. Obviously you don't care for their password security or are simply incapable of devising a better system for them, otherwise you wouldn't be needing to read several other people's passwords to them over the phone each day. For that matter, what do you use to remember them? Obviously you're either further compromising their security by using the same password for all of these people or you're using some tool to keep track of them all? Huh? Well, come on Einstein, do tell.
Biting the hand that feeds IT © 1998–2019