[whatwg] Proposal for secure key-value data stores

On Tue, 17 Aug 2010, Evan Ireland wrote:
>
> I might wish to build an offline web application which will refuse to 
> operate if the browser cannot guarantee that the database is encrypted.
> Now full-disk encryption would be fine (if the O/S has a power-on 
> password), but how can my web application author detect (using a JS API) 
> if any data stored in a browser's database is in fact encrypted (or 
> not)?

It cannot, and should not. It's a user concern. If as a user I want all 
data that you send me to be printed unencrypted and dropped out of my 
office window for anyone to read, then I should be allowed to do that. :-)


> Such uncertainty might force us (as a vendor) to have to develop 
> platform/browser-specific plugins to providew an alternative 
> implemantation of the database API so we can be confident that database 
> storage is secure.

Secure from what?


On Tue, 17 Aug 2010, Dirk Pranke wrote:
> 
> I continue to think that the best approach to start with would be to 
> implement a library in JS that did crypto on top of the Platform APIs 
> (and having a native crypto API would be nice as well), and if it turned 
> out to be useful we could roll it into the platform.

That is generally the best way forward for any feature, indeed.


On Sun, 22 Aug 2010, Brian Campbell wrote:
> 
> 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).

It's probably the most wide-spread attack in the real world.


> 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.

In practice, people having their data read from their discarded disks is 
far less of a problem than people getting malware installed on their 
active systems.

Also, unless the data is encrypted behind a password prompt and the 
password is very secure, encryption isn't particularly helpful. I think 
it's optimistic to hope that browsers will ask all users to enter a secure 
passphrase before being able to use local storage.


> 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.

Stolen (or lost) laptops are a common problem (though nothing on the scale 
of malware/keylogger attacks), but that problem is solved by disk-wide 
encryption with a secure system-wide passphrase, not by a password for 
local storage. The former, assuming the laptop is stolen while turned off 
rather than suspended, is a pretty good defence. The latter is almost 
certainly a worthless defence since the data or key are likely to be found 
elsewhere in the system (e.g. in the pagefile).


> 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).

Indeed.


> 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.

This seems somewhat out of scope of a Web technology specification.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Tuesday, 30 November 2010 15:15:04 UTC