Can we just relax our password policies a bit?
It’s time to pay the Superannuation for my company. I try to login to the AustralianSuper portal, but I’ve forgotten my password. After trying about 10 passwords, I get through, only to be told it’s time to change my password again.
This happens every time I pay the quarterly super. I’ve become accustomed to needing to remember lots of passwords, because it’s part of my job. But what does the average business owner do every time they’re asked to change their password?
They write it down.
They write it on a sticky note and stick it next to their computer. Or under their keyboard. Or worse, they have an Excel spreadsheet saved on their network with every password listed.
It’s not just AustralianSuper that are the culprit. It’s almost every large business that has an access restricted portal. Someone in their team thinks they need high-security, so they enforce a complex password policy. But the problem is by enforcing a complex password policy, they’re doing the opposite.
Enforcing highly complex passwords, or passwords that must change often results in lower security than if the policy didn’t exist. I’m not saying you should allow a simple password such as ‘dogs2016’, but don’t go overboard with restrictions. Because users will just write the password down, in an easy an obvious place that makes it simple for an attacker to gain access.
So what’s should we do? Well, we should still enforce a password policy — just not a ridiculous one. If you think passwords need to be changed regularly, try 6 or 12 months. Allow passwords that are 3 generations old because most people don’t have a huge collection of passwords they use like us IT guys/girls.
Rate-limiting login attempts is a good idea too. If your authentication endpoint allows unlimited, fast request times then it makes it easy for attackers to ‘brute-force’ attack this endpoint. Make it fast for the first three attempts, then progressively slow it down, until after say 20 unsuccessful attempts the requestor is blocked for a period of time. Don’t lock the user out, because if it is an attacker, they could potentially lock lots of users out. Otherwise, your support costs go up as time is spent unlocking accounts. If the authentication endpoint is on the web, try using IP address or cookies (or a combination of both) as identifying factors for blocking a requestor.
Create notification rules for when suspicious activity occurs. If a user is logging in all over the world in short time frames then their account has probably been compromised. Check logs and use a data visualisation tool to look for trends or any actionable data (such as one user logging in considerably more than the average).
Also, allow any character to be in a password. Some portals (banks, I’m looking at you), don’t allow certain characters to be part of a password. Why, I don’t know (probably because of their archaic systems), but it means a user’s usual password can’t be used, so they’re forced to modify it or create something new. Then it goes straight onto the sticky note.
In an ideal world, we wouldn’t have passwords. There’s so many more secure ways of protecting access and identity, but unfortunately, passwords are here to stay. So lets not go to unnecessary lengths to enforce ridiculously complex passwords when all we’re doing is shooting ourselves in the foot.