How to Design your Password Policy

A lot of material on security stresses the importance of complex passwords. Am surprised at how commonly we copy-paste this requirement across specifications, without giving much of a thought to the value it brings.

Several considerations have changed in recent years, which makes a conventional "complex" password of eight characters of letter, special character, number, caps etc. a pain for the user with no real benefit towards security.

For one, compute has become easy to scale and affordable with the advent of several cloud compute options or the FPGA custom rigs people build. We can focus on increasing the permutations with additional characters, but then length is a better bet for that than making the password hard to remember. This toon below from xkcd sums up that one pretty well.

It is possible to detect brute-force happening on a screen/API you own, hence it should really be an attacker who gets hold of a dump that you should be worried about. For those people, for reasons above, a complex password is not the answer. Use other methods like iterations, salts, MAC and such which makes it impossible in reasonable time to target your user-base. At best they can target few users, and that isn't your worry when someone got a dump. In short, it isn't complexity of password that will save you in this situation.

In a web scenario, on your screens, the common attack these days is account-match. This is by purchasing password data of a compromised site and then attempting it on your site. Simple attacks can be detected by tracking session/IP/fingerprint. Sophisticated attacks would need complex bot detection mechanisms. Again, a complex password isn't going to save you in any way here. What would save you in this case are mechanisms to detect repeat attempts on the same user, or repeat attempts on different users from the same origin.

One argument I've heard is that complex passwords will encourage users to not use their "usual" password, but haven't seen any studies backing this. It's quite likely that users will make a complex one their "usual" password. In my limited user interviews, the latter seems to be the case.

On the down side, complex passwords have several proven pitfalls. For one, sign-up percentage goes down significantly. This is proven by several studies we did on websites. Try to login, use forgot password, and then just discard the session is a common path - that is, a user just decided they'll shop elsewhere than deal with your password. People hate creating and maintaining that gibberish you insist as password.

Introduce a second factor (2FA, MFA) and make it simple to use (like a push notified prompt or QR scan or OTP) if the password itself isn't enough in some scenarios. Be sure to use this selectively on a need basis, by introducing "trust levels" for different activities. For example, a simple warm session via a "remember password" session from the past is enough for certain level of activities. When actions requiring a higher level of trust are required, hot authenticate with a password and/or other factors.

If establishing identity and preventing breach is important to you, invest on server side detection, prevention and mitigation measures as well. Invest on multi-factor that is easy to use. Ask for good passwords, but be reasonable. Ask yourself if you would like maintaining such passwords.