Here’s How to Salt Your Own Passwords and Prevent a LinkedIN Style Password Problem

With all of the publicity surrounding LinkedIN, League of Legends, and possibly others, I thought I’d take a moment to explain how I manage passwords.  Yes, I quickly changed my password on LinkedIN, but using this method will add you just a bit more security if and when a provider screws up.  Remember, not every security incident involves a massive “post to everyone’s wall and make the evening news” style announcement!

I started this method after a screwup at Reddit a long time ago, which back in the day was storing plaintext passwords, and leaked them.  It has worked extremely well over the last six or so years.  For those who are unfamiliar with salting – it’s a method to increase randomness of passwords, and prevent rainbow attacks against password databases.  Technical readers may point out some more particulars about that statement, but the general statement should hold true.

Websites and other authenticators are supposed to salt passwords, but they can forget.  You can salt your own passwords by providing a hard to remember base password, then add some random characters to the beginning, after a fixed position, or end of the password.  This will make deriving your password more difficult, and will prevent (quick) account theft by an attacker taking your email and password and trying it at well known sites.

  1. Choose a decent password.  I recommend that people choose a nursery rhyme, favorite quote, saying, bit of religious text, or any kind of phrasing and choose the first letter or second letter of each word from that phrase.  This usually gets them a reasonably strong, easy to remember base password.  Capitalize a few of the letters and add a number at the beginning or end.
  2. Develop a salting mechanism. For every website that needs a password, develop a salting mechanism.  Have two rules of thumb as to how you derive a few additional characters based on the site itself.  Try to choose something relatively non-volatile.  For example – use the first four letters of the company’s name as it appears on their logo.  Or the last three letters of their domain name.  Or something else that may not change very often.  Then add these letters to your passphrase above at the beginning, middle or end of the phrase.  Why two rules?  So if your first rule doesn’t work due to some password scheme restrictions, you can use the second.
  3. You’re done. You now have an easy to remember passphrase that’s unique to that site (your base password + your derived salt).  Best of all, your password looks fairly random and even if your password from another site was stolen, it wouldn’t be susceptible to rainbow attacks, etc.

A few benefits of this approach:

  • You don’t need to rely on a “last pass” type application or system that stores all your passwords on a computer which may be hard to access sometimes.
  • It’s easy!
  • It’s free!
  • It really works – I’ve never had a problem with this, even with some of those sites that have weird password rules.
  • You now have a unique password to every system you access.
  • You can change the base password every year if you’d like, for even better security, and to weed out those accounts you forget about / never use.

There are no silver bullets to any of this.  Yes, this can still be attacked, but it’s certainly better than the “same password everywhere” or the “secure password for sites I care about and insecure one everywhere else” method.

I highly recommend you turn on Gmail’s 2 Factor security setting on your email account as well.  Particularly now that they’ve released an “offline” authenticator token generator which doesn’t need network access to work.

Stay safe out there!

Some Thoughts on Two Factor Security

Awhile ago I wrote an Open Letter to Mint.com laying out some major concerns I have with their service and their security implementation.  Almost all comments both here and on Hacker News and Reddit were divided into three categories:

  • From non-Americans: How is a service like Mint.com even possible or legal? US Banks don’t have two factor security?
  • I totally agree that Mint.com and their service is insecure and I don’t use them!
  • I agree that Mint.com needs better security, but their service is great and anyway, it would be too time consuming/too expensive/too hard/too impractical to implement these security improvements.

Between the time I wrote that letter and now, we’ve seen RSA (the only major token based two factor security provider) have all of its hardware tokens compromised to much public uproar. At Sentry Data Systems, we’ve had two factor security implemented for years using time based cookies and additional security questions to challenge users when they were logging in from a device that hadn’t been previously authorized.  This is similar to how many banks in the US do two factor security if they choose to implement it.  While not a HIPAA requirement, we felt that it was a great feature to offer that provided an additional layer of protection.  We’d originally offered RSA SecurID tokens to customers but found that most customers balked at the price, and even if they did use the tokens, many would simply tape it to their computer monitor or keyboard, or they’d forget the token at home which would cause quite the contentious support call. This experience brought to the forefront several issues that I had with hardware based tokens:

  • Casual users or those who didn’t value the two factor security benefit would simply leave the token lying around or affix it somewhere – it wasn’t natural to expect a user to carry one more thing with them day-to-day.
  • If there was a compromise, you have to replace all of your hardware, for everyone, everywhere.
  • They were expensive.
  • They were highly recognizable and screamed to informed observers that you had access to a system that was considered high-value by someone.

I even went so far as to start sketching out an iPhone app that we could deploy for our customers but it seemed like quite a lift to do it well (a correct implementation is key in cryptography systems) and it was with much delight that I ran across an outfit called DuoSecurity based in Michigan. They have really put together a fantastic service that provides both SMS based (challenge/response) and one-time password (via an iPhone or Android app) options for two factor security.  I signed up for the service, installed their package on my Ubuntu Linux server, and within about 15 minutes, I had a very strong two factor solution that avoids all the drawbacks of the hardware token approach…for free.  Yes – they provide up to 10 users for free to let you get your feet wet and see how the system works.  With the token being my phone, I’m not going to forget it, it doesn’t draw attention to itself, I can’t tape it to my workstation, and they can update the software if they need to. If their service goes down, you can configure it to not require the second factor (the default) or you can choose to prevent logins and keep a private key around for last-ditch logins.  Of course, for those of us running cloud based servers, there is still the risk that your hosting account could get compromised giving an attacker shell based access to the machine – hopefully Slicehost and other services will implement this type of additional security soon (Amazon’s EC2 cloud already implements two factor security as an option). Duosecurity can be easily implemented with any web application, a lot of VPNs, and on your Unix/Linux servers quickly and easily.  If you’re doing anything with medical, financial, or other sensitive data you should definitely check them out.  If you just like additional protection for your own servers and services, they’re a great option as well.  Just in case you’re curious: Duosecurity put up a great blog post about the steps they’ve taken to prevent compromise if they came under the same attack as RSA. A few thoughts on improvement:

  • Give me an apt package please!  I don’t want to compile things, and I don’t want to edit configuration files.  These things make it hard to deploy on lots of servers.  I talked with a support rep from Duosecurity and they told me this is in the works already.
  • Put a login form on your website!  They email the login URL to you but I shouldn’t have to remember it.
  • It’s a little unclear to me if the pricing scales well- if I’ve got the same 35 users access 100 machines, does that mean I pay 35x100x$3?  That seems expensive.  Course, it’s still way cheaper than RSA but at least you could bind an account to a token and not worry how many servers you were accessing.  It’s possible that a single user crosses the server boundary, but again, I’m unclear on that.

Bringing it all back to the original point – there is simply no excuse why a service like Mint.com doesn’t use Duosecurity to protect its own user’s logins.  But the second issue still exists – how do banks provide consumers of financial data access without compromising the entire account? A poor man’s solution of sorts could be taken by banks providing read-only accounts for customers that use generated, revokable passwords.  Google takes this approach with its own two factor implementation for Gmail.  You get texted when logging in normally, but for other applications, you generate a password that can be revoked at any point.  It seems like a decent compromise – you can’t control the account from that login, and the password is of sufficient length and complexity that it’s unlikely to be brute forced.  My initial suggestion of using Oauth is essentially the same thing. Congratulations to the guys/gals at Duo Security on providing a really great set of tools for developers and users.  I really hope it catches on and more and more providers begin offering two factor as an option.