How do we secure your password you ask?

Actually, you didn't ask. But, we think you should have. Better yet, we think you shouldn't have to. Expect this information to migrate on to the main site. We feel as a holder of your account and personal information we have a responsibility to inform you on how we manage your password and personal information. We feel every website you interact with should do the same.

Found a fairly timely post on digg this morning regarding this topic -- You're Probably Storing Passwords Incorrectly. It's timely because I was planning on writing about this topic today. Glad to see other people are concerned about this. This is an interesting topic; most websites (even several of the more famous) do this wrong). Jay and I put a bit of thought into this upfront. We made a few conscious decisions regarding management of passwords and personal information we thought was best for the consumer. Namely:

1. We would not store passwords. Rather, we would store salted hashes. This brings up one minor inconvenience -- if you loose your password we generate you a new random one. We CANNOT recover your password. At the same time, outside of a brute force attack neither can someone who snags our customer database. We use a SHA-512 HASH along with a randomly generated 8 byte salt for each password stored. One thing we could improve is increasing the size of the salt.
   
2. We would not have a pre-canned set of security questions for password reminders or reset. We can't recover your password anyways. Instead we provide you a reminder -- you can put what you want there. Doesn't matter to us. Lot's of folks put a hint or the word 'standard' to indicate this is the one they normally use. One thing we feel strongly about is canned questions are inherently insecure and a reminder can be secure if you choose it to be.
3. We did not want to put password strength checks into the password requirements. Oh no! You guys don't care about my security! Actually, we do. Those that use good strong passwords will continue to use good strong passwords. Those that don't wont. Rather than force you to conform to a set of rules we think is good we let you choose. I think it is arrogant to assume someone who can't remember a complicated password will if you force them to for their own good. They will simply write it down somewhere! Now what did you achieve? This one is near and dear to my heart. I used to work as a sysadmin for the University of North Texas. I worked for this great old tinkerer named Jerry. Jerry maintained the servers and the computers for the Department of Engineering. One day I got the bright idea to put in a more secure admin password. Shortly I realized my mistake. Jerry was a smart guy, but, older and just couldn't remember the password I created so he wrote it down on a sticky. All I did was lower the security of the system!
4. When we start accepting orders we are going to provide you the option of storing your credit card information for quick checkout. When we do this, we will encrypt the information using your password to synthesize a key. This means that we will ask you for your password one more time before processing a speed order -- remember we don't have it! If our database is stolen then each credit card number stored must be brute forced. The difficulty of this act will depend on each user's password. Yes, this means if you reset your password we will discard the encrypted credit card information because it can no longer be recovered.

One weakness in our current system is that during password reset your new password is sent to your email. As we all know, depending on the route from us to your inbox that email may be read by snoopers along the way. There aren't many great solutions to this problem that do not incur lots of verification headaches for you and us. Again, we don't feel too terrible about this because if you did store any super sensitive information with us, it would have been destroyed by the password recovery. This is an area we will continue to think about and refine. Any suggestions out there are welcome.

We feel these choices provide a good compromise between securing your personal data and providing a good customer experience. We also feel that websites should be more forthcoming in how the manage and secure your accounts and personal information. Hiding this information only helps attacker and would be malfeasants.

What do you think of our choices?

Comments

[Tom Moertel]

It's good that you are thinking about security. Since you asked for comments, I have two.

First, use a hashing algorithm that was designed for hashing passwords (e.g., bcrypt). That way, you can make each hashing operation expensive enough to protect all but the most obvious passwords from guessing attacks, should your database fall into the wrong hands. (Remember, salt does not prevent the bad guys from attempting to guess your passwords; it only makes pre-computing hash-to-password dictionaries impractical, forcing attackers to guess each password individually.)

Second, don't use an account-recovery scheme that emails your users their passwords, even if the passwords are newly reset and random. Instead, send account-recovery tokens that your users can redeem to reset their passwords. If you reset the passwords and *then* email them, you open your user base to annoyance attacks: anybody can reset another user's account if he knows the associated login or email address. Also, if you email a new password to a user who choses to keep the password instead of changing it, that password will remain in his email records, accessible to anybody who shares (or can use) his computer.

See the following for one alternative to emailing passwords: http://blog.moertel.com/articles/2007/02/09/dont-let-password-recovery-keep-you-from-protecting-your-users

Cheers! --Tom

[Michael Webb]

Thanks for the feedback Tom. I read your post on password recovery. I had not really considered the annoyance attack. The approach you recommend eliminates that, very nice. We will definitely throw that on the stack for implementation.

I’m not familiar with bcrypt, but, I’m interested in researching it and considering its use for the reasons you cite above. Sounds like it will slow down a brute force attack in the case of the database getting snatched. Are you familiar with a good .NET implementation of the bcrypt algorithm?

Thanks,
Michael