Password best practices @Future500

April 3rd, 2013

I've been building software for well over a decade now, and I'm absolutely guilty for breaking every rule below in the past.. but we've been adopting a more active approach to outlining our company beliefs, to live and breathe what we do every day. So here's our stance on password security:

• Don't use easy passwords
• Don't re-use passwords
• Don't build apps that allow weak passwords
• Use a strong hashing mechanism
• Don't think your development/testing area doesn't need security
• Share passwords with clients in a secure way
• And finally, use a password vault.

Read on for a little more background info on these points.

1. Don't use easy passwords

This is basic password stuff, meaning don't use personal information. Don't use full words that can be found in the dictionary. Don't use short passwords. Mix case and numeric and non-alfabetic characters. For most developers, and all developers that are any good, this is not news. But sometimes it's hard to live by the rules, and easy passwords make it into the application.

2. Don't re-use passwords

This is especially for things like database user accounts, server user accounts and such. It's easy to re-create the same username on all servers, or databases, and to use that one username/password combination for your own management purposes. But you'd be in trouble if you re-used a password at twitter and gmail, and your twitter password is compromised. And in the same way, multiple clients of yours would be compromised if the username/password for one project grants access to a totally different project.

Similarly, using variations on the same password tends to lead to password reuse. I used this technique for years, having a "prefix" and changing the last 3 or 4 characters of my password. I had a paper where I would write down a service, and my username+first-and-last-character of the password; which would allow me to know the variation without writing down my entire password. But, as time progressed, I changed my password for service A to a variation I had previously used on service B, and so on, untill there was definately some overlap. Just use a password vault and get it over with! (more on password vaults below).

3. Don't build apps that allow weak passwords

This point is a bit of a problem; because here's where your own strong views on security clash with the weak views of the general public. "They" hate password rules being enforced, "they" hate long passwords with characters and numers and all that complicated stuff. But make sure you don't trade off too much security for ease of use. You see, "they" also hate it when they accounts get hacked. Think about it.

4. Use a strong hashing mechanism

If you're storing plaintext password: stop developing software and go read a book*. If you're storing MD5 hashes, especially without salt, then your app needs an update. MD5 is not secure enough - and hasn't been for quite a while. Mainly because they can be calculated at huge speed and because of rainbow table projects... (rainbow tables are acually also a very good reason to use complex passwords since the chances that you're using a password identical to someone else's that has already been cracked are diminished).

*_disclaimer: I haven't read this particular book either but it just made my to-read list. There are a great many resources to be found on web application security, and specifically on storing passwords._

5. Don't think your development/testing area doesn't need security

All too often I've fallen into the trap of developing an app, creating an admin user, and setting a weak password because it's "just the development area". Because the development area turns into (or gets copied to) the staging area. And while (usually) it does not get copied to the production area, you're still online with an application, management rights and all, with a weak password. Just another unnecessary vector of attack; because perhaps real production usernames can be identified - or application structure or used packages can be deduced from within the application.

6. Share passwords with clients in a secure way

When your app reaches production levels, you need to start handing over the keys to your client. Remember that email is a plain-text and usually forever-remembered way of transfering information, so if whatever you're sending needs to be any kind of secure - don't email it. And while there are ways to encrypt messages (like PGP), it requires you to add 9 hours to the spec for "explaning how to decrypt the password file".

So here we're back to a tradeoff of secure versus practical, but perhaps you could: communicate it in a telephone call, send it by SMS to their mobile... If you must use email, try to send change-your-password links that can be used only once. That way you won't know the password either - and the email is useless once used.

7. Use a password vault

When using different passwords for every account and every user - it quickly becomes impossible to remember them. Especially without re-using passwords or having variations on the same theme. What you need at this point is a place where you can store passwords so won't have to remember them all, where you can copy them so you won't even have to type them manually. Some tool that can easily generate new random passwords, and allows you to save and retrieve in a simple way...

So start using a password vault. We have adopted 1Password as out vault of choice today, but there are others like lastpass or even the keychain app on Osx. Just google "password vault" for resulting articles like these.

Ramon de la Fuente

Pointy haired boss