Allow me to be the first one to argue that we should require that users use longer passwords. This is not much of a burden. Your password will last for a very long time, and it takes only a few minutes to memorize a long password.
If computing power doubles every 2 years, then every two years we should bump up the required password length to match. If each character is randomly chosen from amongst 2^6=64 possibilities, then every 6 years we add 1 to the number of characters required.
For instance, if today we require 12 character passwords, which are clearly uncrackable even with Amazon's fancy new GPU instances, then in 2016 we require everyone update their password to a minimum of 13 characters. Every six years we bump it up again.
I think people vastly underestimate their ability to memorize passwords (just think how many phone numbers you probably had memorized back in the day). You could probably memorize passwords thousands of characters long if you bothered, and the only problem is that it would take too long to type them in.
You only need one long password, and all others can be stored in an encrypted file. This is not much to ask.
Bcrypt and scrypt look great, but not fundamentally any better than longer passwords.
> Bcrypt and scrypt look great, but not fundamentally any better than longer passwords.
A technical-only solution is infinitely better than one where you try to change user behavior. You think memorizing a long password is easy because it's easy for you. Try telling that to someone who's 72 and just started using the Internet.
The reality is that anything that reduces friction to adoption is almost always a positive choice for any given company. There are exceptions, like banking, but for the most part, this is true.
This all ignores the fact that longer-length passwords are almost completely pointless, anyway, for a ton of reasons:
(1) The data you store on behalf of the user is probably not important enough to warrant the (very strong) inconvenience.
(2) Proper password storage ((b|s)crypt) can already mitigate a lot of these risks. If tuned properly, even a 4-character bcrypt password can become more computationally difficult to "reverse".
(3) Short passwords can be bruteforced over the wire? Well, you can prevent people from doing this. You control the environment and can make brute-forcing attacks against your login mechanisms unfeasible.
(4) For this to matter at all, some attacker has to steal the entire authentication table with all of the hashes. If that happens, the number of ways you're fucked is much larger than just your users having to change their passwords where re-used elsewhere.
Fundamentally, for most use cases, it should be a user's choice to opt to use a longer password that would be more difficult to crack, or use a shorter password for convenience.
Google already does this by showing a password strength bar when choosing a password. Unless you store very sensitive data, who are you to make that decision on their behalf?
A good long password - the first few words of your favorite catchphrase in lowercase with no punctuation. For example: "well thats the funniest thing". I'm not sure how strong it is, but it doesn't seem too bad.
Some UNIX geek once wrote a tutorial saying that good passwords have a random collection of uppercase, lowercase, and punctuation marks. It's too hard, so people just use "Pa$$worD".
Some do, some don't. I remember a digg survey a while back - a significant number responded that they had not upgraded because they felt no need to.
So just drop IE6 support - those people will soon wake up. But that has its own problems. If 10% of my users use IE6, and I drop support for it, that could have a significant effect on conversion rates and the like. Those people are going to do something else, maybe even go to a competitor.
The same applies to passwords. If, say, tumblr suddenly required 12 character passwords, then it would be quite a hit to their signup rates. This is simply not going to fly when there exists far less drastic measures (i.e. scrypt).
> How the hell are we going to get them to use longer passwords, and change them every year?
You merely require them to use longer passwords, and require them to change them every year. My university does this. They require a minimum of 8 characters, and they require that we change our password every 3 months or we can't log in.
If I had to come up with a new long password every three months I'd do what undoubtedly countless other people would do in the same situation: I'd write down my password somewhere nearby the computer so I could look it up when I needed it.
Overly onerous password requirements reach a point where they no longer increase security, they just shift vulnerability to a new area. They also piss off users.
That's avoided by not allowing more than three consecutive characters from the old password to be in the new password. It gets really annoying, trust me.
That would mean that they're storing the passwords themselves, hopefully encrypted, rather than just a salted slow hash of them. That makes me nervous. Should it?
you could have a form asking for the previous password and the new password... It then checks the previous password against the salted hash and then has the information to compare changes between the old password and new password without having to store anything
Regardless of the length, passwords are obsolete, at least when used in single factor systems. The biggest problem with authentication is identity assurance, an attribute that passwords simply don't possess. Better and more factors are necessary to provide true security in the future, and we're simply making due with passwords in the meanwhile. Phishing and Firesheep are ready examples of the weakness of passwords, and they're not even the easiest methods of compromise available. Passwords have a use, but so do other forms of security-by-obscurity, a category that passwords will inevitably fall into.
Payment Card Industry (PCI DSS 1.2) only requires 7 characters and some must be alphabetic while some must be numeric. So "soccer1" is a perfectly valid, PCI compliant password that will be cracked in less than a minute (offline or online).
Section 8.5.10 Passwords must be at least 7 characters long.
Section 8.5.11 Passwords must contain numeric and alphabetic characters.
If computing power doubles every 2 years, then every two years we should bump up the required password length to match. If each character is randomly chosen from amongst 2^6=64 possibilities, then every 6 years we add 1 to the number of characters required.
For instance, if today we require 12 character passwords, which are clearly uncrackable even with Amazon's fancy new GPU instances, then in 2016 we require everyone update their password to a minimum of 13 characters. Every six years we bump it up again.
I think people vastly underestimate their ability to memorize passwords (just think how many phone numbers you probably had memorized back in the day). You could probably memorize passwords thousands of characters long if you bothered, and the only problem is that it would take too long to type them in.
You only need one long password, and all others can be stored in an encrypted file. This is not much to ask.
Bcrypt and scrypt look great, but not fundamentally any better than longer passwords.