In support of Cyber Security Awareness Month
, this article is written as a tutorial on basic login security, including techniques to defend against potential vulnerabilities. I encourage anyone with a software security background to comment on this article. Although I have some years of software security experience, peer review is essential for building secure systems.
TIP: Any and all security techniques (including these) should be considered experimental until thoroughly reviewed by the security community.
The most common form of login
(gaining access to a system) involves transmitting a username-password pair (the user's credentials
) to a server for authentication
(confidence in the user's identity) and authorization
(right to access said system). This article describes techniques used by the Potential RPG platform to improve login security, but the approach can be applied to any similar system.
The first step to improving login security is to avoid exposing a user's plaintext
password. The common approach is to hash
the password, sending the resulting hash value to the server in place of the plaintext
password. The server compares this hash value against the hash value stored in the player's account. Thus, the hash value of the plaintext
password (along with the username) becomes the user's authenticator
. The plaintext
password is never stored or transmitted. The hashed authenticator
can even be stored on the client to allow automatic login.
TIP: Legacy software (and many Web-based applications) send the user's plaintext password over the network. No modern software has any excuse for ever transmitting or storing a user's plaintext password.
This basic form of hashing conceals the plaintext
password, but has several weaknesses. Suppose you use the same password for several sites (
). Even though your plaintext
password has not been revealed, the hashed authenticator
still grants access to your account on any system using the same hash function. Similarly, different users with the same password will have the same hashed authenticator
. Since many systems use the (legacy) MD5 hash function, a simple hash is not sufficient to protect your credentials.
TIP: Don't use the MD5 hash function. Minimally, use SHA-256. Consider going one step further and use the double-hashing technique defined in Practical Cryptography (Ferguson and Schneier, 2003).
The Potential RPG platform protects your password by mixing in additional information when hashing. Specifically, your password, username, and a system-unique value are hashed together to form your login authenticator
. By incorporating these values, each authenticator becomes specific to this game and the user. The authenticators cannot be used on other systems, even if the user has the same password. Users with the same password will not have the same authenticator.
As an added bonus, the above technique defends against dictionary attacks
. The purpose of a dictionary attack is to reveal the plaintext
password of a hashed authenticator
. Dictionary attacks against basic hashing work by pre-computing a dictionary
of hash values for all possible passwords. If your hashed authenticator
is in the dictionary, your plaintext
password is easily revealed. A single dictionary can be used to expose the passwords of many users, for any system using basic password hashing with the same hash function.
By mixing in a system-unique value and username with each password, a dictionary would have to be computed for each system and for each user
. This essentially renders a pure dictionary attack more expensive than would be worthwhile.
TIP: Making an attack more expensive increases overall security.
Consider a more valuable target: The server's database of user authenticators. Before storing any authenticators or authenticating any logins, have the server perform another round of hashing. The one-way nature of secure hash functions effectively devalues the authenticator database, because those values cannot be used to log in.
TIP: Devaluing a target increases overall security.
Unfortunately, all this password hardening still does not secure the login process itself. If an authenticator is stolen from a client's cache, or in transit to the server (during login), that authenticator can be used to log in as the user. This is an example of a replay attack
(the login information is copied by an adversary and resent later). The password hashing techniques described are still a valuable component of the security system, providing defense in depth
, but another layer of security must be added to further protect the login process.
Several strategies can be used to protect and conceal data in transit, but this article only covers password hashing. Besides, this is only Cyber Security Awareness
Month. This month, I only need to make you aware
of security issues. Later, we can discuss how to defend against further security vulnerabilities.
UPDATE: After writing this, I realized another benefit to good password hashing. If all systems salted and hashed your password as described above, you could safely use the same (plaintext) password everywhere. The hashed result would be unique per system. This sounds good from purely a client-server standpoint, but you would be more susceptible to keystroke logging, which would then be capturing your universal plaintext password as you type it into the keyboard.