787965 - [Security Review] [Action Item] Introduce a mechanism in gecko to generate a WAToken when no token is provided

Status: NEW

(mozilla.org :: Security Assurance, task, P1)

Description

[Paul Theriault [:pauljt] (no longer reading bugmail)]

To make the Push API easier to user (and easier to secure) it was proposed during the security review to modify the register call, so that if no WAToken was provided, gecko would generate a secure, large, random token which the app could use. The client would then need to send this token back to the App Server (see https://www.dropbox.com/s/xa3gqxyd7ycpw0y/Push%20notification%20server%20APIs.docx definition)

Comment 1

[Thinker Li [:sinker]]

(In reply to Paul Theriault [:pauljt] from comment #0)
> To make the Push API easier to user (and easier to secure) it was proposed
> during the security review to modify the register call, so that if no
> WAToken was provided, gecko would generate a secure, large, random token
> which the app could use. The client would then need to send this token back
> to the App Server (see
> https://www.dropbox.com/s/xa3gqxyd7ycpw0y/
> Push%20notification%20server%20APIs.docx definition)

Why is not the app server to generate WAToken for an app?  Sorry! I am not involved in security review, and I don't see the reason it should be done at device side, not at app server side.

Comment 2

[Paul Theriault [:pauljt] (no longer reading bugmail)]

The discussion from the review was to make it easier for developers to use this API securely. The risk is that developers may create poor WATokens (non-random, not large etc). The proposal was that if a page called the API without a WAToken value, the browser generates a secure large value which the app can then report back to the server.

On reflection I am not sure if this adds a lot of security though. This creates a new problem that the client needs to register the token with the app server, and that is probably more complicated that just generating it on the server side in the first place. For one, the user would have to be logged in, otherwise the generated token couldn't be securely associated to a user.

So I don't have a strong feeling that this needs to be done, but maybe other from the review feel otherwise.

Comment 3

[Fernando R. Sela (no CC, needinfo please) [:frsela]]

Hi,

The WAToken SHALL be a secret one given by the webapp, and the idea is not to avoid the developer to choose his own WAToken (since this is needed for *multicast* notifications)

Jona's concern is that if the developer don't want's to worry about this token probably he'll use unsecure ones, so we should offer a way to allow developer to leave this parameter empty.

So, if I understood well, the Gecko component should generate a random one (UUID?) if no watoken is given.

--

To the question if this have been done by client or server side, we think that it's better to do it on client side because:

In order to allow async. registration, we'll add the WAToken on the registration response so if no WAToken is given on multiple webapps, you won't have any way to map each public URL with the related webapp.

Comment 4

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Yes, like Fernando said the idea here isn't to get rid of the WAToken entirely, but rather make it optional.

That way a developer which doesn't care about multicasting doesn't need to worry about coming up with a user identifier or worry about keeping it hidden.

We could basically just create a random value when the WAToken is omitted. We just have to make sure that it's a cryptographically strong random value so that it can't be guessed. I'm guessing we do something similar to generate a UAToken when registering with the notification server?

The only problem with generating a really random value is that we need to be able to support unregistering notification at some point in the future (not required for v1). So we'd either need to flag the generated WAToken with "this was generated due to no WAToken supplied" in the internal indexedDB database.

Comment 5

[Antonio Manuel Amaya Calvo (:amac)]

Sorry for piping in so late, but I just discovered this bug. 

The whole point of the WAToken is to give a way to securely identify users between the App Server and the Push Server. If the application developer doesn't care about individual users (and he just wants to use broadcasts) then he doesn't need to figure any way of creating secure tokens. And if he *does* care about individual users, then he *already* has to have some mechanism in place to create any kind of token (we can call it cookie if you wish, but it's still a token) to keep the user's identity during a session at least. 

The WAToken isn't anything more and anything less than an extra authentication token, with the same requisites than the session token. So it should be generated at the server side, it doesn't make much sense to generate it at the client side.