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

Thanks for all comments. Nice to have a lively discussion :-)

With my proposal I assume:

* It is possible to securely verify the identity of the web application (typically a signed widget).
* The mobile platform is capable of preventing any other applications than the application the secret information is aimed for from accessing the information.

This of course places restrictions on the usage of this API and places requirements on the devices implementing the API. 

I would like to take your comments to an internal discussion with our security experts and come back with more meat to the discussion later.

Regards
  Claes 

-----Original Message-----
From: richard.tibbett@orange-ftgroup.com [mailto:richard.tibbett@orange-ftgroup.com] 
Sent: tisdag den 6 oktober 2009 17:52
To: pp.koch@gmail.com; Nilsson, Claes1
Cc: public-device-apis@w3.org
Subject: RE: ISSUE-11: Gathering requirements [FileSystem API]

On Oct 6, 2009, at 11:44 , Peter-Paul Koch wrote:
> 
> On Oct 6, 2009, at 10:41 , Nilsson, Claes1 wrote:
> > 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.
> 

I second that. If any user credentials flow through Javascript, they can
be intercepted either by the developer themselves or by malicious XSS
script. Interception by the developer COULD be seen as useful by some
(for e.g. persistent credential storage) but the resulting storage may
be insecure and/or clunky...you wouldn't be able to force developers to
use the secure storage we set aside.

Mostly it puts the end-user at the mercy of the developer's competency
in keeping their credentials secure and I don't trust all JS developers
(most of them like you guys of course ;-D).

This is a general web problem: authenticating from AJAX Web Apps via
Javascript for example. OpenId or OpenAuth as authentication mechanisms
are proposed alternatives to having to deal with user credentials
directly. It does seem like this decision will be down to individual
developers and how open they perceive their users will be to providing
usernames and passwords to their 3rd party application. In any case, if
a developer gets hold of usernames and passwords (e.g. credentials touch
Javascript at any point) then we should assume the worst kind of
storage. Giving users a false sense of credential security by providing
a secure storage area may be misleading if developers aren't using it
correctly or sufficiently.

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

IMHO, I agree that it should be implementation dependent and beyond our
scope. All necessary credentials would be configured outside of the web
runtime e.g. as part of an api config file/dialog/application not framed
in the browser.

So, by way of example, if the file system that is plugged from the file
system api just happens to be cloud-based, I would configure my
username/password credentials for the cloud in a separate config file.
When I use any part of the FS API the authentication would be performed
from my device to the server in the background. I can use the FS API
without having to worry about authentication as part of my consumption
of the FS API as it's configured and handled bby the device backend
implementation. I have access because the DAP policy allows me to access
the FS API in the first place (so then it's a given that authentication
with the actual file system is performed transparently).

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

Authentication to server-side APIs from JS are not the exclusive problem
of the DAP WG. This problem exists on the current web and I wouldn't
consider the DAP WG a catch all or a resolution point for the insecurity
of Javascript. OpenId is made for this use case, and is incidentally
supported for Facebook API developers.

> > Maybe the requirement should be rephrased to:
> >
> > "SHOULD provide secure storage and management of secret 
> information, e.g. server login credentials or API keys."
>

Received on Wednesday, 7 October 2009 11:52:08 UTC