Passwords suck. It is a universally accepted truth. But in the absence of anything better, we’re stuck with them. This article is intended to help instruct website/SaaS/app developers and users on how to help make the whole thing suck a little less.
Creating passwords – for users
This has been done to death. Avoid sexy1 and password123 and g0dl1k3 and trustno1 and l3tm31n and correct horse battery stapler and all the cliche overused passwords that appear on the top 100 lists. Practically speaking, hackers have access to wonderfully powerful GPU based crackers and large password rainbow tables and anything that has been stored poorly, or isn’t long and complex, will be cracked quickly. Letter substitutions or adding numbers to the end of your favourite word or doggo’s name are just options on their crackers, so don’t expect that to help.
Password managers are your friend, but also have inherent risks. More on that below.
Registering users – for developers
If you collect and store the toxic waste known as personal information (fool!) then you’re probably going to want to make sure the data you’re entrusted with is secure. So, you’re going to ask your users to create usernames and passwords to protect them. Some of you will enforce strong password standards to ensure they aren’t using stupid passwords. Here are your biggest mistakes:
Really dumb-ass poor validation javascript
The user has decided to user a password manager that autogenerates and stores 60 mixed upper and lowercase characters with numbers and special characters (bonus points for using non-ASCII characters!). Your javascript barfs after 24 characters of input and tells them their password complexity is too low. This just makes them curse and hate you.
UX testing
UX testing isn’t just about which shade of blue makes your users buy more cool graphic tees. Assume 10% of your smartest, hippest, beardiest or purple-hairiest users are going to use password managers. UX test them to make sure they don’t barf on your website. If you like your users. If you hate them, continue to mislabel your username and password fields and don’t check for password manager interoperability. They’ll find somewhere else to buy tshirts with cute cats riding sharks on them.
Storing the passwords
Congratulations! You’ve managed to twist your user’s arms into creating a complex password. And then you write it to disk in clear text. Seriously? I know you slept through the security part of your coding class, but at this point if you’ve made this mistake it’s unforgivable. And no, using a MD5 or ROT13 hash is not an improvement, it’s like pulling your seatbelt over your shoulder but not clicking it into the harness. Only the illusion of security.
You need to salt and hash your password stores. If you use a common salt then you’ve just made it easier for the hackers to reverse the password once they own your infrastructure, which they will do. Count on it.
Finally, don’t write your own algorithm to do this. You will screw it up. Yes, the broadly available hashing algorithms like Argon2, bcrypt, scrypt, or PBKDF2 will likely have weaknesses found in them 5 years from now. Yours will be hacked by a 14 year-old in 15 minutes. Cryptography is hard, don’t do it alone.
Storing the passwords
What? You thought that was it? Your password file is secure. But some dork in your web analytics department decided they needed to instrument every keystroke your user put into your web app, and as a result have been storing passwords cleartext in your log files. Stop it! Bad marketing manager!
Multi-Factor Authentication
Multi-factor is NOT ‘something you know and something else you know’. A password and a secret question is not more secure, it is just annoying to your users. If you’re going to implement secret questions instead of real grown-up multi-factor authentication, at least let them define their own question/answer pairs. Because even I know your mother’s maiden name, the street you grew up on and the name of your first pet.
Multi-Factor Authentication – SMS notifications
Note that SMS notifications, while a decently supported and wide-spread technology, are not terribly secure. Smart 13-year olds have done everything from buying up old Nokia phones that allow hacking of the IMEI and cloning inbound SMS messages to social engineering your telco’s customer helpdesk to register your phone to them to compromise your twitter account. It will happen to you if you implement SMS. What will you do then?
Multi-Factor Authentication – Email Validation
Email validation is cool. What could be easier than requiring a user to click a link to validate an account, or a login attempt. Sending email alerts when people login to accounts from new computers is a decent security measure. But, you need to assume that some small portion of your users (25%) used the same password on their email account, which is also their username for your accounts. So the hacker got a twofer, and now can easily delete those wonderful notification messages you keep sending.
Multi-Factor Authentication – Step Up Authentication
A good practice rather than annoying your users by requiring them to go through 26 steps every time they log into your service is to require multiple authentication steps when they come from a new device or IP address. Is this perfect? No. Is it less annoying to your users? Yes. Annoying your users will just make them revert to the lowest common denominator.
Brute force attacks/User harvesting
Script kiddies are called that because they like to download and occasionally write scripts. Scripts that do things like test a zillion username/password combinations on your website. Because you didn’t do anything to stop that.
Or maybe you have set a threshold? Or one of those captcha’s that require them to use a cheap botnet to attack your website authentication. Start by assuming that they will attempt to harvest usernames/passwords from your front door. If your website spits out useful error messages like “unknown user” or “incorrect password” then you’ve made it even easier for them – they now know if they’ve got a legitimate user name.
Password recovery techniques
Your users forget their passwords. For a variety of reasons. They’re humans, not computers (unless your users are a Russian Troll Farm, in which case they are 15 people in front of 10,000 computer controlled accounts). So, you need them to recover their passwords. Are we going back to secret questions? Mother’s maiden name? Social Security Number (that’ll be $5 on the dark web, please). Having a weak recovery mechanism is like putting a deadbolt in your front door and leaving the side window wide open with a ladder conveniently perched below.
As a user, if the website sends you back your password in cleartext when you click the “I forgot my password” link, know that they are storing it in an easily reversible format and can’t be trusted with your data. Not your credit card, not your mother’s maiden name, not the name of your first pet Fluffy. If they can’t store passwords properly they can’t do much of anything right.
OAuth/Google/FaceBook/Twitter pass-through authentication
By now you’re probably just thinking – this password thing is hard, I’ll just let my users sign in using their Google/FaceBook/Twitter credentials. That’s a choice. Sort of like letting a 8-year old ‘secure’ your Halloween candy choice (just ask the people over at Tinder how they feel about having Facebook as their signin credential now that Facebook is in the dating game). Sometime in the future they’ll get hangry and your candy will be theirs. But for most organizations, not creating usernames and passwords at all is a perfectly reasonable way to go. You can’t lose it if you don’t have it, right? Google and others have robust account protection schemes – some of them are used to fending off attacks from nation states. You’re going to have a hard time matching their development team’s expertise, and they’ve got a lot of tuition value out of a million hackers trying to break into gmail/etc.
Password rotation
Don’t do this unless you know/strongly suspect your password database has been stolen – if your password database has been compromised or your users phished. Actually, if you’ve followed proper password database security mechanisms then even if your database is compromised the need to rotate is significantly lowered. Password rotation times of 30/90 days are archaic throwbacks to inherent flaws in ancient versions of the NTLM security model and a no longer relevant. All you’ve done is ensured your helpdesk will be forced to deal with more password recovery calls and made them more vulnerable to social engineering.
Password Managers – for users and developers
Password managers are great, except. Hackers know we have them, so they infect the users’ computer and slurp up all their passwords out of the unlocked password manager. What’s your mechanism to defend against that (multi-factor, anyone?). If you’re a user, make sure your critical accounts (email, socials, banks (we wish!)) are also locked down with multi-factor. If you’re a developer, count on your users’ accounts being compromised because their machines have been compromised, or because they’ve used the same username/password combination in 37 other places, and figure out strategies to deal with this (user behavioural analysis is a useful tool!).
Secrets – for users
Assume your identity has been compromised. That someone (Cambridge Analytica) out there has a portfolio of your mother’s maiden name, your birthday, your dog’s name, your favourite flavour of ice cream, etc.
It turns out you don’t have to tell the truth when being asked to provide answers to secrets for websites. You can create a second, false persona with a different birthdate, you can put in a random string of digits for your favourite movie (I really loved Jennifer Lawrence in %[email protected]), or your favourite colour can be a country. It doesn’t matter, because humans don’t look at this stuff. So do something different, so that if your real world identity is compromised your online identity isn’t as well.
Other considerations
Start with the assumption your account database will be compromised. What then? What’s your incident response plan? Write the press release now. What will you tell people about how you stored passwords (salted, hashed or plaintext?). Send your press release to your favourite security friend – if they facepalm, you have work to do. If they shrug and go “ok, it’s not great but no big deal”, you know you’re on the right track.
Do you do other things – user behavioural analysis, device fingerprinting, email/text notifications. georestrictions, brute force thresholding – to reduce the risk of a password compromise leading to an account compromise?
Assume that attackers will try to harvest users from the authentication page, that they’ll social engineer your help desk and work your password recovery mechanisms to try to bypass your security. Assume they’ll harvest user data from other sites (first four/last four digits of a credit card number) in order to have the necessary info to social your help desk. Now, do a bunch of tests yourself and see how effective they are. Did you get in? Keep working.
For users, assume that your credentials will be compromised. Your email password stolen. Your bank credentials compromised. Your password vault dumped. How big of a deal is that? Are there other controls you can put in place to reduce your risk (multi-factor authentication, limits on account transfers with the bank, etc)?
Passwords suck, choosing good ones is hard, keeping them safe is harder. But, for the time being, they’re what we’re stuck with. So, do your best to secure them.
