[whatwg] Proposal for secure key-value data stores

[Ian Hickson]

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


> 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.   `._.-(,_..'--(,_..'`-.;.'