I agree with almost everything but the he loses me towards the end:
> I had a bit of a sad when I realized that we were perfectly fine with users selecting a 10 character password that was literally "aaaaaaaaaa". In my opinion, the simplest way to do this is to ensure that there are at least (x) unique characters out of (y) total characters.
Isn't that exactly what you're complaining about with your arbitrary password restrictions to begin with?
I mean, I can imagine that a clueless user might have the illusion of safety if they're using something like "1q2w3e4r5t" but if I use "aaaaaaaaa" as a password on a website I know full well what I'm doing. So why even bother?
I think there are two possible ways to look at this problem from a service provider perspective:
- if the user getting their password stolen is a bad thing for you (i.e., you're a bank or something like that, and getting an account compromised will put you in trouble), then IMO the only satisfactory solution is to impose a password to the user. In effect these ridiculous password requirements are exactly that, except less convenient and secure. Cut to the chase and say "your bank password is Axei5aoc0i, write it down somewhere safe".
- if the user getting their password stolen is not a problem for you because it's not your responsibility to handle these issues (like a hacker news account for instance) then just let the user pick whatever they want and deal with the consequences. If they care enough about it they'll care enough to pick a decent password. At most if you really want to be friendly give an indication that a password might be weak, but please don't disallow it.
Yes and yes! Many throwaway accounts I have use some variation of the same password, because I don't care if someone hacks my HN or reddit or youtube account. I don't use my real name on any of them. If I lose control of it, I'll just make a new one. (Karma doesn't pay the bills, and I don't make money from my very excellent youtube comments; someone else does.)
This is why all these accounts get an email account that doesn't include my real name, too. There are so many sites that have these signup dialogs that require an email address -- why? Oh yeah, that's right, user data is the oil that will fuel the future economy.
I do the same thing. I have my crap/spam/don't care account (at yahoo.com). All the accounts that use that email address (which has zero ties to me - though you have to be careful over time not to leak information) also all use the same password. Couldn't care less if anyone ever ties two random and anonymous accounts on the Internet together. My important accounts have huge passwords from a password manager.
There isn't a day that goes by that I don't get an email intended for someone else, often including personal information, due to a mistyped email address. Whoever decided that email verification was a poor user experience needs to be hit in the head with a shovel after he digs the appropriate sized hole.
If you know Catherin (PA) let her know her round trip to vegas is confirmed
Carolyn's (NYC) open table reservation was canceled by the restaurant.
Different Carolyn (CA) needs to correct email address with the walnut creak school district.
Possible the same Catherine (PA), your financial advisor needs a distribution form filled out.
Clint (OH), your repair at Kay jewelers in Akron is done.
Ann (FL), Thank you for scheduling an online appointment with Conley Subaru
sigh, you get the idea
Edit:
Oh, and I'm going to start canceling Open Table reservations that show up in my inbox.
What's even more annoying is that some sites ask for verification, but then proceed to email you stuff even if you don't click verify. Someone in Australia created an Apple ID using my email. I ignored the verification, but then I got a bunch of purchase receipts from them later.
What I really wish for is a link in emails that say "I am not the intended recipient of this letter." Normal mail works like that. You can ask the United States Postal Service to only deliver mail that has your name on it, and if you send back mail with someone else's name they will add that person's name to a database that says the mail is undeliverable.
I don't want to mark these organizations as spam, but that's basically what they are to me. I've started using the password reset to log in and change the email preferences so I don't get these emails anymore.
I had the same problem with someone signing up for an Apple ID with my email address.
I even tried calling Apple to get them to cancel the account, but they wouldn't let me because I couldn't answer any of the security questions on the account!
The guy on the phone acknowledged that of course I can't answer them, because I didn't create them, bit their policy forbids them from doing anything without the security questions...
Man, now I'm wondering if this is some sort of violation of the CAN-SPAM act. My blood pressure goes up a little every time I get one of these emails and it doesn't have a way to unsubscribe if you aren't the legitimate recipient. Considering the companies that spam me the most with this irrelevant crap are Apple and Wal-Mart, I would feel 0% bad if they lost money over this practice.
Quick Edit: I just read the Wikipedia page, and individuals cannot bring suit against spammers (using CAN-SPAM in any case). Which is a shame really, because spam is really really annoying.
Instagram does this. They let anybody sign up for an account using any email address, and the account is immediately live. While they send a verification email, you don't have to click on it to still use the account. And most likely if you hadn't signed up for the service you'd think it's a phishing attempt and ignore it anyways.
I found this out the hard way when someone else had created an account under my email address and because some of my friends had uploaded their address book, my friends were following this stranger, perhaps thinking it was me. When I eventually did choose to sign up, I had to jump through a bunch of hoops just to be able to use my own email address.
I suppose there may be some sort of anti-hacking law that could be twisted to fit this case, and if the cops came to my door over it I'd definitely hire a lawyer before I said anything. I somehow doubt if I'd be charged with a felony for accessing an account that is registered under my name and email address and turning off email notifications, especially since I've tried everything else I could think of to stem the tide, including emailing support, etc.
Plus, this individual who keeps signing me up lives in Australia. I cannot imagine our system is so dysfunctional that both the United States and Australia would agree that a) this is a criminal offense, and that b) it would be worth going through the effort of extraditing me to face justice.
I mean, I haven't even received another password reset request from those websites I logged in to fix that issue, so I half imagine that person is using my email address as a plausible address for email they don't care about.
I understand what you mean, but I don't think I'm going to have to spend the rest of my life looking over my shoulder. The few personal emails I've gotten with financial details (gym membership bills, etc) I've responded letting them know about the mix-up and they've been more than happy to fix the issue. Feel free to say I told you so when I end up in a jail full of kangaroos though.
As someone with an unusual name (used for my public-facing email address) and who uses a fairly unusual email for personal stuff... that's pretty different from my experiences. I've never ended up with someone else's mail at all.
That's a solid argument for business cards with vCard QR codes as I see it. Or a pack of stickers with QR codes that you could slap on whatever documents you needed.
It's too bad QR code adoption is so horrible. I'm just as guilty of it as anyone else, I assume that any QR code is probably just some marketing thing.
But vCards seem like one of the very legit use-cases. Now that I am imagining using stickers and never filling out my contact info on a form again, I realize that's definitely a world I want to live in.
> As someone with an unusual name...and who uses a fairly unusual email for personal stuff... that's pretty different from my experiences. I've never ended up with someone else's mail at all.
I think it's more likely if you use an initial in your email address. I have a fairly unusual last name, but I used my first initial to create my gmail address, so I regularly get stuff meant for a couple of other people.
Business cards or sheets of stickers are not going to solve this problem. The former is not universal, and you're not going to get enough adoption for the latter (do you really want to carry them around in case you need to put your email on a form?).
The only solution that might actually work is to put some kind of financial penalty on certain classes of email sender to incentivize reasonable levels of validation.
I could overload my pockets carrying around all kinds of special purpose labels and stickers, and track my stock of them so I don't run out....or I could carry a pen.
> Do you people really not keep a book of stamps in your car?
> Whoever decided that email verification was a poor user experience needs to be hit in the head with a shovel after he digs the appropriate sized hole.
That's why you get send the verification email first, when creating the application user, and don't do anything until the email is verified.
The flow should be:
User: Please give me an account; my email address is jim@example.invalid
Server: I have sent an email to jim@example.invalid
That is what I was trying to say. Apparently there is some number of designers that believe that that whole email verification process is too much friction for registering a user, so they simply opt not to do it at all.
I have (first initial)(mid initial)(last name) at gmail. Same as my HN id. And a very common last name! 16 months into my first job out of University I got a call from a headhunter intended for the other Chris Miller sitting 2 cubicles away from me. At my second and fourth jobs there were also other Chris Millers. And from my list of examples, most all have the same last name.
4 days into university, the first time I logged in to the email account, I had several messages waiting for me, all intended for the same person, the best of which was:
"Hi X. The £80 million for the new biomedical building is approved, please make the transfer ASAP."
It turned out I had the same unusual name as the most senior financial officer.
My last name is pretty uncommon, but there are at least a thousand of us or so in the US.
I probably get a dozen emails a month to people who are not me (not counting all the ones that end up in the spam folder after I'm on a damn list).
Susan. Stephen. Another Sam. So many damn S. Lastnames around.
On occasion I've tracked the people down. I've forwarded their emails if they seem important. And whenever I ask that they be more careful and memorize their own email address, they get defensive and tell me someone else made a mistake.
Buddy, this email was was an automated response from a computer
after you signed up for something. No, it did not just randomly decide to send to my @gmail instead of your actual @yahoo address. YOU just don't know your own email.
Enough people clearly do -- they think that all email addresses end in @gmail.com, even if they check their email at yahoo.com. Because we have an email monoculture.
I have an uncommon name spelling and I still get misdirected emails.
Not to the extent of the above, but for instance, last year I received someone's job offer in Colorado. I did respond to the sender to let them know of the mistake of course.
My most entertaining email yet was a group thread that kept track of a young missionary's progress as he traveled through South America. He's home now, so I don't get weekly updates anymore :( I almost miss it.
I've always assumed it was for password recovery. People forget those all the time, email is a quick way to verify identity. Since everyone can have an email address for free. If you have a better way, do tell. Also, when your email is your username, that's one less thing to remember.
Then you're effectively banning someone's existing account, which they could have been using for years at that point. There's a lot of potential content there. Not a great feeling for anyone.
Seems like the simplest solution is to have some basic password requirements.
I think the OP and other posts here have demonstrated that password requirements won't solve anything given a sufficiently incompetent or not caring user. If the platform provider cares more about the security of the account than the account holder there isn't much you can do.
well I really need to remember part two, for too long I just used an old email I no longer had as my primary account but it does incorporate my last name. time to get smarter. thank you for wake up
For what it's worth, the current NIST draft has the exact same recommendations:
> Verifiers SHOULD NOT impose other composition rules (e.g., mixtures of different character types) on memorized secrets.
> When processing requests to establish and change memorized secrets, verifiers SHALL compare the prospective secrets against a list that contains values known to be commonly-used, expected, or compromised. For example, the list MAY include (but is not limited to):
> * Passwords obtained from previous breach corpuses.
> * Dictionary words.
> * Repetitive or sequential characters (e.g. ‘aaaaaa’, ‘1234abcd’).
> * Context specific words, such as the name of the service, the username, and derivatives thereof.
Totally agree. If you annoy the user too much, they will not try to circumvent your rules, they will leave and find something else to do with their time.
Also, the big question that's missing from the article is: who's the enemy? If the enemy are Russian genius hackers, then certainly very long passwords and maybe other measures are in order.
But the enemy is not always remote. I just bought a new iPad and had to reset my password and so-called "security questions".
In my experience, there are only two kinds of security questions: ones I don't know the answer to myself, and ones everyone around me knows the answer to (what was your first job, what was your surname when you were a child, etc.)
The problem is, in the case of the iPad, your enemy is not some James Bond villain in a cave in Ukraine, it's your 13 year old child who wants to use your account to buy apps, or your spouse during a nasty separation. And they both know, or can guess, answers to "security questions".
What I do personally is type random things as the answers, and write them down somewhere. But that doesn't improve security, it weakens it.
It's also insecure to have password rules because people end up writing, printing, saving passwords in Google Docs, because they can't remember them anymore with those stupid rules.
Totally agree about the "security questions". They're just insecurity questions. Everyone knows what street I used to live on and what my previous phone numbers were.
This is a good idea. Unfortunately if you have ever in the past (foolishly) answered these security questions honestly, you can't just now start answering them with your password, unless you keep track of which sites have your honest answers and which sites you just gave your password again.
Did I answer "Ste-Citée" or "Ste-Citee" or "Sainte Citée" or "Sainte-Citee" or ... oh, too late, only had two chances to answer. My account is now locked.
Ran into one where it demanded I choose from a drop-down list, e.g. "What was your first pet" had "dog", "cat", "hamster", "gerbil", etc. I recall the list having a scrollbar, but there was not even enough choices for eight bits worth of entropy.
Oh, and they referred to these security questions as "2FA."
I love the ones that ask about one's favourite sports team (not everyone likes sports), or first girl (or boy) friend (not everyone has dated) or first car (not everyone has ever owned a car).
>What I do personally is type random things as the answers, and write them down somewhere. But that doesn't improve security, it weakens it. //
It weakens it to the extent of your physical security. But in practice how many crackers are breaking in to your flat [aka condo] to find your written down security responses, unless you're famous - or a target some other way (politician?) - in which case you should have sufficient physical security to protect the written answers.
Having security questions allows users to use hard passwords without the problem of losing an account. It increases the risk of personal attacks, for sure, but I'd warrant the chance of personal attack [ie by someone who knows you (or has gone through your bins)] is minimal for most people vs. the chance of an automated online attack.
I think it's right to minimise the online attack surface at the risk of the offline one for most users.
For security answers I let my password manager generate a Multi Word Phrase you can easily spell out in a phone conversation. Store those in my password manager under my account. Someone told me he had to go through a converstation with Apple Support spelling out 3 random 20+ characater passwords and it was a nightmare. I immediatly switched tactic.
Regretfully Apple has an annoying bug that the dialogboxes accepts 5-word phrases, but only remember the first 32characters, 3 words or something alike. Very stressfull when you’re trying to recover a password.
I have never come across an authentication mechanism that actually required your security questions. There's always another route to restoring your password, which means that they do not serve a security function, but rather serve a convenience function, at the expense of security.
If you are willing to be brave about this then the best way of answering security questions is by typing a random string and NOT writing it down. You will never need that value again.
I once did that for a site which I didn't want anyone to recover my password to and thus break the security. I -DID- write down the actual password.
Today, years later, I still can't login to the damn payroll site because there isn't a procedure for just completely resetting the password state of the account and it wouldn't let you log in without those extra things.
Since that point I have recorded every annoying split-password (that's what the 'security questions' actually are, a forced split in the single real password)...
> if I use "aaaaaaaaa" as a password on a website I know full well what I'm doing
You do. A lot of users don't consider automation when it comes to people hacking their account. I've heard "Nobody will ever guess it though" a few times during my career.
I am being serious when I ask this question: does anybody brute force passwords? I posit that using a unique password for every single website is sufficient, because no one brute forces passwords.
What attack vector is a password with high entropy protecting against? The only one I can think of is an unreported database leak. The attacker may be able to more easily reverse the password hash and use your account on that particular service, at least until the leak becomes discovered and the service does a full password reset.
While it would be ideal to defend against that attack, I think it's far more important to stress that users have a different password for every website. The real attack vector that we see every day is a DB leak from a poorly secured website, passwords cracked, and then reused on important services. That's where the problem lies, not in the user's password entropy.
Jeff isn't wrong here, he's just attacking a relatively unimportant problem.
Depends. If the leak or breach reveals actual password, then yes, you're screwed. If it reveals SHA-256 hashes, then you're screwed unless you chose a good high-entropy password (e.g. lBBo1f93XbbKs2hKa8T5pR). If it reveals PBKDF2-hashed, bcrypt- or scrypt-hashed passwords, then you're almost certainly safe, unless you chose a really poor password (e.g., the following is a Base64-encoded PBKDF2 hash, with 100,000 iterations of SHA-256 and a seed of 'QDTGEqi8to9PrkpBgCbnN0': 8h1HO6omVWhusXcQRGS0CcTzSC5AkAIvodC+hT/AoRk=; I contend that you will not be able to guess the password I used for it), since trying passwords with a good key-derivation function is so slow.
I know of almost nowhere that encrypts content with the user password. It means if the user resets the password because they forgot it, they lose content.
I was wondering this as I read it as well. Yes, we know it would be fairly easy to compromise an individual account by guessing common passwords. But that assumes you have one particular account in mind. If you're just looking for bank accounts to access, you first need a list of usernames to try (ideally usernames of non-tech-savvy people) and then you need to run your entire password guessing routine for each one.
I'm no security expert, but I start to wonder if the "practical" entropy of a given password is actually much higher than the theoretical entropy numbers people derive.
Serious question: when is the last time anyone has had an account compromised because of a weak password?
My wife had an account hacked years ago. I don't know for sure that it was brute forced (could have been phished or exfiltrated by a keylogger or session jacked with an XSS vulnerability or...), but I also don't know that it wasn't brute forced. She used very short, simple passwords at the time.
Come to think of it, I also had an old account with a very weak password that I hadn't used in years mysteriously hacked one day. The language settings were changed to Russian when I went to reset my password. The fact that no other account of mine appeared to be compromised and I hadn't used the site in years certainly suggests brute forcing.
>Serious question: when is the last time anyone has had an account compromised because of a weak password?
What is your definition of "weak"? I sometimes help my landlord fix their computer when they accumulate too much malware. One time I brought their tower home to do this and didn't get their Windows account password. Instead of calling them I decided to try a few things first, including their kids' names. Lo and behold, the second attempt was correct.
Brute forcing a weak password probably isn't what you have to worry about when it comes to targeted attacks against weak passwords, but social engineering is.
And then what? Like sure, you'll be compromised on that one service and that's bad, but it's not anywhere near as bad as re-using passwords across services. My argument is we should be focusing on stopping password re-use far, far more than we should be nit-picking about password entropy.
Hah, funny you ask. I was able to siphon off internet quota in my college using a combo of brute-forcing and previously known passwords. Worked quite good until my conscience got the better of me.
> I am being serious when I ask this question: does anybody brute force passwords? I posit that using a unique password for every single website is sufficient, because no one brute forces passwords.
Weren't the celebrity iCloud account compromises due to Apple neglecting to rate-limit a certain authentication API endpoint, allowing the hacker to brute force passwords online?
Also, doesn't some of the current crop of IoT malware brute force device passwords as well (after trying the defaults)?
If you have a server running SSH, you can try the "lastb" command, which shows failed logins. Or, look in the logfile, often /var/log/secure or similar.
Do you run any ssh or email servers? If so, your logs will tell you already. I've got bots brute forcing passwords on my blogs, that nobody even read, but did have account functionality, with email sending. People made the point of adapting their bots for different captcha schemes just so they could send some email.
> if the user getting their password stolen is not a problem for you because it's not your responsibility to handle these issues (like a hacker news account for instance) then just let the user pick whatever they want and deal with the consequences. If they care enough about it they'll care enough to pick a decent password.
Surely that's a cop-out? If the user getting their data stolen is not a big deal for you, why bother securing any system at all?
The reason service providers set password rules is because there are many, many people who do not understand what a good password is, or the risks associated with losing them. There are people out there using the same password for everything, unaware that the compromise of one service can spell doom for their financial life.
Developers really need to start taking responsibility for their code. Setting password rules, while arbitrary, are about protecting users. This may upset those who are tech-savvy and know what they are doing, but that really weighs nothing compared to the benefits it brings to those who are not.
I guess Atwood's point is that it's impossible for developers to stop users from creating dumb passwords just using regexes. That much is true. Even if you require an uppercase letter, lowercase letter, special character, and number, you're still going to have a lot of passwords like "Password_1" coming in. And then, if you require people to change their password every so often, it will become "Password_2," "Password_3," etc. There's no easy way around this.
It is weird that he goes on to suggest a complex system of rules literally right after saying rules are bad, and that's the point where he lost me too.
If users don't understand what a good password is, they are going to eventually get an account compromised somewhere, if not on your site, then on another. In cases where there's no liability back to you, then there's no sense in babying them. If you do have liability, then two-factor authentication is probably a better way to go.
I personally would hate it if a company forced me to use their generated passwords because I like to manage my own passwords.
However I take offense at the notion of "babying" users. We are all babied in some aspect of our lives: if it weren't for the active work and intervention of those in other fields, we wouldn't know whether the food we eat is safe, or if the roof isn't going to collapse during the night. I'd like developers to assume some responsibility for their users in turn.
But I concede that may be beside the point in the case of password rules.
>I mean, I can imagine that a clueless user might have the illusion of safety if they're using something like "1q2w3e4r5t" but if I use "aaaaaaaaa" as a password on a website I know full well what I'm doing. So why even bother?
It's not an illusion, 1q2w3e4r5t is indeed better than aaaaaaaaa, even if it's just the numbers interleaved with qwerty (and probably easy to brute force generate up to it).
>if I use "aaaaaaaaa" as a password on a website I know full well what I'm doing. So why even bother?
Because not everyone who uses "aaaaaaaaa" (or "1q2w3e4r5t" for that matter) knows "full well" that it's insecure?
It's a password that I postulate is more secure that the average and yet is only made of two different symbols and would've been rejected by the proposed "x amongst y" character policy.
It's a bit far fetched but not that much, you'll notice that the pattern is simply the first digits of pi, so it's fairly easy to remember. And the letters are "Hn", like hacker news.
That's my point, really. If you think you know better than the user how to pick a password, then just do it. Otherwise don't get in my way, you don't know how I generate my passwords.
>That's my point, really. If you think you know better than the user how to pick a password, then just do it. Otherwise don't get in my way, you don't know how I generate my passwords.
Only they don't need to know how YOU generate your passwords. Just how most of their users generate their passwords. The suggestions and rules are not there to protect computer scientists from entering bad passwords...
zxcvbn (https://dl.dropboxusercontent.com/u/209/zxcvbn/test/index.ht...) gives it a score of 4/4 and an entropy of 10^20, meaning it would take centuries to hack at 10B a second. I think this is a slight overstatement of the security, because it's probably more along the lines of 50502^30 which is closer to 10^12. And this would be a legal password (but banned by the bullshit password rule).
I feel like the solution to everything in this thread is just to use zxcvbn and stop with the insane rules for things. In your two cases: the bank would disallow passwords below some limit while the blog would just show you a warning (in case you were ignorant of hacking enough to know that "aaaaaaaa" wasn't a good password), but let you use your awful password to spare you from having to remember it.
"COMMON PASSWORD: IN THE TOP 9635 MOST USED PASSWORDS
Your password is very commonly used. It would be cracked almost instantly[1]"
I do realise there's a difference between cracking a local system password vs a website password but always assume a site's database is going to be leaked at some point
> It's not an illusion, 1q2w3e4r5t is indeed better than aaaaaaaaa, even if it's just the numbers interleaved with qwerty (and probably easy to brute force generate up to it).
In this case, we're talking 'better' but still bullshit [1]. Calling it 'better' makes no meaningful distinction whatsoever in practice.
I agree with what you have said but I think the new guidelines don't go far enough. The biggest problem is that in the balance of security and convenience, users will always opt for convenience. Only via legislation will that change, think credit card chips versus swiping. (We should have chip + PIN in my opinion.)
We need to make passwords a much simpler thing to manage so that people don't create a bigger problem by putting it on post-its on their monitor. What I'm suggesting would take some effort but is where we need to go. Your username is your fingerprint. You won't forget that and it is very hard to fake/brute force. (Your phone already has one and a usb one for you computer would be trivial. A lot already have them.) Your password is always just 8 characters, alpha numeric only (62^8 is plenty big) and you must have 2FA on. It would be trivial for the phone manufacturer to add that at the OS level and it could be visible on your lock screen. Also, finally a good use for a smart watch. The rules are simple and you have removed the biggest security hole most companies have: people. Just my two cents....
Imposed passwords aren't the only solution. Something like Google Authenticator is an alternative. Or key fobs. Or send a confirmation code to their phone. Or something like Barclays' PINsentry [1] for cards where you need the gadget, the card and the PIN. Or face recognition, which I recently saw demonstrated (it includes liveness checks like asking you to blink).
Authenticator is great, but then you get the arsehole effect - every arsehole company decision maker wants you to only use their authenticator. So, I made an account on MS recently and can't use GA because "fuck you user, we won't stop until we own every facet of your digital existence" or something. That shows you where such companies rank security.
[FWIW I expect the reverse situation is probably the same, this is just my anecdotal experience].
Then I apologise, it must be an information 'hiding' issue then because they clearly flagged installing their own Authenticator and I was completely ignorant of the use of GA; GA must be the most popular authenticator? Does this all mean I can use a third-party auth for both MS and Google sites or is it only MS that supports third-party authenticators?
> if the user getting their password stolen is not a problem for you because it's not your responsibility to handle these issues (like a hacker news account for instance) then just let the user pick whatever they want and deal with the consequences
Yes! Please. Let users determine the value of their accounts for themselves. If I decide that say, my HN account isn't valuable and use a common password that is shared with many websites, I know the risk I'm taking and I'd rather take it than have to mark down a unique password for HN.
On sites I write I advocate for no password rules at all (hit enter is good enough for me, yes we can hash an empty string), have usually compromised on a simple length check.
Proper password storage is important, use the latest bcrypt/scrypt/argon2, don't cheap out there. You can cheap out on password rules. If you want to write a fancy entropy checker, run it client side and tell the user how secure their password is, let them choose whether they want that or not.
That's a very interesting way to categorize passwords. I wonder if one reason why banks etc. don't auto-generate passwords is to avoid liability: I can totally imagine a class-action lawsuit where a lawyer claims that all the auto-generated passwords were insecure.
>but if I use "aaaaaaaaa" as a password on a website I know full well what I'm doing. So why even bother?
I agree. Sometimes I'm just signing up to a site where I don't put any personal info up, or at least nothing more sensitive than my name. Why do I need high-level security there?
> but if I use "aaaaaaaaa" as a password on a website I know full well what I'm doing.
That's you. The average user thinks 'nobody will guess this password'. In other words don't assume they know about brute force attacks, rainbow tables, most common password lists and a host of other things that they haven't thought of or don't know even exist. They don't even know the complete group of actors that could potentially breach the account.
yeah i'm on your side. I randomly generated a password one time that ended up with 3 repeated characters. I used it because, hey p-random is p-random i'm not gonna argue. Unfortunately the site it was for rejected it.
I've since had to change my random generator to avoid 3 of a kind, which actually makes it less random/secure i believe.. pruned some branches off of the search tree.. especially since i've now told everyone ;)
> if I use "aaaaaaaaa" as a password on a website I know full well what I'm doing.
There's no substitute for length. "dog" is a bad password. "doooooooooooooooog" is much better. The entropy is still the same, but the latter takes much longer to brute force and is just as easy to remember.
Of course one should not use passwords one can remember for anything critical, but many passwords are for services where compromise is not a big deal.
Here's another problem that isn't discussed very much: error messaging and failure modes.
I use a command line tool to generate passwords, and I use a password database to store them. It has happened to me before that the maximum password length is something disconcertingly small, like 20 characters. I would copy and paste my password, submit, and then failed to be able to login. Why? Because my password in the "create" page was silently truncated on the front end, but the same truncation does not occur in all places, so I would type a longer password on the login page then what was registered in the system and it would fail.
Other times a password that was too long or contained whitespace would fail with a cryptic error message, or would tell me I failed to meet some other password rule that I know I did not fail to meet.
I don't understand how something with so many widely-recognized best practices associated with it can be implemented badly.
> Why? Because my password in the "create" page was silently truncated on the front end, but the same truncation does not occur in all places, so I would type a longer password on the login page then what was registered in the system and it would fail.
Here's an even worse one than truncating the end of long passwords: truncating internal whitespace
The change/reset password dialog for Apple ID does this. If your password is "foo bar baz bam" then it will happily convert it to "foobarbazbam" but not tell you it did so. Then when you go to log into your Apple ID on your phone, you include the whitespace, you try repeatedly and then lock your account (temporarily). Then you do it again...
Some general advice is:
- Don't silently truncate anything (i.e. don't limit the length)
- Don't silently transmute anything (i.e. don't convert to lowercase)
- Don't have a password max length with a limit less than $BIG_NUM chars[1]
- Do give the user feedback rather than silently doing anything.
[1]: You're hashing them anyway right? So the storage doesn't change. Though if you're using something like bcrypt be aware of the max hashed length: https://security.stackexchange.com/questions/39849/does-bcry.... Also you can work around that by hashing the entire uses password (with say SHA-512) prior to inputting into bcrypt.
> Also you can work around that by hashing the entire uses password (with say SHA-512) prior to inputting into bcrypt.
I wonder why people are so eager to combine different hash algorithms, especially a strong with a weaker one. If this is isn't a well-established anti-pattern, it should become one.[1] Why? Because in some sense it combines the weaknesses of both algorithms.
Assume your password hash is:
h(p) = bcrypt(sha512(p))
Assume in the future somebody generates a sha512() collision with p and q, while bcrypt() holds water:
sha512(p) = sha512(q)
It follows that:
bcrypt(sha512(p)) = bcrypt(sha512(q))
and hence:
h(p) = h(q)
So any collision in sha512() translates directly to h(), bcrypt's strength is unable to protect you from that.
Had you just used bcrypt(), you would not have been affected.
Frankly, this is about collision and not about preimage attacks (the latter being more relevant for password cracking), but the former is usually a first step towards the latter. Also, this example demonstrates that combining a weaker and a stronger hash algorithms usually does not combine their strengths, but their weaknesses.
[1] It is almost like inventing your own crypto primitives, which actually is a well-established anti-pattern.
While the collisions themselves would increase it's not statistically significant to cause an issue in practice. Plus the idea here isn't to increase the strength of the overall construct. It's to ensure that all characters that the user entered have some contribution to the final product.
What I'd consider a much worse issue is considering the following to be the same by silently truncating things:
- some really long password ... that ends with foo
- some really long password ... that ends with bar
- some really long password ... that ends with baz
The only acceptable alternatives when using something like bcrypt are:
- Restrict user passwords to 72 bytes (not chars!)
- Hash with something like SHA-512 prior to passing them to bcrypt.
People are eager to combine different hash algorithms frequently because they desire to hedge against weaknesses in one of the algorithms. Or, in this case, because they want to shore up an existing 'weakness' in one of the algorithms (for bcrypt, its maximum input size).
You are correct that doing this ad-hoc should be an 'anti-pattern'. There are subtle details (see the papers linked above...). However, the idea itself is sound, if handled properly.
One thing to note is that if you manage to get access to just the hashes, they won't have sha512(p), so they wouldn't be able to figure out sha512(q). So while your are correct that there is (technically) a weakness there, it's not one that's actually exploitable.
Can you explain how a collision helps? I mean, there's trivial collisions with the truncation that would be used instead. That doesn't mean that bcrypt(f(x)) is any weaker because there may be some other x' that f(x) = f(x').
I'm siding with vog here. Do not compose hashes¹. You may not think it's relevant that it degrades the security of your site, but nobody knows what consequences it will bring, so how could you know?
Impose your size limitation as a clear password rule. That means, write on your site that passwords must not exceed the 55, 255 or whatever characters, send back an error if the user tries to create a larger password.
1 - And completely avoid weaker hashes in general, it's not like a percent or two increase in CPU usage will have a greater impact on your bottom than having to adapt your software after it's out.
I can confirm. I spent days locked out of my Apple account (and all associated devices) because I had spaces in my passwords. After several hours with support, who needed to escalate the issue to tier 2, then engineering, the only thing that fixed it was me briefly trying a simple password -- one without spaces. I'm not sure if the issue was ever fixed, but I don't imagine I'll use spaces in an Apple password again anytime soon.
Wonder what other sins are there. A couple of years ago when iCloud was first a thing, I did a couple of password changes in quick succession. It resulted in me having different login passwords for different iCloud services. It worked for a short time then broke and another reset fixed it all.
Enforced password reset questions. There's a limited set of about 10 questions (trivial stuff like "where were you born?"), and you have to set 3 of them. About half a year ago, I was forced to do this in order to be able to log in again (I'm only occasionally using it for publishing iOS apps). What is this, Hotmail in 2005?
And the questions haven't changed in decades. It's pretty simple to figure out things like "name of high school attended", "street you grew up on", "model of first car", "mother's maiden name", etc for just about anyone who has a social media account.
As my dad pointed out, the answers are passwords. If you restricted passwords to every possible make of car, for example, it would be incredibly weak - too little total entropy in the possible answers.
(Love the name of the high school mascot, by the way!)
> As my dad pointed out, the answers are passwords. If you restricted passwords to every possible make of car, for example, it would be incredibly weak - too little total entropy in the possible answers.
United Airlines does exactly this and it's hilariously insecure. The secret questions are preselected and the answers must be from their set of answers for each. There's only 8-10 choices for each (ex: Favorite music? pop / jazz / classical / etc).
> (Love the name of the high school mascot, by the way!)
There 10 types of people. Those that got that joke and ...
My favorite restaurant in college is a high-end hotel in Johannesburg (actually it's not, and I've never even been to Africa unless you count a week I spent on Tenerife as a child).
> You're hashing them anyway right? So the storage doesn't change
No, but the time spent computing the hash does change and you open yourself to denial of service attacks. Just pick a max password length of like 200, or whatever your hashing algorithm mandates (55 for bcrypt).
Extremely large password sizes can lead to a DDOS attack on the server (due to computation complexity curve). A large size such as 4096 characters is perfect. Don't accept a password that is 10GBs in size. But don't limit to MAX 16 characters either.
Oh yeah! Freedompop actually transformed a space into a "+" (or vice versa). And this is just free internet I set up for my dad. Took us like an hour to figure that one out.
I'm guessing whatever they used as an HTTP client did it for them. It's a fairly common way to encode spaces (the alternative being %20 of course - encoding as "+" looks much cleaner).
This is why the first thing I do when I create an account -- no exceptions as long as it's not a throwaway -- is always to log out and log back in.
If there was a problem with password truncation I'll know straight away and I can either figure out what the truncated password should be and switch it to something that isn't truncated or if that's impossible I can create a new account. If I'm unable to create a new account at least I'll know to stay away from them without having done anything important yet.
I have had that weird truncation happen several times. It is very frustrating, especially for someone who is first learning to make great long passwords, because they've never come across that problem before and now have to debug it.
Recently I had another scenario happen to me: signing up for a job application login, use my password manager to make a password, everything's great. Then when I go to login, "please remove the disallowed symbol (") from the password input before continuing". Needless to say, I could not log in. And they made me wait 24 hours before resetting my password. I was much less keen on applying for jobs there after that.
I read a recent anecdote bout a similar issue. The person had their long password silently truncated to 21 chars on the reset page and 20 chars on the login page. That sounds like a super fun thing to track down as an end user.
(UK mobile network) giffgaff.com does this.
You can enter any length (as far as I can tell) on the "set password" form but the login form will only submit 25 chars.
This means you can successfully set your password to something you can never enter!
I've run into this kind of issue before. I had an 11-character password silently truncated to 10 on signup, then when I typed the full one into the login form it failed to log in.
Woo. Can't remember what clue the system gave me that let me figure out what had happened now.
I ran into one of those... with a bank! Supposed 32-character limit, but the login page truncated at 31 via Javascript (was able to force my way in via using the console). Ever since I usually don't max out the listed length during generation, just in case.
And don't you absolutely love it when you realize that your password is failing because of a quotation character. It's then that you realize how seriously poor security is at this website that requires capital, lowercase, digits, and special characters in a password limited to 10 characters and doesn't like spaces.
The same way anything else well understood can be implemented badly: naïveté, incompetence, ignorant ukaze from on high, "well we had to have something but there wasn't enough time", or some combination thereof.
I think it was an account I had with Sony Planetside where the password was lowercased on signup, but not all parts of their site did it....... (e.g. forums, game itself, etc).
This partially happened to me on NBA League Pass. It was particularly confusing because I wasn't completely locked out. The failure mode was that my password was one character too long, and was truncated. On the login form, the length was restricted by javascript if you typed in the password, but using auto-fill from 1Password bypassed that.
I thought they were locking me out for proxying or something until eventually by luck I noticed what was going on.
I had a fun issue a few months ago with Team City at work. I was setting up a build to upload to our internal Nuget server, but the upload kept failing. I finally discovered (I don't remember how, but it took hours) that our randomly generated Nuget API key included a character that Team City didn't like and it was silently stripping that character from the input field in the build setup.
This just happened to me on the Wii U with my Nintendo ID. I had set a 20 character password some time in the past(probably the limit on whatever webpage I used to sign up) and when I tried to log into my Wii U recently, only 16 characters were available for entry.
Hotmail did that my super long password, it freaked me out at first and I had to guess where the cut-off happened because I couldn't find the damn password length.
Funny thing is this sort of password bug bit me on PayPal. PayPal of all places! Not sure if it was the length or a disallowed character, but no actual validation took place. Would let you "change" it to something and then never allow you login.
Somebody got into my bank account and attempted to steal some money. Luckily, we were able to stop it quickly and the bank had the money back in our account the same day. It was pretty upsetting so I sent a letter to them with a lot of questions about their system and eventually somebody from the inside called me.
One of the questions I asked was why they limit password length. The (low) limit suggests that they were storing the password rather than a hash of it. They wouldn't confirm that was what they were doing, but their ultimate answer to me was stop worrying - you aren't responsible for fraud.
I also asked for a list of all the external IPs that had accessed my account and I couldn't get that for privacy reasons. I'm not sure whose privacy they were worried about, but I guess it wasn't mine. In the end, it was an incredibly unsatisfying exercise.
I changed my bank's online account password lately because it wasn't a good password, and then I forgot my new password. Resetting my password was a fucking joke, anyone who's acquainted with me and can do a few google searches could get into my bank account if they had my card number. It's not just their hardware, their whole security practices are messed up but they don't care because the federal government insures every account up to 100k.
Their website is probably front-ending mainframe CICS screens that have a short password field, saved in plain text, just like when it was developed in the 1980s.
I'm surprised that this article didn't mention the most important point about password rules:
They force you to come up with a new password that you probably haven't used before and so you will probably forget it.
There are websites that I don't use often where I literally have to reset the password (and go through all the i-forgot-my-password steps) every time I want to log in because they forced me to come up with an overly creative password.
I think most people have two or three passwords for all their apps/services; one very secure one, one medium security one and one low security one (where you literally don't care if you get hacked). It's not the company's business to tell you which of those classes of passwords it deserves for its website.
You really shouldn't be re-using passwords across sites anyway, since all your accounts are compromised if any of them are compromised. Since re-using passwords is a problem solved by using a password manager, I'm assuming you're not using one, in which case you likely won't even remember the list of sites where you have accounts that have a shared password if you need to change it when any of the other sites are compromised.
Best to just use a password manager and keep unique per-site passwords.
I'm quite hesitant towards using a password manager. All secrets are protected by only one single password, and to make the tool useful, it should be accessible from anywhere and I would use it quite often too, increasing the limit of my master PW being stolen (whatever way, keyloggers, shoulder surfers, cameras...). Thus, I rather memorize a handful of unique high-security passwords for important services and one or two low-security ones for all the rest I don't care about.
Of course, it's a different situation when e.g. managing many sensitive servers which you only access from work or so.
All secrets are protected by only one single password, and to make the tool useful, it should be accessible from anywhere and I would use it quite often too, increasing the limit of my master PW being stolen (whatever way, keyloggers, shoulder surfers, cameras...)
True, though your handful of passwords can be stolen in the same way.
With a password manager, you:
- ensure your master password is not transmitted over a network
- ensure you never reuse passwords
- ensure you have long, strong passwords everywhere
- never forget login details and never worry about remembering yet another password
On the other hand,
- you _need_ access your password manager in order to login
- you now have a single point of failure
- cloud-based password managers are very attractive targets for hackers
I don't like these aspects of it.
Still, a password manger is incredibly convenient and I do feel a greater sense of security/confidence when I copy a big old 64 character password to log in. As it is, I use so many different services (gmail, github, slack, aws, steam, dropbox, reddit, etc, etc) and that number is only going to increase. I think a password manager is a practical, scalable solution to both remembering login information and improving my security.
The security process that has really worked for me is using the "forget password" as means to get a "login token" into my mail, which is protected with 2-factor auth.
I don't have to deal with password managers, maintaining their files. Or deal with multiple passwords.
Most of my accounts use my low-security password, I don't care much if they all get compromised. I only use my high-security password on 1 site.
Password managers are horrible - Whenever I change machines, I could never remember all my passwords and I certainly don't want to store my passwords in the cloud.
I wonder why people still think that their passwords are stored on the external site. It's explained on the "how this works" or whatever for most services like LastPass.
> Password managers are horrible - Whenever I change machines, I could never remember all my passwords and I certainly don't want to store my passwords in the cloud.
"There are websites that I don't use often where I literally have to reset the password (and go through all the i-forgot-my-password steps) every time I want to log in because they forced me to come up with an overly creative password."
Indeed and then one's email potentially becomes the weakest link in one's password security.
If a site offers email resets at all, how often you (legitimately) use them generally doesn't play into the security analysis. If it's easier to get access to your e-mail than to get the password to the account that can be reset by proving access to the e-mail, then your e-mail is the weakest link.
>"if it's easier to get access to your e-mail than to get the password to the account that can be reset by proving access to the e-mail, then your e-mail is the weakest link."
For me it's gotten to where I just assume next time I need to log into the website, 6 months from now - car insurance for example - I simply expect to recover the password. No password really matters besides my email.
My current pet peeve with password resets goes like this:
1) Forgot the password, start the recovery process.
2) Get to the "create a new password" phase, look at the rules.
3) Rules require special characters, caps, etc. So I make one.
4) I get the "This password has been used before" error.
5) Now I have to think up a new random one.
If that password 'that was used before' was the current one, why can't I just continue to use it??? Now I remember the password (usually because of the silly special character requirements), so we're good, right? Wrong.
Related, some of these sites you forget what you used and have to create a new password - and some of them do this horrible "You cannot re-use your four last passwords" thing which leaves you in this sort of permanent "I'm never going to remember and always have to come up with something new" loop (for sites you go to only periodically, e.g. an HR portal, let's say). But hey, nothing important lives in an HR portal, right? :P
Employee of a university here. Not only are the password requirements annoying, unless you close the browser you aren't logged out. Clicking "logout" makes it look logged out, but the next person to use email/payroll enters their credentials and gets the prior users account. Hilarity ensues with people applying for each other's leave, emailing responses to messages that weren't for them etc. The interim response is for people to set a theme in their email to make it more dictinctly different. I kid you not.
Shibboleth user? I can't even imagine how difficult that kind of problem is when you're working with other people's software.
* Go to some service A.
* Get redirected to SSO and authenticate.
* SSO confirms your identity and A issues you a session token.
* You log out using your SSO.
* Go back to A where you're still logged in with your session token.
At a certain point I would not be willing to commit to maintaining lots of patches to every product we host and just tell our users to close their browser.
OMG very true. Often, it seems that all these password systems are designed for celebrities; maybe if there were teams of people working 24/7 to hack my account, then it would make sense.
This is why my new server system sends you a password for every login you want to do to your email. Of course you do stay logged on, so it is not needed very often.
I totally agree that arbitrary password rules are not a good thing, they frustrate users to no end, and can make things less secure.
I really liked the zxcvbn library from Dropbox, as it allows you to catch those really egregiously bad passwords before it's too late, but is much smarter than any list of arbitrary rules could be. I actually wrote a similar library (nbvcxz - https://github.com/GoSimpleLLC/nbvcxz) for my company which implements all of the functionality of zxcvbn (and extends it as well) so I could use it on the server side.
Travel to some other side of the world and France's CNIL recommends[0] the following password rules as of 27 Jan 2017 (abridged):
- if the system uses a login + password scheme: 12 chars min and mandatory mix of all among non-caps/caps/digit/special
- if the system uses a login + password + time-based exponential backoff rate limiting with a baseline of 1 min after 5 tries maxxing at 25 per 24h or lockout after 10 tries or a bot detector such as captcha: 8 chars min and mandatory mix of 3 among non-caps/caps/digit/special
- if the system uses login + password + environmental information (such as IP or MAC addr, etc...) + time-based exponential backoff rate limiting with a baseline of 1 min after 5 tries maxxing at 25 per 24h or lockout after 5 tries or a bot detector such as captcha: 5 chars
- if the system uses login + password + hardware second factor (SIM, U2F, YubiKey...) + lock out after 3 tries: 4 chars
To fend off in-transit and offline attacks, the document suggests that auth should transit sufficiently encrypted (using a cipher or method currently recognised as strong and non-vulnerable) and passwords should be stored obfuscated using a secure (similarly defined as strong and non-vulnerable) one-way cryptographic function with salt (and possibly pepper since they mention a "key", which makes no sense for one-way crypto functions).
Essentially, Facebook accepts 4 forms of the password as correct: 1) the correct password, 2) the caps-lock inverted version, 3) the correct password but with the first letter capitalized, and 4) the correct password + 1 character of any type. Each of #2-4 seems to be designed to prevent a failed login for the real user under common error cases, particularly when logging in on a phone.
Since each of those options can be easily stored as hashes (with #4 being done by also testing the entered password with the last character omitted against the correct password hash), the only weakness I can see this introducing is that if hashes were leaked, there's 3 valid passwords that could be found by an attacker rather than just 1, but with good hashing practices, that doesn't seem like a big deal since the search space will still be quite large.
With that in mind, that seems like a user-friendly addition that doesn't introduce any major weaknesses. Anything I'm missing that would make this a crazy scheme to have implemented?
Yes, it would reduce the search space three-fold (the 4th mechanism uses the same stored hash as the 1st), and your suggestion of different salts would prevent that since each password variant would need a separate search. Still, the difference between looking for 3 things out of ~10^20 options vs. just 1 thing is not that big.
I don't see much sense in claiming that a mere 2 digit increase would be the crux of the problem. Sure, nowadays since most websites enforce a 8-digit limit, most cracked passwords are 8-digit long. So what? If everybody goes to 10-digit passwords, then aren't we back to the status quo and most cracked passwords are going to be 10-digit long as well? Also, how much does a 2-digit increase make the brute-force computation much harder anyways? By dropping those requirements the cracker's job can literally get much easier instead of harder even with the length increase.
I don't think the point about random password generation is much valid either. Since most websites just have such password requirements in place, why wouldn't those generators just remember to put the upper case and special characters into the final result? They might try to generate them separately and insert them at a random position. That shouldn't compromise the password's security right?
As a side note, I also don't get why for Chinese websites a limit of 6 characters would be a good idea, as he spends the whole article talking about length... Surely many Chinese don't use English words (though many still do actually), but they use pinyin, which is a way to write Chinese characters with Latin alphabet. Literally nobody uses real Chinese characters as passwords, and most websites just downright don't support them. Clearly he doesn't know much about Chinese websites anyways...
In all, I think most of his articles are excellent but this one is really a bit off the mark IMO.
Password reuse across sites.
Have some check as to whether the same password can be used for the same username / email across other sites. I discovered this one early; back in 2000 I was an admin for a student portal at uni created by Virgin. As an admin I could manage people's accounts; including reset their passwords. The field for me to change their password had their current password; it was hidden by asterisks so I couldn't see it... until I clicked view source on the site :/. So now I had everyone's passwords & their email addresses; my guess is I could have taken advantage of this for at least 80% of those accounts.
Password change frequency.
Changing your password can be annoying; but there is some benefit (so long as you're not changing too often).
Password reset rules.
If you click "forgot password", many sites still use the memorable question with questions which are often publicly available (e.g. to get someone's mother's maiden name, this information's on the public record, and can often be found through someone's social media too by looking through their contacts, then the contacts of those sharing their surname; as their mother's maiden name will match their uncle's surname, and most people with their surname will be friends with both their mother and their uncle). Emailing a reset link is great; but relies on email which isn't (and some people's mail's very unsecure; e.g. company mail can often be legitimately viewed by the company's IT team; and that's the non-hacky scenario).
Regular forced changed of passwords is generally a net-negative for security.
There's nothing wrong with changing if you think it's been breached or just 'cause you feel like it, but a system forcing change every 90 days is likely to be a bad idea.
This is due to the fact that when most user groups are forced into periodic change they will stick an enumerator at the end (e.g. password1, password2 etc) which ruins any benefit you might have got from it.
I assume you are referring to the NIST SP 800-63-3, which is quite new (still a draft).
PCI DSS follows NIST guidelines quite closely. Requirement 8.2.3 reads "refer to industry standards (e.g., the current version of NIST SP 800-63.)". These requirements will probably be updated at the next version of the standard (and I hope they will!).
Particularly for sites where you're unlikely to return for months/years (government, utilities, charities, small ecommerce sites) this is a fantastic approach.
Can anyone explain why all authentication systems don't enforce a (say) 2-second delay on repeated password attempts? Wouldn't this solve nearly all insufficient entropy problems?
Even a 5-character password should suffice in this situation, and a human user would never even notice the 2-second delay. How would malevolent password-crackers get around this?
I really like Fail2ban for SSH lockdowns, but I worry about using it for repeat login attempts on an application. Depending on the application, this could possibly lock out everyone in an office, campus, etc. For certain critical services being used by everyone, this could cause a fair amount of headache.
The main problem is not the response time of http requests. Is when you are hacked and the database is leaked and becomes avaliable for anyone to brute force it at any speed they want.
I wonder it who designs those rules, in general, notices that when you require "at least one Uppercase" people will just press shift for the first letter, and when you require "one number" people will suffix or prefix the password with the number "1" [0]. And I don't know how that would increase security.
This article starts by using an example of 8 "bad" password rules, but by the end of the post, Jeff ends up suggesting 5 of the 8 anyway. This post really should have been called "special character requirements are bullshit."
I'd be willing to bet that a future version of Discourse will also disallow using your previous password as well. Then we'll get another password blog post talking about how hard passwords are and how we need more rules for passwords. Experience is a funny thing.
I have to use Dashlane for work and it horrifies me that their password requirements are so outdated. A password manager ought to know that it's more important to have a longer password than a password with a number in it.
Excess in password complexity policy is bullshit. I'm surprised Atwood would write knee jerk nonsense like this.
If you follow the NIST guidance, it's not a problem at all. The bullshit happens when you allow infosec people who lack applied skills and go overboard in their analysis of policy and standards documents. Those infosec people wrongly see increasing entropy as equating to high assurance -- in reality increased complexity leads to ad hoc "something you have" tokens (i.e. My complex password is written on a post it note).
You need length and complexity standards because users don't know how to measure risk, don't understand what a good enough password is and don't really care. So people do stupid shit like make their password "qwerty". It puts their data and the integrity of your system at risk.
Disregarding the navelgazing about cultural insensitivity re: character sets, a 10 character length + 3/4 of upper/lower/numeric/symbol, combined with lockout controls ensures a reasonably high level of assurance. Again, per the NIST guidance, if you need more trust, you need multiple factors.
I gave up on this long ago. I login to various accounts from different machines often enough that a password manager doesn't always work for me. I keep a printed paper copy of some 60 different passwords in my laptop bag in case I need to remember one for a new machine. That printed copy gets handwritten notes on it from time to time, which I then use to update the text file on a thumb drive when I'm not connected to the Internet. I print a new copy about every two months, I guess.
To add to the bullshit, it is so common that a site will have some idiotic rule (like "must include a number," "must have at least one lower (or upper) case letter," "must include a special character," "must not include any of these special characters," "must change password every 30 / 45 / 60 / 90 days"), that I don't even get mad about it anymore. I can't even spend the mental energy to send them an email.
Password rules are one of those bike-shedding moments project managers and clients love so much. To show their brilliance, they invent complex password rules, define database field lengths and ask for infinite scroll on everything. Can't expect a code monkey to do the job right.
I just yesterday had to sign up for some bullshit "secure email" service to read some email from my late uncle's bank. They had all the rules described in the article, and I could not use highly secure generated passwords. I finally settled on some super weak password with one of each requirement (char, case, symbol) tacked on to the end. Sigh.
To make matters worse, the email looked just like a phishing attempt. Right down to having you download some html attachment, which, after it opens, directs you to click on something which finally takes you to the "secure email". The whole process felt like something a scammer would come up with, and is really not how banks should condition their customers.
What infuriates me is when I attempt to login to a site with a password that doesn't conform to their password rules, the site doesn't give any indication. It would be so easy for sites to return an error "The password you entered couldn't possibly be your password because it doesn't conform with the site's rules. Here are the rules again FYI" so I can figure out what dumb workaround I had to go with to make an acceptable password.
Serious question: given those rules, are there more invalid or valid passwords within those constraints?
At first I thought the answer would be obvious but the more I thought about it and did some scribbling I couldn't come up with a good answer. Math is not my strongest skill.
Let's assume you had hashes of passwords following these rules and knew the hashing algorithm, could the rules be so restrictive they narrow the search space and actually make it easier to crack them than no rules at all?
Thou shall take care of the password manager, as it is a single point of failure. Because users (=not people who read and understand news from hnews, but the layman):
1 - won't make backup of the password manager (PM) database
2 - will forget sometimes the main password of the PM
3 - will loose the cellphone where the PM is installed
4 - will not update the PM
5 - will tell somebody else the PM password
And there will be many PM, some will have flaws, bugs or backdoors. Some will work on iOs but not on Android. Some will mess up in same point and make users lose trust.
And there will be sites with bad interface that won't accept copy-and-paste of the passwords. That will require things that your random-generated password doesn't contain. Will complain about something that it contains. Will do good on the password but will have those stupid questions (maiden name? grandfather name? pet name?) that you'll be able to find in any Facebook. Than the weak point becomes the password recovery.
I just found one type of requirement that was good enough to people take real care with the password: when the password is the one that allows anyone to withdraw cash from their account. When there is real money in the game, people take care.
We hit "peak password" somewhere around 10 years ago. Passwords are both bad security and bad UX. Cryptographic secure keys are better security, but at the cost of a much worse UX.
Bad UX is a defect. We need to stop giving a pass to crypto programmers who make such shitty software. Software that is not easy to use won't be used, and should therefore be considered as insecure as any other defective software.
I wish we could just avoid all of this by using methods like SRP[1] where the site wouldn't even need to know the plain-text password in the first place. Why am I giving a "secret" to someone else?
I've been intrigued by trying to circumvent passwords completely. On the vast majority of websites your password already is only as secure as your associated email account. You control the email you can reset the password. So maybe we can build on that? Instead of entering a password I entered a code that gets emailed to me either manually out via link. For important things we can airways supplement with another token from a TFA app or better TFA device. I'd argue that this would be more secure for the average user and more convenient for at least some users and use cases. I personally would find this mildly annoying on my laptop where I'm already logged in to a password manager, but convenient on my phone where logging in to a password manager is a major pain. Cheapshark.com does something similar and as a user I find it a great experience. It's more of an obvious fit for something like this where your account isn't very valuable and you use infrequently, but it's really no less secure.
I find it interesting he mentions Emojis as I actually just recently wrote a deterministic password generator that uses the Emoji annotations (for word selection) for generating deterministic passwords from a master password: https://github.com/agentgt/ezpwdgen
Of course you could use the EFF word database but after trial and error I actually like the Emoji annotations [1] better (I obviously remove short words and non ascii stuff).
I plan on having the script show the words along with the corresponding emoji (iterm supports emojis) to help remember. The idea being not to copy and paste (I need practice on remembering stuff anyway... the joy of getting older).
Let's imagine a theoretical world in which every service had a 12 or 15 character limit on their passwords and no other restrictions.
Does anyone really believe that the list of most common passwords would not contain equally inane entries as the ones presented in this article, just modified to be longer? "qwerty" would just become "qwertyuiop", etc. People using these passwords are just filling the minimum requirements with something easy to remember. Making them fill more characters wouldn't really change that.
The only reason the most common passwords are short is because so many services allow short passwords. Users gonna be users no matter how long their passwords need to be.
That said, I agree with the article in spirit. I hate password restrictions. I just think that the argument about most common passwords being short is a spurious one.
I think its interesting that passwords have been undergoing a transformation as of late.
Is password hacking really still that big of a deal? I mean, most big hacks into retail places like Target, Best Buy and others are done by getting into their POS (point of sale) systems, or hacking their networks to get at the customer data.
I just don't see a lot of one off doxxing to get into a persons email or financial records. Most groups are going after the big scores, not small potatoes stuff like a few hundred cracked password protected accounts.
I could be wrong, but it just seems like even when you protect your accounts with a strong password and triple layer redundancy and six-step protection, all it takes is one SQL injection or an Adobe Flash flaw and all that work is useless because the company holding your information was lax with their own security.
"When the DB with clear text passwords is stolen from our server, because we haven't installed updates in three years, at least your other logins won't be affected."
There's no better way to communicate this to your customers than complex password requirements.
Who cares about remembering passwords? Like my burner mobile phones, I use burner passwords. I use a one time password and the next time I need to log in to the website, I request my password to be reset and use the link that is emailed to me...
Rule 1 is that password rules are bullshit, but all of the other rules lead to needing Rule 1: how are you going to explain to a user that their password cannot be their username, or that their password needs more entropy or complexity?
To be honest I think this is a problem that needs to be solved outside of the web. We need to move towards password managers.
Of course, that comes with its own set of issues: Lose access to the password manager = lose access to all your accounts. An attacker gets access to your password manager = they get access to all your accounts.
On the other hand, for users who use a single 6 character word as their password all over the web, that's essentially the same thing. You can far more easily educate someone in picking a very strong passphrase they will never forget, than get them to use different passwords on each website.
I have successfully converted several non-techies in my family to KeepassX [https://www.keepassx.org/], which I also strongly recommend to anyone here. I had to hold hands at first but after explaining how it works and making sure they understand how important it is, over two years, there's never been any issues.
Rule 5 rejects nulls; if your password is your username, you don't have a password.
Meanwhile my organization is getting ready to mandate the use of a password manager that uses bullshit rules to produce analytics to surface at the director/VP level. So it goes. I look forward to automating the GI that's used to produce this GO.
Just spitballing, but it's possible that you could take the given password and derive the hashcat invocation that would generate the password. In the strictest case this is equivalent to computing the Kolmogorov complexity of the password, but there's an easier way: have a list of the X most common rules, and test the password against those. Once you have the rule, you can calculate how many possibilities exist in that search space and do a calculation ala GRC Haystack[1]. If it's the case that the list of rules doesn't have one that matches the password, that's probably good enough anyway.
Saying "less than 8 chars is close to no password" is stupid. It just means, if your service provider hosting your short password get hacked, if they store their users password in a crappy format, then your password is gonna be recovered.
I was trying to sign up to an online gaming site recently, and my initial password was shown as being "strong" but was rejected — not enough "special" characters. It was 24 chars long and straight out of Keepass, but whatever.
I asked Keepass for another password; it included special characters, was 24 chars long and "very strong", according to the website. Rejected.
I then noticed that the message was telling me I could not have more than 16 characters, so I trimmed the password to something rated as "medium". Accepted.
The biggest issue with passwords is using the same one with the same username everywhere. I knew this, still did it with accounts I didn't really care about (Netflix, Hulu, Skype, etc) and, of course, after 10 years of using the same one, just about every place I used it was getting accessed by someone else over the last few month. Writing down passwords and keeping them in plain site in your house is probably safer than using a username/password combo that you use a lot, on a system any script kiddie can get at.
Another major problem I have with password restrictions - how about you make sure your stupid password dialog is capable of accepting the passwords generated by password managers? How about you just test the 5 or 6 most common ones? I hate it when I accept the suggested password from Safari or 1password and the stupid site won't accept it because it used the wrong kind of special character, or didn't include enough capital letters, or worst of all - it's too long.
Ten years ago I thought we were all going to solve this with OpenID and strong protections on the provider side. [1] What happened? I know a bunch of providers moved on to OAuth which let users authorized 3rd parties to do stuff on their behalf. And then at some point we decided v1 was hopelessly broken and moved to v2. But today it's still the rare event where I can login with my {Gmail, Hotmail, Yahoo!} account.
[1] U2F, authorized devices, predictive phishing protections, etc.
>only 5 of the top 25 passwords are 10 characters, so if we require 10 character passwords, we've already reduced our exposure to the most common passwords by 80%.
That's not an accurate measure. Like, take two of the example common passwords: 123456789 and 1234567890. What do you bet that the people who'd pick the first would pick the second if they had to use 10 characters? Plus, attackers don't have to try passwords that fail your requirements.
Rules are annoying; passwords are what's terrible, full stop.
They are merely the only thing we know how to do which meets the expected constraints on auth. I can't even give them a grudging 'least bad option' because they're so bad, in our current context and multiplicity of identities.
They are so unmanageable for normal humans we have a bunch of helpers, which become the new single point of failure.
Yubi dongles on a keychain may well be where we're headed.
Password rules are especially bullshit on mobile devices where the pain of caps (requiring shift key) and the pain of special characters (often requiring a change of keyboard) are extra severe punishments.
A long all-lowercase pass phrase that's pronounceable is both safe and easy to remember and easy to type on mobile devices. When I hit sign ups that require other characters while on a tablet, I frequently decide I don't need it and bail out.
Side topic: As an end user, the worst for me software that only tells you what's wrong with your password AFTER you've done it wrong, and then only tells you one thing at a time even when you've made multiple errors (dictionary word, password too short, needs one capital letter, needs one number...). Just tell me the damn rules and let me get on with my life!
A problem with using emoji in passwords is the emoji special character keyboard shows your recently used emoji. Brute forcing a password using the recent emoji list certainly gives you a much smaller set to work. Also, the Chrome browser doesn't let you enter emoji directly, but you can paste them in (which show as two dots •• ).
Inspired by this, just wrote a Ruby gem that handles passwords exactly how Atwood suggests. It's still a work and progress but I think it's off to a good start. Let me know what you think.
I just use the recover your password functionality over and over on many sites.
I hit some keys typing into notepad then paste that into both password reset boxes and then paste it again logging in. Sometimes though I have to type A1! on the end if the site requires capitals or a number or a special character.
In mockery of the socialist past someone once wrote: "wouldnt it be better the goverment voted for a new people and dissolved the nation to get to the root of the problem.."
"Wouldnt it be better, the admins switched to better more learned users and dissolved the company to have the provlem get root."
Could someone explain why password length is so important when logging into web services? I get that it's important for encryption, but when you implement a web service that has rate limiting, a basic password length of say six characters should be sufficient, no?
After explaining why many common password rules are bullshit, the author presents the few remaining rules that aren't. Or rather: if you're going to subject your users to the bullshit that is passwords, here's a set of rules that optimize the security:bullshit ratio.
While I've obviously encountered frustrating arbitrary password rules on various small/ancillary sites, Stackoverflow/Stackexchange is the only service I use regularly that I've hit real problems with...
i'd prefer no password validation other than having to type it twice. but have a password strength gauge, and give hints on how to bump up the strength (have you tried using a non-alphanumeric character)
The main reason is that, if IT chooses the user passwords, then the users simply forget the password. Thus, the system for resetting a lost password becomes part of the default login process. In which case, you might as well having a password in the first place.
Because unless users are using a password manager, they need to be able to remember them (and anyone using a password manager is going to be generating secure passwords anyway)
As a side note, if you are a website with arbitrary rules, as a general UI recommendation, please state your rules if a user inputs an incorrect password. I'm looking at you yahoo.
If the salt for every user is the same, is it a good practise to check the password hash against existing's (registered) and reject a duplicated password ?
Why don't we dispense with the pretense that passwords should be human readable strings of characters at all, and just make them a sequence of randomly generated bits.
Passwords often need to be human readable because, in practice, humans often need to memorize them and then enter them from memory, or write them down on a piece of paper first, which can be error prone with a complex password.
Using a password manager isn't always an option either - there is a vast amount of infrastructure, much of it corporate and nearly immutable - that simply presents the user with a password prompt and expects them to get it right.
It's only recently that some password prompts even let you view the password you've typed. With a terminal, you get no visual feedback at all.
Password managers suck as soon as you need to share a password - like the password for a SaaS admin panel used by several people at a business. Not all services support multiple users (or multiple admin) users.
The trick of password rules should be (and this is what xkcd was getting at) to trick users into using passwords that they find easy to memorize, but are still high entropy. Long passwords can be high entropy, but, as highlighted at the end, they can just as easily be low entropy. If they needed to memorize it quickly, most users would pick a low entropy long password. Also, every users opinion of what makes a long password easy to memorize will be about the same - repeated letters, patterns on the keyboard, english words. This means that you can try to detect easy to memorize password, and flag them as bad. However, users will find something easy to memorize you don't block, and use that instead. This new thing will probably be common to all users as well. I once had someone inform a group that they should all use the first three letters of their names to overcome a password restriction. While the restriction probably assumed people would pick a random three letter string, they instead chose an even more obvious one then they would have otherwise.
When making password restrictions, try to force every user to come up with a different opinion of easy to memorize. For example, you could display pictures of ten foods, and ask users to pick their favourite food. Since eveyones likes different food, their choices would probably have a relatively even distribution. Moreover, upon returning, each user would reidentify the same food as their favourite. By extending this to a larger field of subjective values, you could make the overall datapoint high entropy, while maintaining memorizability.
from a security standpoint. I hate the required special characters BS, especially since other sites will explicitly restrict you from using those same characters. Seriously, without a password manager of some kind I don't know how people can function online.
This is perhaps not the place for this, but as a user of a password manager, here's and idea in this area that I've had for a while.
I'd like the various password manager vendors to get together and produce a standard/specification to take us (users) out of the process of registering and rotating passwords as much as possible in much the same way that they have the login process. Among other things, the spec should define a format for expressing password validation rules, a password rotation endpoint/policy, common registration fields and a url handler for triggering the registration process.
So then site operators could add a "Register with a Password Manager" link that, perhaps, looked like: "register://example.com/path/to/registration/policy.json" The various browser extensions could easily recognize that and change to "Register with 1Password" or "Register with LastPass" or whatever is appropriate. That policy document would have the registration endpoint, rotation endpoint, rotation period, password rules, required registration fields, what sort of identifier is used (username, email, etc), terms of service and possibly and endpoint for determining the uniqueness of potential usernames. Clicking the link would open up the password manager where the user would agree to the terms of service, enter any missing fields, approve the sending of fields the password manager already knows about and select a username, if necessary. Once completed, the password manager would generate a legal password of maximum length/complexity, send everything to the registration endpoint and save the login details, terms of service and rotation endpoint for future use/reference. Over time, the password manager could update the password in the background to limit the danger should the password be compromised.
I'm curious whether others think this could work. I realize there's an http://xkcd.com/927 problem in it, but it seems like if all the password manager applications could agree to work together, enough site operators would be willing to implement it that it could be useful. And if enough people saw "Register with a Password Manager" links during the registration process, they might get curious enough to start using one. But most of all, I'd like to stop having to care about what a site's password policy is...just let sites make the decision and offload the responsibility for adapting to it to my password manager.
> I had a bit of a sad when I realized that we were perfectly fine with users selecting a 10 character password that was literally "aaaaaaaaaa". In my opinion, the simplest way to do this is to ensure that there are at least (x) unique characters out of (y) total characters.
Isn't that exactly what you're complaining about with your arbitrary password restrictions to begin with?
I mean, I can imagine that a clueless user might have the illusion of safety if they're using something like "1q2w3e4r5t" but if I use "aaaaaaaaa" as a password on a website I know full well what I'm doing. So why even bother?
I think there are two possible ways to look at this problem from a service provider perspective:
- if the user getting their password stolen is a bad thing for you (i.e., you're a bank or something like that, and getting an account compromised will put you in trouble), then IMO the only satisfactory solution is to impose a password to the user. In effect these ridiculous password requirements are exactly that, except less convenient and secure. Cut to the chase and say "your bank password is Axei5aoc0i, write it down somewhere safe".
- if the user getting their password stolen is not a problem for you because it's not your responsibility to handle these issues (like a hacker news account for instance) then just let the user pick whatever they want and deal with the consequences. If they care enough about it they'll care enough to pick a decent password. At most if you really want to be friendly give an indication that a password might be weak, but please don't disallow it.