Encrypting users' web data with Grendel

Web sites that store personal information can be worrisome. Depending on the type of information stored, disclosure of the data can have effects ranging from embarrassment to financial loss. There are steps that web services (or "cloud" services in the parlance of our times) can take to reduce the danger of data disclosure. The Grendel encryption mechanism for sensitive data, which was recently released under the MIT license, is a reasonable approach to the problem—and one that can now be examined and possibly adopted by other web services.

Grendel comes from Wesabe, which is an online money management tool. That means that Wesabe stores some of the most sensitive information a user has, so focusing on security is important to Wesabe and its users. Unlike many other web services, though, Wesabe has been very candid about the steps it takes to safeguard its users' data. The release of Grendel is just another step along that path.

The basic idea behind Grendel is a REST-based API that a web service can use to implement an encrypted store for users' data. The encryption is done using OpenPGP, with keys being generated when the user is created. The private key is then encrypted using the user's password, so that it is only when a user is logged in that their data can be decrypted.

The interface is meant for the back-end, "behind the firewall", so the rest of the web application uses the API over a local or private network to retrieve whatever data has been stored by the user. Grendel is meant to reduce or eliminate sensitive data leaks to third parties, not to protect against malfeasance from web site operators. The recent RockYou breach is mentioned as an example of the kinds of leaks Grendel is meant to prevent.

The decryption key for the OpenPGP private key (i.e. the user's password) is only available to the application while the user is logged in. Once that session terminates (either through an explicit log out or a session time out), any attacker will be unable to access the data unless they can crack the password. So, even a complete compromise of the database contents will not easily allow access to the sensitive data.

In some ways, Grendel is an outgrowth of another technique that is used by Wesabe, called the "privacy wall". The wall makes it difficult for attackers to correlate users and their private information even if the database contents are exposed. Instead of using a user_id field to connect a user table to another table, the technique uses a cryptographic hash of the username and password as the key into the second table. That way, a particular user's data in the second table cannot be retrieved without the user's password, which is only available during the lifetime of their session.

There are some additional wrinkles, of course. If a user forgets their password, their data is essentially lost. This might be viewed by some as a weakness to the system, but from a security standpoint it makes a lot of sense. One way to handle that problem might be storing the key value (i.e. hash of username and password) encrypted with other information, such as the answer to security questions. However, security questions have risks of their own to consider.

There is nothing truly groundbreaking in these techniques, but there are certainly useful ideas embodied in them. While Grendel itself may not be of interest to other web services, due to its architecture or its Java implementation, it is heartening to see a web service that takes security seriously enough to explain its methods. It certainly stands in stark contrast to other services and their "trust us" security policies—something to consider when storing sensitive data on the web.