By BoLOBOOLNE payday loans

Standards for handling passwords

Every time we sign up for a new service on the net, we have to make a new account and pick a password to go with this account.  We’re going to be stuck like this until something like OpenID becomes dominant which is going to take years.  Until then we’re stuck remembering which password goes with which site, which is an age-old problem.  I think very few of us actually use a unique password for every account we have.  For sanity’s sake, we re-use passwords, or at least password themes.  Personally, a couple of times I’ve had throw-away passwords get used in so many places that I realize they are actually now quite important because they grant access to many services.  Some of these services seemed stupid at first so I created an account with a throw-away password and then they became important to me later.

The problem that’s bothering me today is that I have no idea what the new site is going to do with the password I give it.  Few things irk me more than seeing one of my good passwords sent to me in plain-text, say in a password reminder mail.  Why are you storing my password in plaintext!?  Some of my most valuable passwords I’ve never even seen written out, and the first time I do see them say in a username field it’s a little surprising and I feel like they’re a bit compromised.

I’d like to see sites post their password handling policies.  I’m going to start doing this on my own sites.  Here are some examples of levels of security to consider:

  • Your password is stored in plaintext
    • Forgotten passwords will be emailed to you in plaintext
  • Your password is stored using a one-way cryptographic hash form
    • Forgotten passwords cannot be recovered.  If you forget your
      password you will have to create a new password after we verify your
    • using MD5 (not considered very strong cryptographically anymore)
    • using SHA1 (better)
  • Your password is stored using a strong hash with a salt
    • Without a salt, somebody looking through the password database could see that two users have the same password since they hash to the same value.  Obtaining one password thus grants access to the other account.
  • Your password is never transmitted or stored in the clear. 
    • All auth events happen over SSL
    • Your password will not appear in any server logs.  (Rails devs take note.)
  • Your password is never stored in any form in a browser cookie.
    • Some sites might see it fitting to store a hashed password in a cookie for re-auth.  Ugh.

Responsible sites will follow the last three rules.  We could come up with a simplified grading system that explains in simple terms whether you can use a valuable password here or not.  We know we can trust the smart folks to do that.  But with so many features being launched as stand-alone sites, understanding these policies is important.

Comments are closed.