a companion discussion area for blog.codinghorror.com

Password Rules Are Bullshit


#61

Hey Jeff, thanks for the reply (btw, it looks like the quoting feature ^ doesn’t pick up unordered lists).

The problem is that by setting these 4 rules (or even just the first “master rule”), you are telling me that you know what a good password is and that I should follow your rule, which has the added consequence of helping me avoid needing to learn “why” this is the case.

If I want to leave my wallet on the floor in a truck stop, then I should be allowed to. Any arguments in the spirit of “but, people don’t know about X…” can be addressed by education. And, the educational requirements don’t need to be addressed by website owners. When websites don’t purport to “solve” the problem, then proper sources of education emerge.


#62

I don’t think it’s any more vulnerable than brute forcing a normal password, but you’re right, if the attacker can reverse the hash and get at your master password, they could potentially use it to generate all your passwords.

What do you mean by no salt in this case? The salt is the website URL + username, which while not random, is unique per user. The salt in a normal password hash must also be known to anyone who has the hash in order to validate a password.

The advantage I see is that you no longer need to trust that each website you type your password into will keep it safe. I don’t know how Twitter stores their passwords, I have to assume they use best practice including salt, PBKDF2, etc, but at the end of the day they are still handling my unhashed password at some point, which could be leaked (heartbleed/cloudbleed) and used anywhere else if I used the same password. So, logically, I need to remember a different high-entropy password for each site I use, or use a password manager.

With these generated passwords, I can still use the same master password, but never reveal it to any third parties. It’s not possible to leak that password, so even if one site is compromised, it won’t affect my other logins, unless someone is able to brute force the master password. I still need a good high-entropy master password, but I only have to remember one.


#63

And that is exactly the case. They likely know better than “you” the normal user. You see, from the user’s point of view, a password is a wall they have to go through; most common users don’t associate passwords with “security”, they just think it’s something you need so other users can’t impersonate you.

Dare I saw most users are not aware of the dangers of simply using the same pwd everywhere. “Nothing ever happened to me, chances are they will pick someone else”.

Users need to be educated in these matters and the only way is through enforcing, otherwise people will not waste time “thinking about their password’s complexity”.


#64

Good password database practice is to use an expensive hash, however. Ideally, you’d want the hash to take a non-trivial amount of time. Exactly how long is up to debate, but there are been reasonable people suggesting between 125-500ms (or sometimes more) per hash. Doing that a few thousand times is a bit excessive.

Besides, you don’t need to do that if you are only looking at one previous password (the “password1”->“password2” scenario). You should know the current and proposed passwords from your password-change form. If you want to catch “similar to prior passwords”, plural, you’ll need to do your check against several stored prior passwords, which would require “a few thousand” hashes per number of stored passwords, at 8 hashes/second.

Personally, I like the idea of simply taking the MD5 of the proposed password and throwing it at an instance of John the Ripper or similar for 5 seconds. If it doesn’t get cracked, it’s good enough, and can be properly hashed and stored in the password database. If it does, report the reason why to the user (with a link explaining your process) and ask for another password.


#65

I agree that length/entropy is the key, but this could be accomplished client side with a bloom filter or similar to compress the dictionary to check if the password is one of the 100k most common passwords with high probability.

It would be possible to get false positives, but that’s not really a problem in this case.


#66

I agree with @codinghorror’s diagnosis, but not the solution. The fix is not to create better password rules it’s to get rid of passwords entirely. Password rules create a false choice between usability and security. We should not be forced to choose between the two.

The usability burdens of passwords are high. It’s difficult to:

  • Think up a new unique password that fits the rules for the site
  • Remember the password
  • Type the password in (especially on mobile and especially with multiple character sets)

As @kranzky wrote above, most sites have already created an alternative to passwords: the forgot password system. We already let you bypass the password if you have access to your email account. In that case, let’s get rid of the password and replace it with an emailed one-time use login link.

It doesn’t matter so much if the system that replaces passwords is slightly more inconvenient (like an emailed link) because people rarely have to use the system. I can’t remember the last time I entered my Facebook password. “Keep me logged in” allows us to use a more difficult system on the occasions when it is needed.

But, an emailed link isn’t the only alternative to passwords. Some others:

  • A numeric code texted to your cell phone
  • A numeric code read out to you via voice on a phone call
  • 3rd party login (Facebook, Twitter, Google, Amazon, GitHub, etc.)
  • A button on a push notification sent to your phone

Several of these have been implemented by Facebook’s great AccountKit system.

As this article showed creating password systems are really complicated. Especially when you consider the every changing best practices for storing passwords. In my opinion, this article would fall into the same category as an article on how to create a good sorting algorithm or how to create a good hashing algorithm: Interesting and important, but best left to experts. There are many great 3rd party password systems: Facebook’s AccountKit, Auth0, Stormpath, etc.

We live in a world where nearly every site uses passwords (something you know) and some allow/require a “2nd factor” of “something you have” (e.g. a phone, a token generator, etc.). This should be the opposite: “something you have” (e.g. exclusive access to your phone/email) should be the default and passwords should be an (optional) additional factor.


#68

https://blockstack.org/intro is trying to solve this as well


#69

Right. Stop relying on the digital world, and start relying on the real world. You could use the “world line” of a phone, you don’t even need to know the identity of the user, or tie it to anything else. If the user is standing at the end of the set of tracks they have been leaving, you have found them!

Godel said that no closed system can be authenticated (proven). So, stop relying on things within the closed digital system and touch the user. When people used Morse code on the radio (they still do), it was possible to recognize the unique way that someone you know sends code. (I have done this so I know from experience.) All we have to do is teach people Morse code, send a challenge text to their last known location and watch as they type it back in with a mouse button.

Oh, but we could not expect people to learn something new in order to gain security! Reading. Spelling. Typing. Using a mouse. Comprehending a web page… Why did we create a system that can do everything except what we need most - identify people? Because at some point the horizon expanded from “the computer you were sitting in front of” to “the world”. The built-in security provided by being physically located, has vanished. We need to put it back somehow. Watch them make motions that you request, smell them, listen to their voice, do something that proves who they are, in real time, in a way that cannot be replayed, made up, lost or stolen. And, within a sane distance of where they were last time.


#70

I agree with all of the individual points you make, but you’re missing the big picture here. 95% of the time when I find myself needing to make a password, it’s a site where I just want to register as quickly as possible so I can make an anonymous response. Like this!

I see that for “Discourse”, you need to provide an email address (but “mailinator.com” is blacklisted, requiring me to use one of their hundreds of aliases) and password. In essence, it’s kind of like a big captcha. You just need to make it painful enough for me to register that it’s not going to attract stupid Youtube-level comments.

The password rules are one piece of that test. Requiring an email address is another. Blacklisting “mailinator.com” is another: it blocks anyone who can’t be bothered to scroll down a screen on the Mailinator homepage.

StackOverflow used to make it really easy to get started: you didn’t need to provide an email address, or even register at all. If you wanted to ask a question or provide an answer, you just did it. There was nothing requiring a person to register, ever, and many of us used it that way. Then the site got too popular, I assume, and so they needed to add these captcha-like methods to make it harder for people to use.

The problem is similar to a captcha, but not exactly the same. A captcha tests if you’re a computer or not, as quickly as possible. What you want is a test to tell if the user is going to provide an intelligent and reasonable comment, and it does that by being as slow as possible (lots of steps). But if that test could be quick, life would be better for everyone. Imagine if StackOverflow could go back to not requiring registration, but still somehow keep the trolls out.

I have no idea how to do that, but that’s the dream. Until then, we’ve got “register + password rules + email confirmation + other junk”.

Maybe something like an Oauth-style authorization system that lets me re-use my “karma” from all sites I’ve ever commented on, but also keeps each one isolated from each other.


#71

Make the site available only to Mensa members. Or require that an existing user approve new users. Done.

Make it so that you have to build your own computer from raw parts to get in…

Hey, we could have sort-of this “island” and only let good people on to it… (Atlas Shrugged) (oh. right)


#72

What about biometrics? is the hardware barrier too high? is the security level too low?


#73

At this point, you’re basically using email as a poor man’s OAuth or other third-party identity provider. So maybe that should be the default?

I should say, this would be third-party identity providers that don’t get access to the rest of the application ("By logging in with Google, you authorize them to view a list of your most private fears and personal beliefs, and share them with some of their affiliates. You also agree to share your popcorn with Google at the movies.)


#74

The interesting thing is that we have already achieved a password-free system: when you sit in front of your laptop, with your copy of chrome open, it knows all your passwords.

Now we just need the it part to follow you around… Connect to your phone with Bluetooth or something? Embed a pacemaker-like thing in your body?


#75

the way out of this dark pit is simple: no passwords. (*)

the real solution looks like this: every connection between individuals and between individuals and groups is defined and defended with a keypair. if there is a connection, then there’s a keypair, on both sides of the connection.

everything you used to do with passwords for authentication and authorization is instead translated into verifiability and agreements cryptographically.

Then the only real issues become keeping your secret keys private (which may involve ONE set of personal passphrases or an access system for hiding/keeping private data for yourself or for your group), plus recovery in the case of key loss, and obviously key distribution. These problems are way easier to solve than passwords as they work currently, and they are all being solved now.

* well, maybe one password for your self or your group’s own private dataset


#76

The “master” rule I want users to learn is very simple: longer is better. (Within reason – obviously a 64 character password is brutal to enter on a smartphone.) Users intuitively know that bigger numbers are better in a lot of areas (salary, score, etc) so this is not a stretch nor is it difficult to understand why.

A bunch of weirdo rules like “must have a number, special char, uppercase” are just harmful distractions from the bedrock value of a reasonably long password.

If there must be a password at all, of course…

5 seconds is way too long … this would be a ddos waiting to happen. It should be no more than 100ms on the server hardware, per user, per login attempt.

No. You would be causing harm to not just yourself but the system and other users (who are affected by compromised accounts) with that approach. Don’t create an intentionally crappy password, just log in with Google, Twitter, Facebook, etc to avoid creating any password at all. Way safer and :100:% correct!


#77

Well how about this – Assign users their passwords?

So you create an account, and then it says: “OK, your password is: u82r6bz5pe2kxwqqnrbh


#78

Asimov was ahead of us all. He had a series of books, about a waiter and some diners (a regular group) that solved crimes. One crime involved a password. Basically think of a poem or song. Something thats important to you. Take the first letter of each word and bobs your uncle. Best of all screw up the quotes or lyrics as we humans are prone to do.

Wydilatntniya - REM, evrybody hurts…

Its not rocket science. Everybody carries a song in their hearts.

Think the books where the black widowers, or such. A good read if you can find them.


#80

I find it hard to believe the average Chinese person will ever choose the passwords “password”, “quertyuiop”, or “mynoob”.

Maybe not “password” or “mynoob”, but “qwertyuiop” is quite possible. They use QWERTY keyboards.


#81

‘don’t ask me to remember random sequences and I’m not gonna tell you where to go’


#82

What’s the problem anyway? They ask me for password, I smash over the keyboard and let Chrome cache it. Facebook-schmacebook, those social superlogins all reveal a bit of leaky data for their sick reasons.