Password Rules Are Bullshit
blog.codinghorror.com
blog.codinghorror.com
> 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.
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?
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.
- Password Recovery (this can be optional though, for my sites it usually is)
- 'Legit Users', sending an email and having them confirmed through a code in them gives a bit more confidence in the user
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.
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.
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.
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.
Yes. Or my name/address/phone number. It's essentially a machine-readable address label, the email is just one part of the vCard.
Do you people really not keep a book of stamps in your car? Such inconvenience!
> Do you people really not keep a book of stamps in your car?
No, why would I do that?
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.
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.
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...
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.
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.
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.
If we didn't have a monoculture in email providing, this would be far less of an issue.
"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.
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
Server → jim@example.invalid: Please go to https://server.invalid/register?token=KDU6dG9rZW4xOWppbUBleG...
User: visits URL, completes registration
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.
Seems like the simplest solution is to have some basic password requirements.
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.
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.
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?
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.
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.
Very many people. And not all systems stop them from doing so.
And database leaks happen all the time too...
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.
There's a difference between random script kiddies and targeted attacks. People do all sorts of wacky things.
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)?
root ssh:notty 116.31.116.44 Fri Mar 10 22:27 - 22:27 (00:00)
root ssh:notty 116.31.116.44 Fri Mar 10 22:27 - 22:27 (00:00)
...
Login using the root account is disabled.
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?
"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
[1] https://howsecureismypassword.net/ (Don't go putting real passwords in there..)
47 TREDECILLION YEARS to crack your password
Why not create even stronger passwords with Dashlane? It's free!
I didn't know that was a number!
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.
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...
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.
In this case, we're talking 'better' but still bullshit [1]. Calling it 'better' makes no meaningful distinction whatsoever in practice.
[1] https://dl.dropboxusercontent.com/u/209/zxcvbn/test/index.ht...
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.
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.
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.
"What is your mother's maiden name?" - "gHk899iL@"
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).
https://www.united.com/ual/en/us/account/enroll/default
Derp.
My solution is just to keep those answers in the "extra notes" section of my password manager.
So-called "security questions" are the dumbest security measure.
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.
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.
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)...
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.
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.
[1] http://www.barclays.co.uk/Helpsupport/UpgradetoPINsentry/P12...
[FWIW I expect the reverse situation is probably the same, this is just my anecdotal experience].
> 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.
I suppose you could open a pull request :) https://github.com/usnistgov/800-63-3
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.
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....
So fingerprint gives you part 2 and password gives you part 1.
No need for an additional MFA device.
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.
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.
Nothing makes me immediately dismiss a site or piece of software faster than nannying me, especially from go.
"So I send it to my mail account for when I am on the go... that account with the qwerty password..."
The point being, you can't really protect users from themselves so a bank can't build it's security model upon the assumption of safe user accounts.
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 ;)
I don't want to trust a bank who knows my password.
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.
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.
This means you can successfully set your password to something you can never enter!
It has been raised in their forum but the discussion there is drowned out by people missing the point entirely. https://community.giffgaff.com/t5/Help-Support/Password-Limi...
Woo. Can't remember what clue the system gave me that let me figure out what had happened now.
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 remove anything (i.e. don't remove whitespace)
- 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.
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.
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.
I see. If that wasn't a design goal, this construction is sound.
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.
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).
Model of first car? zSuI2LR9DvDYwr04 (drop top!)
First city visited? GGSrqPB78tcJ2WB9 (what a trip!)
Street you grew up on? 1pAXzzns5owXNYiU (very quiet!)
Favorite food? oEW5AQ738bkGf6rj (it's delicious!)
High school attended? 3i5OfyNhnWD0bQVy (go Nonces!)
(Love the name of the high school mascot, by the way!)
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 ...
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 thought they were locking me out for proxying or something until eventually by luck I noticed what was going on.
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.
The same reason why we have other kinds of crappy software: People try to do it themselves rather than using a robust, tested, third party solution.
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.
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.
I think the future will be passwordless with biometric as a added layer of safety.
* 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.
Indeed and then one's email potentially becomes the weakest link in one's password security.
This was exactly my point yes :)
Best to just use a password manager and keep unique per-site passwords.
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.
1Password can sync locally which is a nice plus:
But you're not. You're storing an encrypted blob in the cloud. You just need a good master password and a password manager that isn't broken.
Of course, it's a different situation when e.g. managing many sensitive servers which you only access from work or so.
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.
I don't have to deal with password managers, maintaining their files. Or deal with multiple passwords.
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.
It's a great one. Not only does i recommend against composition rules, but
> Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically)
Oh, if there is a sin against passwords it is forcing quickly memoizable (i.e. simpler) passwords.
password1 -> password2 -> password3
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.
- 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).
[0]: https://www.legifrance.gouv.fr/affichTexte.do;jsessionid=DCF...
P a s s w o r d 2 0 1 7 .
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?
Would someone who has access to all 4 hashes be more able to crack said hashes than if they only stored one?
(Or would they salt each hash with a different salt to negate this?)
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).
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.
That's why we've (finally) started to see good official guidelines saying forced password rotation is a bad idea (e.g. https://www.ncsc.gov.uk/guidance/password-guidance-simplifyi... and https://nakedsecurity.sophos.com/2016/08/18/nists-new-passwo... )
- Contain both numeric and alphabetic characters.
- Users to change passwords at least every 90 days.
- Password parameters are set to require that new passwords cannot be the same as the four previously used passwords.
Which go against the NIST guidelines. So how do you do things that are considered "best practices" when people like PCI require you to do them wrong?
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!).
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?
Luckily, there's out-of-the-box solutions that are easy to set up, e.g. Fail2ban.
Fail2ban scans your server logs, spots repeat login attempts, and sets up a temporary iptables ban on their IP.
Also anyone who swipes the server's DB would have an easier time cracking the hashes, even if you use bcrypt/scrypt.
And I can run the check in parallel. So if I have 1,000 email addresses I can find all the users with low-entropy passwords in just 6 hours.
[0] for example: http://www.the-interweb.com/serendipity/index.php?/archives/...
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.
yea, my thoughts exactly after i read it...
(See rules here: https://csdashlane.zendesk.com/hc/en-us/articles/202698981-I...)
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.
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.
Whew, thanks. I feel better now.
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.
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?
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.
Edit: misspelling, thanks for the warning!
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.
[1] https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...
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).
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.
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.
There's no better way to communicate this to your customers than complex password requirements.
Special brickbat for American Express who doesn't let you use special characters in passwords - screwing up my system.
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.
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.
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.
So yes, password rules are bullshit.
grrrrrr
[1] U2F, authorized devices, predictive phishing protections, etc.
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.
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.
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.
Edit: and if you speak German, there is a short film about passphrases: https://passphrasen.de/
The first rule for passwords, you don't talk about your password rules.
"Wouldnt it be better, the admins switched to better more learned users and dissolved the company to have the provlem get root."
https://arstechnica.com/business/2015/10/this-11-year-old-is...
So the system could basically fall back to being OTP?
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.
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.
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.
> 3rjs1la7qe
I wonder what these two mean.