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.
Forgotten Passwords
Rather than transmitting a password back to the user via email, it is possible to transmit a key that will allow the reader to change their password via a special page. Transmitting a key rather than their password is better because it doesn’t expose a password that they potentially use at other sites and also because this key can be setup such that it is only usable one time. This would prevent a hacker from recording the information and using it at a later time.
Creating a forgotten password key is relatively simple. First, the user’s object is “touched” so that some date is changed by the mere practice of sending the forgotten password. Ideally, another property in the user’s object will be present which changes every time that the user logs into the system. The user object is then serialized and then hashed using an algorithm like the ones above. This will create a unique key every time the user indicates that they forgot their password because the mere fact that they requested it causes the data to change which in turn causes the hash to change.
Occasionally, there is some concern about the length of the resulting hash. It is technically possible to truncate the length of the hash to an acceptable level for entry and comparison purposes. However, the shorter the hash the less protective the whole process becomes. In practice a 32 bit or 8 hexadecimal digit hash is minimally acceptable if a limit to the number of attempts at the forgotten password page is established.
It’s important to realize that when they do set their password they will be changing the data in the user record of both the password itself and the last updated time. This will automatically invalidate the key that they received making it useless to an attacker for replay or reuse.
By utilizing hashes for password resets it’s possible to create a solution which most importantly doesn’t give away the user’s password but also prevents a third party from replaying or reusing the same key to gain access to the user’s account.
Expiration Dates
It’s generally accepted that security account passwords become known over time. One of the established ways used to minimize the impact of this it to cause accounts to change their password on a periodic basis. One of the easiest ways to accomplish this is to set in the record a password expiration date when the password is set. During the logon process it is possible to check the expiration date and redirect the user to change their password if their password is expired.
For accounts that are created for others the password expiration is set to yesterday on creation so that the user is forced to change their password the first time that they log in. Alternatively, the last password set date can be set to a date and a system policy set for how many days can elapse between password change events. In either case it is possible to create accounts with passwords that expire based on business rules as well as accounts whose passwords never expire.
Protecting from an End-Around
A final note on protecting passwords is that sometimes it’s necessary to protect the account creation process. If the passwords are appropriately protected but the new account creation process is fairly lax it is possible that malicious parties will try to do a complete end-around the user account/password process by setting up bogus accounts and trying to use them to gain access to the system. When creating a system that protects passwords it’s important to consider what validation is done to the account when it is created.
A similar mechanism to the forgotten password mechanism can be used to force a user to validate their account. A hash of important account information is emailed to the account. The user must return to the web site with this information in order for their account to be fully activated. This process can be adapted with an account expiration date that allows a user to use an account for a few days before being forced to authenticate the account. This will minimize the protective effect of requiring activation; however, it will allow users who don’t have immediate access to their email to gain short-term access to the system. This technique is also useful with situations where a printed correspondence must be mailed to the user rather than the user receiving an email.
About the Author
Robert Bogue, MCSE (NT4/W2K), MCSA, A+, Network+, Server+, I-Net+, IT Project+, E-Biz+, CDIA+ has contributed to more than 100 book projects and numerous other publishing projects. He writes on topics from networking and certification to Microsoft applications and business needs. Robert is a strategic consultant for Crowe Chizek in Indianapolis. Some of Robert’s more recent books are Mobilize Yourself!: The Microsoft Guide to Mobile Technology, Server+ Training Kit, and MCSA Training Guide (70-218): Managing a Windows 2000 Network. You can reach Robert at Robert.Bogue@CroweChizek.com.
