[whatwg] Proposal for secure key-value data stores
eireland at sybase.com
Mon Aug 16 16:03:58 PDT 2010
One of our key concerns is with Web SQL Database API (which we prefer) or
Indexed Database API.
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)?
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.
> -----Original Message-----
> From: Ian Hickson [mailto:ian at hixie.ch]
> Sent: Tuesday, 17 August 2010 10:58 a.m.
> To: whatwg at lists.whatwg.org
> Subject: [whatwg] Proposal for secure key-value data stores
> 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
> > 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.)
> > Another major issue also relates to the persistence of the data in
> > localStorage. Whereas cookies allow you to specify a time
> at which the
> > data will be removed, localStorage is there more or less forever.
> Right, it's there for as long as the data that would be saved
> by the user
> if the user viewed your page and chose "File > Save As" --
> that is, until
> the user deletes it. (Or until he visits your page again and
> your page
> deletes it.)
> > It seems like any company that takes the security of its
> data seriously
> > would run into the same issues, and rather than forcing
> every company to
> > implement their own version of the same approach, a common native
> > approach would be incredibly useful.
> Why isn't whole-disk encryption sufficient? It seems like if
> the user is
> concerned about his disk being stolen, he'd be concerned
> about all data on
> the disk, including his HTTP cache, his cookies, his saved
> usernames and
> passwords, etc, not just the data in the Web page's localStorage area.
> On Tue, 30 Mar 2010, Dirk Pranke wrote:
> > Nicholas is almost certainly discussing the case where the service
> > provider requires any data stored on a customer's computer to be
> > encrypted, not the provider's own computers. (e.g., this could be a
> > Yahoo! policy that data stored on Yahoo! users' computers must be
> > encrypted).
> > Hence they cannot enforce anything like "use FileVault".
> If you can't enforce whole disk encryption, but you are
> concerned that an
> attacker could have access to your machine, it seems that there is no
> solution, since an attacker could just install a rootkit and
> then carry
> out arbitrary attacks remotely, including simply replacing
> the browser
> with one that intercepts all the user's data as it is written.
> On Tue, 30 Mar 2010, Dirk Pranke wrote:
> > Perhaps we should instead focus on a set of JS Crypto APIs,
> since that
> > is largely orthogonal to the storage APIs?
> That would make more sense, I think. It would be useful in
> other scenarios
> too (such as replacing <keygen>). I would encourage people
> interested in
> such an approach to get vendors together and write a spec.
> Ian Hickson U+1047E
> )\._.,--....,'``. fL
> http://ln.hixie.ch/ U+263A /, _.. \
> _\ ;`._ ,.
> Things that are impossible just take longer.
More information about the whatwg