Can the world please standardize passwords?

One reason for no single standard is there is no single level of risk. The other is that standardizing password formats makes cracking passwords more standard.

[1]: Though, I did change the trivial password I was using before first posting the example here on HN

Good. Human-memorable is machine-crackable.

More seriously, there's work being done on this front, but specifically along the lines of eliminating passwords, because passwords are a terrible method of authentication.

See: FIDO Alliance https://fidoalliance.org/

Or my preferred item, the Yubikey: https://www.yubico.com/

In other words, a lot of your assumptions aren't necessarily correct (and there's competing interests. If I were writing a standard, I'd have all passwords be 20-characters minimum. However, that's not good for user experience)

http://stackoverflow.com/questions/15753279/password-validat...

It's not a standard that can fix this problem, it's education, both between end users and developers.

One could devise a system that allows any password as long as the entropy threshold is satisfied.

The only limitation to passwords should be a minimum level of entropy (or at least length, to keep things simple) furthered by taking into account character sets, lists, etc...

Some people prefer only digits, other like sentences, while some are used to the systems currently in place at the moment with multiple custom rules.

Food for thought.

My couple of password manager files encrypted and stored on Dropbox disagree with that one. (A couple of different ones because I like to segregate them by criticality. So I don't have to unlock the one with critical information most of the time. Reduces the attack surface.)

I can access them anywhere. Although I try not to access them on anything I don't have control over. For example: I memorize my dropbox password and my student login separately.

And it's a whole lot more secure to have a couple of long passphrases to unlock long generated passphrases for every site than to have a short password/passphrase for every site.

For today we are stuck with passwords. Maybe my beef would be diffused if some lazy programmers would be more open to longer passwords and more non-alpha characters. e.g. let the user decide how long the passwords needs to be beyond some reasonable minimum. Then allow any character the user can stuff in. i.e. don't tell the user the password conatins invalid characters.

Again, the average user is like my mom. Not like the people on HN. And you can memorize non-dictionary passwords...

Yeah, if I am projecting my screen in front of an audience of 300, I do not want my password echoed. But when I am using my mobile phone, getting feedback is far more useful than guarding against someone reading my screen.

Whatever method they are using, I would imagine that'll be the new standard. My passwords are decently secure, but that's hard to beat in terms of both workflow and security.

Here: http://en.wikipedia.org/wiki/Password_strength#NIST_Special_...

That formulate provides the only meaningful measure of a passwords strength: its entropy. NIST 800-63 is a (very conservative) formula for calculating it. Rules like "at least one numeric" are poor rules of thumb for the same thing.

That raises the question of "how much entropy do I need". That depends on how well guarded the password is. A four digit pin has an entropy of around 12 bits. By web standards it's an absurdly weak password, yet it has stood attacks for years. That's because it's guarded by a piece of hardware that only lets you have 3 guesses.

There are banks that only let me have a 6 character password - without upper case or special characters, which you apparently think is bad. But the bank is assuming they control the use of that password in the same way the pin is controlled. If that assumption is right it's a perfectly reasonable think to do.

The assumption is almost certainly wrong, but it probably doesn't matter. There has been a gang knocking over Russian banks by infiltrating their IT (ie hacking their infrastructure). If they've done that they also have access to the customers password data. But then it probably doesn't matter as the bank is hosed anyway. http://www.wsj.com/articles/new-report-says-computer-crimina...

The average web site isn't as secure as a bank. It has to assume the password database will leak. If it leaks the attacker gets unlimited tries at guessing each password, and number of guesses per second is limited purely by how much hardware they can afford. For example, if the password is protected by SHA256 + salt, spending US$30K lets you make 1 guess every 3 pico seconds. If want a password that can withstand such at attack for a year (ie, take a year on average to brute force), you need a password with 40 bits of entropy. Such a password will be around 60 characters long. However, if the web site puts some thought into how they store the password they can reduce it considerably: http://pbkdf2.sourceforge.net/ Sadly almost none do.

Lets tie this up. We've seen that a 12 bit password (a pin) can work well, yet a 20 character password stored on a regular web site will last around 10 seconds once the password database storing the password as a salted SHA256 hash leaks. These are wildly different numbers are not going to be easily encapsulated by the single standard you desire, mainly because difference between these two examples was _not_ how user chose them. It is in the way they are protected. That is where you should be focusing your efforts.

Besides, forcing users to change their behaviour doesn't work - they are far smarter than your "weak password detection" algorithms, and none of us like to be manipulated.