Security is getting a lot of mind share these days. With high profile hacking events, Microsoft releasing what seem to be daily security patches, and constant media reminders that you're never secure when you're working on-line it's a wonder how web site creator ever gets anything done except handling security. Despite this attention to security often times there are no good guidelines for how to protect one of the most important pieces - the lynch pin of authentication - passwords. Passwords are often an under-protected area of security for a variety of reasons. In this article we'll expose common problems with the way that passwords are handled and protected and discuss how to improve the situation.
Why Password Protection is so Important
Passwords are the only mechanism that most sites utilize to confirm a person's identity. This supposedly secret bit of information is supposed to be known only by the user id's owner. If a user is aware of good practices they know that the administrator of a system can't be trusted and therefore the password that you use on one system or web site shouldn't match any of the other passwords that you use anywhere else. However, in practical terms, this doesn't work. There are just too many systems with too many passwords for a single person to ensure that they only use each of their passwords one time on one system.
Making matters worse is the accepted security guideline of periodically forcing a user to change their password. In some organization password changes occur between four and six times per year. If this were to happen on more than a system or two it's easy to exhaust a large supply of passwords in relatively short order.
As a result most users use the same password for multiple systems even though they know that they shouldn't. They just can't help but find some way to simplify their password needs. This means that the password that a user uses on your system can quite possibly be the same password that they use for their bank, mortgage lender, doctor, etc. The net effect is that losing a user's password from your system affects them substantially more than just the impact of access to your site.
To be a good Internet citizen you must provide more care for the passwords that users use at your system than the care that would be exercised if they were on someone else's site.
A Few Common Mistakes
When dealing with sensitive information like passwords it's easy to make an innocent mistake that can jeopardize the safety of this vital piece of information. Here are a few of the common mistakes that occur in applications everywhere.
- Assuming that SSL security is enough to protect passwords - SSL protects a password while it's being transmitted across the Internet but doesn't protect the password when it's stored on the local system. There are no silver bullets in security. Every place that something can be broken into will, eventually, be broken into.
- Encrypting the password with a reversible encryption - Just because you can't read someone's password at a casual glance doesn't mean that the password is secure. If someone is persistent enough to break into a system they're probably clever enough to use the same techniques that the web site does to reverse the password and dump the passwords out in clear text for use other places.
- Failure to recognize that HTTP-based authentication resubmits the password every time - Transmitting a password once in clear text over the network is a security no-no, however, sometimes it is nearly unavoidable. Because of this sometimes compromises are made to allow HTTP-based authentication. The problem with this thinking is that HTTP authentication passwords are sent on every request. So the password isn't sent along once or twice or a few times, it is retransmitted literally every time a request is made to the server. If you must use HTTP-based authentication SSL is a must for all transactions all the time.
- Sending the user their password in an email -- Emails are more akin to post cards than the letters that we all visualize when discussing email. The contents of an email are clearly readable to anyone watching the wire, just as a post card is clearly readable to anyone opening your mailbox. Sending a user's password to them in email exposes that password for possible use by someone at an arbitrary point in the future on your system or on other systems the user has the same password for.
Why You Don't Need the User's Password
In truth there is no good reason for the system to maintain the user's real password. All that the system needs is to be able to confirm that the password the user entered matched the one that they originally provided in their account. In other words, so long as you know that the password matches you don't need the actual password.
Because of this it is possible to store passwords as a one-way hash of what the user originally entered. Both the MD5 hash and SHA1 hash are suitable for hashing a user's password. When the user comes back to the system you can hash the information they provided with the same hash algorithm and compare the hashed values. If they match the user provided the correct password, if they don't match the user didn't get the correct password.
A hash is a mathematically valid compression of an arbitrarily long string of digits into a fixed size. By using a hash you also gain the advantage of allowing the user to have an arbitrarily long password. Instead of limiting them to 14 characters, 30 characters, or some other number of characters they can enter a password as long as they would like. Cryptologists and security experts know that passwords get substantially harder the longer they are so being able to accommodate large passwords can substantially improve security.
This same technique can be used for the so called "secret" question that some sites offer as a way of recovering a password. The answer can be hashed as well so that prying eyes can't harvest the user's favorite question/answer pair that might be useful to them on another site.
Of course, not having the user's password can cause problems if you are currently sending the user their password. Instead of sending the user their password you can use a forgotten password procedure that relies on similar technologies to create a key that they can use once to change their password.
Page 1 of 2