[whatwg] Proposal for secure key-value data stores
ian at hixie.ch
Tue Nov 30 15:15:04 PST 2010
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
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
In practice, people having their data read from their discarded disks is
far less of a problem than people getting malware installed on their
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).
> 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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg