There are still circumstances when SSL can't be used. It generally requires a dedicated IP address, as support for TLS Server Name Indication is not quite widespread enough, so it is not common on shared hosting platforms. Embedded applications, such as web management of a wireless router, may not have enough CPU power for responsive SSL. Packaged applications, such as a forum system, don't usually force the sys-admin who installs it to use SSL, so they may want to provide basic security when SSL is not used.
Implementing Hashed Passwords
I generally recommend using an authentication library, rather than implementing authentication yourself.
Most languages and frameworks have such a library. At present, few authentication libraries support JavaScipt hashing, only:
If you're involved in the development of a framework and would like to add this feature, do email me.
The instructions below describe in general terms how to implement an MD5 authentication system. They avoid referring to any specific server-side language, so apply equally to ASP.Net and Ruby on Rails. Some language-specific instructions are also available, from other sites:
- Session Cookie
- When the user does a successful login, the server issues a session cookie. This is effectively a random number that an attacker can't guess. The cookie is used to authorise subsequent access to protected pages. When the user does a logout, the cookie is deleted. This basic design is used by almost all web authentication systems.
- Challenge-Response Login
- Storing Passwords
- The server stores password hashes, instead of unencrypted passwords. A random number unique to the server is included in the hash. This number is called the "salt", and it is not secret. It is also included in a hidden field in the login form. The purpose of the server-specific salt is to ensure that a captured password cannot be used on a different server.
- Both login and storing passwords require hashes that include both the password, and a random number. We could simply hash the two strings concatenated. However, there is an alternative technique called HMAC, which uses two hash operations and some extra logic. This is specifically designed to be secure for such purposes, making it preferable to simple concatenation.
Some further technical considerations are discussed in the advanced section. more...
Adding MD5 to an Authentication System
- Store the server salt in global application configuration.
- Modify the login form:
- Add a hidden fields for: the server salt, the current server time, and the password hash
- Add a script tag to link to
pwhash.value = hex_hmac_sha1(hex_hmac_sha1(password.value,
password.value = "";
- Modify the handler that receives posted login data:
- Check the time stamp received from the client is within the last 5 minutes.
- Calculate hex_hmac_sha1(password stored on server, time stamp).
- If this matches the hash received from the client, the login is successful.
- Update registration and change password:
- Add a hidden field containing the server salt.
- Add a script tag to link to
password.value = hex_hmac_sha1(password.value, server_salt.value);
The following technical risks affect this system, as well as all the general risks that affect web applications. For most sites these are not particularly serious. In general, sites that require greater protection should use SSL, although strengthening the system is possible. more...
- Session ID is Unencrypted
- Although the password is always encrypted, the session ID is transmitted unencrypted. If an attacker captures this, they can perform a "session hijack" attack, to access the user's account. The same risk exists for sites that use SSL to protect the login process, but revert to non-SSL after the user has logged-in.
- Replay Attacks
- If an attacker captures a login, it is possible to re-use the password hash, until the timestamp expires. This is generally a minor issue, as an attacker who can capture the login can almost certainly capture the session ID. For web sites that store sessions in a database, this can be easily fixed. more...
- Active Interception
- Registration and Change Password
- Both registration and change password transmit a "password equivalent" over the Internet. If someone captures this, they can use it to login to the site. The unencrypted password is still never transmitted over the Internet.
- Brute Force Attacks
- In a "brute force" attack, an attacker tries many different passwords for a user, until they eventually succeed. The use of challenge-response login creates a new risk here. If an attacker captures a password hash, they can later conduct an offline brute force attack, where passwords are checked without accessing the server. This bypasses any server restrictions, such as locking an account after three incorrect passwords. Some simple steps can make this harder for an attacker. more...
- Stored Password Equivalents
- The hash the server stores is a "password equivalent". If someone captures this, they can use it to login to the site. However, the protection is still worthwhile, because its main purpose is to stop an attacker using captured passwords on different sites. If someone has captured a stored password from your database, they have already compromised your site.