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
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
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
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.
to post comments)