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 (TIP: Don't.). 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.

The static keyword (in Java) is an important language feature, but can be easily abused, leading to several problems.

One problem is static cling syndrome: Static methods beget static methods. Once you start coding with global access methods, other parts of the system tend toward static access. Eventually, the design degenerates into unmaintainable spaghetti code.

Another drawback is initialization. A static system that requires an initialization method to be called is error prone. Consider Java’s class loading system, which may trigger static method calls just by accessing a class.

Purely static code may also break other software features, such as modular component design. The static API can be called from any object in any module at any time with no access control or coordination. In some cases, this type of global access is desirable. For example, a fully instance-based (non-static) logging system would require passing the logging object throughout the code, permeating every class with its presence.

If your code has given in to the dark side of static design, do not despair; there may still be some good left in it, and you may be able to save the design before it destroys itself. Attempt to reform the design by rewriting it with instance-based objects. This is your library implementation. If global access is needed (as with the logging example), follow the singleton pattern and provide static access to a single instance of the system.

Do not underestimate the power of an object design. Even though it still involves global static access, the singleton provides several benefits. For one, you can eliminate static cling by implementing helper classes as objects. Premature access problems are eliminated (or at least exposed), since there is no singleton instance to call until proper initialization is performed. The singleton pattern tempers the dark side, and is the tool of a more civilized design.

You might tell yourself that you’re not afraid of the dangers of a static design. Once you are faced with debugging an evil static system, only to find that your adversary is your very own code staring back at you, you will be; you will be…

First, consider the cases in which data serialization (a.k.a. marshalling and unmarshalling bytes) are used on this project. I am serializing objects for client-server network transport, client data cache, and server persistent storage. Without any special care, any class changes could/would break compatibility with old versions of the data. This situation is evident to any Alpha Playtester, as I usually wipe out the database after major updates.

Notice that client-side cache data can be (and is) expunged if any data structure has become incompatible. Also, since I’m using Java Web Start (at least provisionally), I can assume all users are running the latest version of the client software. Therefore, transport compatibility is not a big concern. Nonetheless, other projects may support clients of varying versions. Although I’m not explicitly dealing with this scenario, the technique described below could be used to support forward compatibility.

For the server, serialized data must survive code changes.

The standard advice is to avoid the problem; either maintain yet another external data format, or never change your objects. Since the former is undesirable, and the latter impossible, I’ve attempted to come up with a more robust approach.

Although Potential RPG is (so far) 100% Pure Java, I am not using Java’s built-in Serialization mechanism. Java Serialization is designed (rather elegantly, actually) for convenience at the expense of robustness. Even for core Java classes, the documentation explicitly warns that serialized data is likely to break between Java versions. Using Java’s Externalizable interface is an option, but this still binds the developer to Java’s Serialization mechanics.

The approach I’ve developed is an object packing/unpacking system, in which each serializable class has an accompanying byte-handling Packer helper class. This is functionally equivalent to a class-based Externalizable system (but with a cleaner API, IMHO).

The problem of survivability remains. The one-byte solution is to insert a packing schema version byte before each object’s data. This version is given to the unpacking method when unmarshalling the bytes. The unpacking method can include logic to (a) skip defunct fields and/or (b) set default values for missing fields. This technique provides backward compatibility. (Adapting to future versions is more complex, so I’ll ignore that on this project…)

Under this design, maintaining backward data compatibility for a class is a matter of augmenting the unpacking routine. Notice that the packing routine always produces an updated serialized data structure. Therefore, it is possible to write a routine that upgrades the database in one pass; or, the server can be left to lazily update objects as it encounters them.

For Playtesters, the next Alpha release will impose a mandatory database reset. After that, if I am diligent in my code, the test world should survive future updates.

Further reading: Durable Java: Serialization

I expect everyone to be walking around at Level 16 with Double Battleaxes and Expert Regeneration skill by tomorrow.

… That gives you one hour until tomorrow. Have at it.

Background: I have a class (let’s call it Subordinate) that has special control methods, which should only be called by a Master class. (Subordinate also has methods for public use.) Consequently, I originally implemented the Subordinate in the same (client-side) package as the Master, using package-protected control methods. Unfortunately, this binds the Subordinate, and everything that needs it, to client-packaged libraries.

Simple Solution: The simple solution is to repackage the Subordinate into its own (non-client-specific) package. Unfortunately, the control methods must become public for the Master (still bound to client-specific logic) to access. The API would have to document, “Please do not call the control methods, unless you’re supposed to.”

The Goal: My goal is to provide a Subordinate that can only be controlled by the Master. One approach is to create a Subordinate interface, and keep its implementation hidden. However, there is no desire to allow any other implementation of the Subordinate (it is best kept final).

Concealed Controller: The crux of this pattern is a Subordinate helper class, called Controller. Controller has access to the (once again) package-protected control methods of the Subordinate. The Controller exposes public access to the control methods. In addition, the only way to obtain a Subordinate is to construct a Controller (which constructs the Subordinate instance internally).

Integration: To use a Subordinate, the Master constructs a Controller and exposes the contained Subordinate publicly (but conceals the Controller for itself). The only access to the Subordinate’s control methods is via the Controller, which is concealed by the Master.

Pseudocode:

package library;
public final class Subordinate
{
    Subordinate() { }
    void control() { ... }
    public void action() { ... }
}
 
package library;
public final class Controller
{
    private final Subordinate sub = new Subordinate();
    public Controller() { }
    public Subordinate get() { return sub; }
    public void control() { sub.control(); }
}
 
package client;
final class Master
{
    private final Controller control = new Controller();
    Master() { activateWhenClientIsReady(); }
    private void activate() { control.control(); }
    public Subordinate get() { return control.get(); }
}

Potential RPG: In my code, the subordinate is a PlayerCharacter class, with activate() and deactivate() control methods, only to be used by the client-side CharacterAgent (master). Many GUI classes integrate with PlayerCharacter, which provides access to the in-world character being controlled by the player. Following this pattern, the CharacterAgent constructs and conceals the Activator (controller), shielding access to the control methods (thus preventing the chaos that would certainly ensue).

Posted this morning, Alpha3 v0.3.1 is an incremental release on the roadmap to Alpha4, introducing Player-Created Islands. There are some known issues and limitations, but basic functionality is testable. (This is the secret alpha bonus feature mentioned earlier.)

Disclaimer: I’m not promising how this feature will manifest itself in the final game design, but I’m very excited about the potential.

Alpha playtesters should see this forum topic for details on testing the new feature.