How to manage passwords
Passwords are one of my favourite topics! There's so much you can do wrong when working with passwords. Here are some best practices on how to manage passwords.
I already wrote a blog article about password best practices (in German) a few years ago. Most of the information here can be found in that article in detail.
In this post, I will briefly cover the whys and hows of passwords and best practices, while also offering links to the infographics I created.
So why passwords?
Mainly to authenticate a user against a service or app. You give your secret, the app saves it (hopefully hashed and salted) and on each login, it will be checked.
This leads to three very important conclusions:
- Passwords should be hard to guess
- Passwords should be stored as salted hash so they can't be recovered within a reasonable amount of time
- The same password should not be used for different services multiple times
There are a few more to consider when developing an app using authentication. For that reason, I created an infographic for developers you can find in the following section.
Consider using the How to manage passwords in your application infographic's best practice advice.
Also, as a user, please read the How to securely manage passwords infographic.
Feel free to reach out to me if you have questions or disagree.
In a former version I concluded that it would be always best to set the minimum required length for passwords to at least 12 characters.
When I published these infographics someone pointed out this Microsoft research about passwords. After reading a bit more about different viewpoints I mostly agree with their conclusion that in many cases the password's length isn't that important as long as it's about 8 characters long.
This is for two reasons:
- Most password breaches are done via methods other than breaking passwords via bruteforce
- Some (too many) users might get confused by requiring a password longer than 8 chars (thus, for the same reasons as not requiring special characters, numbers and so on, the resulting password may be less secure)
This is why I changed the Infographics a bit to better reflect that fact recommending at least 8 characters for an application implementation now instead of 12.
Although, depending on the target audience (more tech-savvy), I think you can still go with 12 in some cases.
Alternatives or completive measures
There are three different methods for authentication that can be used in combination with each other for greater security:
- Something you have (like a keycard, FIDO, App, ...)
- Something you know (like a password, passphrase, also one-time passwords)
- Something you are (like fingerprints, iris, ...)
So we already got the password (something you know) covered. As an additional factor (2FA/mFA) you should add something you have like an Authenticator app on your mobile phone or a security stick like FIDO.
You could also add i.e. a fingerprint. Although, in my opinion, this is somewhat more delicate if it will be stored somewhere online. If there was a breach, hackers would be able to reverse engineer even irises.
Also, a fingerprint can be physically copied and used on your behalf. So with one breach all (or at least some) of your "haves" could be broken for authentication forever.
What are a good password's properties?
Aim for long passwords or passphrases. The longer the password the better the entropy. Special chars, numbers and upper/lowercase can help to improve the complexity and therefore entropy as well.
The most important trait of all: The password has to be unique to the current service. No cross-usage!
Also, the more random and the less obvious to guess (relatively easy to guess are words like password, date of birth or just repeating characters or words multiple times)
How can I improve my user's experience?
Aim for a seamless and easy experience while guiding the user on what passwords are safe and why they should be! Throw in 2FA to further increase account security.