W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2010

[whatwg] Proposal for secure key-value data stores

From: Brian Campbell <lambda@continuation.org>
Date: Sun, 22 Aug 2010 23:11:41 -0400
Message-ID: <01F51AE0-0A5B-4405-AF05-58570A0EAC77@continuation.org>
On Aug 16, 2010, at 6:58 PM, Ian Hickson wrote:

> On Tue, 30 Mar 2010, Nicholas Zakas wrote:
>> In attempting to use localStorage at work, we ran into some major 
>> security issues. Primary among those are the guidelines we have in place 
>> regarding personalized user data. The short story is that personalized 
>> data cannot be stored on disk unless it's encrypted using a 
>> company-validated encryption mechanism and key. So if we actually wanted 
>> to use localStorage, we'd be forced to encrypt each value as it was 
>> being written and then decrypt each value being read. Because of this 
>> tediousness, we opted not to use it.
> Doing that wouldn't actually help, either, since anyone attacking the user 
> could simply intercept the key and then decrypt it all offline. (In this 
> scenario, I'm assuming the attack being defeated is that of an attacker 
> obtaining the data, and I'm assuming that the attacker has physical access 
> to the computer, since otherwise the Web's security model would be 
> sufficient to block the attack, and that the computer is logged in, since 
> otherwise whole-disk encryption would be sufficient to block this attack.)

Note that there are several different types of attack you might want to defend against. While it's true that there's no real defense against someone taking physical control of the machine, installing a keylogger, putting the machine back in the users control, and then either uploading the data somewhere or retrieving the data physically at a later time, that attack works against almost all security mechanisms in the web platform (password authentication, HTTPS, cookies, etc). That is a very expensive type of attack, with a high risk of discovery (several opportunities for physical discovery, and the keylogger may be discovered too).

There are several attacks that are much cheaper and easier which encryption of data on disk can prevent. I think one of the biggest risks is simply the discarded hard drives. While most places which deal in sensitive data require that hard drives are erased or destroyed before being disposed of, in practice, that's something that's very easy to overlook when discarding an old computer. There is considerable risk of someone just doing dumpster diving being able to recover sensitive data, which can be prevented (with no risk of the password being sniffed) by just encrypting all potentially sensitive data before writing it to the disk.

The stolen laptop attack is similar; encryption will prevent sensitive data from being leaked, and stealing a laptop is a lot easier than stealing a laptop, installing a keylogger, returning it unnoticed, and then collecting the data from the keylogger unnoticed.

So, there are real security benefits to ensuring that sensitive data is stored encrypted. One way to do this is to require the platform to encrypt the data, either the browser itself or the browser ensuring that the operating system has some sort of full-disk encryption. The web app could then require the browser report that data will be encrypted before sending the data down. The problem with this is that browsers may lie, or be mistaken about full-disk encryption. Microsoft Exchange has a flag that notifies the server whether data is stored encrypted, and some companies have policies of not allowing clients that don't support encryption. Of course, this means that several clients just lie, claiming to encrypt the data while not actually doing so (I believe the initial version of the iPhone Exchange client did this, though my memory may be hazy).

Anyhow, I think most of the reasonable ideas have been suggested in this thread (allow the browser to report whether data will be stored encrypted, provide a JS crypto API to allow web apps to more easily encrypt and decrypt data piecemeal on the client side). The one thing I'd add is that if you really want to make sure that private data will be encrypted, it's probably best not to allow users to have access to that data unless they are known (by some out of band means, such as IT department policy and limiting access to the data to certain machines) to be on managed machines that have full-disk encryption, or that they have read and agreed to a policy that states that they must use full-disk encryption. This way, it's the user or the IT department's responsibility to ensure that the disk is encrypted securely, not the browser vendor which may or may not know.

-- Brian
Received on Sunday, 22 August 2010 20:11:41 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:00 UTC