W3C home > Mailing lists > Public > public-device-apis@w3.org > October 2009

Re: ISSUE-11: Gathering requirements [FileSystem API]

From: Peter-Paul Koch <pp.koch@gmail.com>
Date: Tue, 6 Oct 2009 12:40:08 +0200
Message-ID: <21e4a1280910060340h40c6b355kda65a88e923e37a@mail.gmail.com>
To: "Nilsson, Claes1" <Claes1.Nilsson@sonyericsson.com>
Cc: "public-device-apis@w3.org" <public-device-apis@w3.org>
> I am thinking of general secrets for authentication towards a server. This can be API keys but also login credentials.

I'm sorry, but I disagree strongly. This should not be part of the Device API.

In general, JavaScript is inherently insecure, and we shouldn't add
anything to this API that needs a certain level of security other than
what the browser or OS can provide. We shouldn't even *pretend* we
offer any such form of security.

Some browsers (notably Chrome) offer to store login/passwords for you,
but this function is wholly separated from JavaScript. If it weren't,
a cross-site scripting attack would be able to steal all your
passwords.

> It should be implementation dependent how the keys, credentials etc are stored. What's important is that the secret information shall be protected from access by applications for which the secret information is not indented. Access to the information should be granted based on the identity of the application.

This would be trivial to spoof. Whatever mechanism is in place for
determining whether a widget has access to credentials can easily be
copied by a malicious author from one W3C Widget to another. The
author could then spread the widget under an innocent-sounding name,
and it would access a user's credentials and send them off to the
malicious author's server.

I strongly feel that credentials and logins should not be handled on
the JavaScript level at all.

Of course, if this API would be used by another, non-client-side
language, the security constraints might be different - I wouldn't
know.

But it MUST NOT be implemented in JavaScript. It's a glaring security
hole waiting to be exploited.

>
> An example of an application needing this kind of API is a Facebook web widget where certain API keys are needed to get access to a set of extra APIs that are not accessible by the normal Facebook web page executed in the browser.
>
> Maybe the requirement should be rephrased to:
>
> "SHOULD provide secure storage and management of secret information, e.g. server login credentials or API keys."

------------------------------------------------------------------
ppk, freelance front-end consultant,
agent, and trainer
http://www.quirksmode.org/about/
------------------------------------------------------------------
Received on Tuesday, 6 October 2009 10:40:38 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:39 UTC