Password ponderings
Long passwords are more secure than short ones, but if they are too long people write them down, so find the happy medium.
Bad advice
Give passwords as short an expiration as the users will accept. The more frequently they are changed, the better. That is really the only defense against password leaks.
Bad advice
If the password does not contain both uppercase and lowercase letters, and special characters, it is too easy to guess.
Bad advice
I have looked at password security for more than ten years, and I blinded myself staring at that type of advice.
How long should they be, those passwords? Can we base the number on research instead of imitating what others do? Et cetera, et cetera.
It is easy to get caught up in the logic around those advices. It is not that the they are wrong. They are really not. But their relevance has just eroded away.
Heres the thing: We humans have a limited bandwidth when we prove our identity.
Because we want our authentication to be both fast and repeatable, it is limited how many data we can generate. That means that the set of all the possible data is relatively small. So small that a computer fairly easily can break a human password by using brute force with some optimizations.
By breaking the password I mean to break the encryption or hashing of the password.
You should never save an unencrypted password, but instead a hash of the password. A password check is then done by hashing it and comparing it to its saved hash. Hashing like this is done by a cryptographically strong hash function. Just a fancy name for a one-way function.
The problem is that it is feasible with the computing power, that is within reach of most people, to basically test out all possible passwords, and that way "invert" the one-way function.
There is a nice trick to avoid this kind of inverting. Use a computationally heavy hash function. A simple hash function like a modern SHA, is lightingly fast to compute. But if your hash function is this SHA iterated 100,000 times, then the computation power required is noticeable, and brute-forcing becomes non-trivial. Unfortunately it also affects yourself, so this is only used in setups where it is the users own device that do the hashing. It is only used for password-protected documents as far as I know.
There are more tricks. They are less compelling. You can pull one bad trick after another up of your hat, but it is a loosing battle. The scale of the task plus the computing power available equals a defacto inverse function for password hashes.
The basic problem is the small set of data that we can generate, as mentioned above. When I realized that, I saw what should have been clear all along.
Passwords are shared secrets.
The best security comes from sharing them with as few as possible. Of course, as everyone knows, with so few people as possible. But also, what every security architect should take note of, with so few machines as possible.
Ideally the only machine that sees your password should be the one you use to enter it.
Minimize password spread.
Use this as your guideline when you design or purchase solutions. Then you will avoid a lot of attack vectors.
Note by the way, that solutions designed this way inherently solve many of the issues that the classical password advices are about. If you nevertheless set up enforcements in line with the classical password advices, it actually can hurt the security. Because you get the disadvantages without getting the advantages.
