- One of the sites is compromised
- One of your devices is stolen/lost and you have to change some passwords
- One of the sites has a password expiration policy
Pretty soon you end up with multiple password schemes and you're in precisely the same situation as before, wondering which password goes with which site, only this time you have to perform algorithmic dances in addition to memory feats.
• Passwords that prevent double characters within the password: not ideal when using a scheme.
• Passwords with a minimum/maximum length: I've seen sites with a minimum of six characters and other sites with a maximum of eight characters. That means, to cover them all, you really have to choose a password of exactly six, seven or eight characters and even then it's no guarantee.
• Sites that prevent certain punctuation and other sites that require punctuation. That means you have to remember which sites require which.
• Likewise, sites that require/prohibit capital letters or require a mix of case.
It's a nightmare doing anything other than recording them somewhere. And recording them somewhere is not great either as you always have to carry that thing with you and, if it's electronic, remember to charge it.
The concept of illegal characters is tied for second. If you're handling it right, there should be no such thing - yet so many sites continue to set arbitrary limitations for reasons that aren't clear even to them.
Kind of wish I could just generate private keys for each site and not think about it anymore. (Yes, I know there are some convoluted ways to do this, but they're not particularly usable.)
THe best part is that even so many new and/or modern sites enforce the same arbitrary requirements.
To add insult to injury, when I tried to tell the gentleman on the line what an egregious security lapse this was, he cut me off with a terrifying and patronizing explanation: "strong passwords don't matter anymore, because nowadays we have _encryption_".
American Express, get fucking real.
Also, chances are users will not type their 10MB password into an input field, but try and paste it in. Again, the browser may silently discard a few MB of that string, or beep while you have your sound muted.
That's no reason to set max length at something small, but setting it to 1024 or so shouldn't limit anybody as long as it allows for more entropy in the plaintext password than will be in the hash you store.
This one really grinds my gears because it also indicates that they're most likely storing your password in the clear. Hashes are all the same length.
A major financial company does this, of all the terrible places.
The alternative is that they're smart enough to come up with a clever scheme like hashing your password in both its raw form and when converted to 0-9, but not smart enough to realize how converting your password to 0-9 makes it vastly less secure.
1. Your password is required online where the full password must be entered and the numerically reduced password is not accepted. This results in no loss of difficulty in the password.
2. Your password is required over the phone where the password is reduced to a T9 password. Despite the fact that the solution space has been cut down significantly (by 33%^n), the password cannot be broken any quicker because the bottleneck for this case is not computational power but rather the phone system. You can brute force all of the passwords in X seconds, but this is irrelevant because you can't try more than 1 password per call and you can't call more than Y times per second.
In the universe of banking this is pretty small potatoes, though. My bank uses a case insensitive comparison for passwords (!), limits them to 8 characters (!!), and silently truncates anything over the limit (!!!!!!!!!!!!!!!!!!!!!!!!!!).
They say they're fixing it. But it sure is taking a long time.
There are 3 'tricks':
1. First, use several different initial functions for different levels of security, each with different levels of complexity (i.e. f1(user,domain), f2(user,domain), etc).
2. Then, use a function for password requirement rules (i.e. g(f(user,domain),rules)).
3. Finally, use a final function for rotating passwords (i.e. h(g(f(user,domain),rules),rotation)).
So, all together, maybe 5 different algorithms, each of different levels of complexity.
You'd think that this would be very difficult to manage, but it hasn't been in practice. Very, very few times do I pick the wrong initial algorithm when trying to derive my password. And, in that case, I can quickly iterate to the correct password within 3-4 tries.
Most of the time I get it on the first try. Sometimes, I get it on the 2nd-3rd try. Very, very rarely (< 1%), I cannot derive it within 5 tries. And, at that point, I just do a password reset (and rotate the password using the h function).