[aerogear-dev] Security for "Device Registration"
Matthias Wessendorf
matzew at apache.org
Wed May 22 01:28:36 EDT 2013
Let's have hangout to talk about the proposed ideas and the related
discussion, instead of getting lost in countless emails.
I am happy to summarise the out come here, on this ML thread
On Wed, May 22, 2013 at 7:03 AM, Matthias Wessendorf <matzew at apache.org>wrote:
>
>
>
> On Wed, May 22, 2013 at 12:13 AM, Bruno Oliveira <bruno at abstractj.org>wrote:
>
>> Is it a priority? If yes, please file a jira.
>>
>
>
> Nah, not a priority at all.
>
>
>>
>> Matthias Wessendorf wrote:
>> > 1a)
>> > would perhaps,... add some "monitoring" if an unreasonalble about of
>> > "new devices" is registered, but that means we need some sort
>> > of analysis component (not for the first iteration) :)
>> >
>> > whoops, typos ===>
>> > we could perhaps,... add some "monitoring" if an unreasonable amount of
>> > "new devices" is registered, but that means we need some sort
>> > of analysis component (not for the first iteration) :)
>> >
>> >
>> >
>> > On Sun, May 19, 2013 at 11:08 AM, Matthias Wessendorf <
>> matzew at apache.org
>> > <mailto:matzew at apache.org>> wrote:
>> >
>> > Concerns with both approaches
>> >
>> >
>> > 1)
>> > It would be possible to register new devices, if the pub/private key
>> > (or the accessKey:secret combination) would be hacked.
>> >
>> > HOWEVER, the "hacker" has to know how to generate VALID tokens for
>> > the different push-networks. Apple and Google will NOT accept
>> > incorrect tokens, and IMO this as a minimal risk.
>> > Similar for SimplePush. The SimplePush Network/Server, generates
>> > UUIDv4 key, for every channel, so IMO.... it's hard to "hijack" that
>> > as well.
>> > => But I may be just naive.
>> >
>> >
>> > 1a)
>> > would perhaps,... add some "monitoring" if an unreasonalble about of
>> > "new devices" is registered, but that means we need some sort
>> > of analysis component (not for the first iteration) :)
>> >
>> >
>> > 2) hacker can update device info
>> > If the pub/private key (or the accessKey:secret combination) are
>> > being compromised. it is possible to update informations for a
>> > certain device. IF... he know the "token".
>> > So... it's than very simple that the hacker can update informations
>> > for his phone (since that token is VERY easy to read, via the
>> > platform APIs).
>> > IMO not a big deal. If he updates his iPhone metadata (e.g. changing
>> > "iOS" to "Android"). If he changes his token, he looks himself out
>> > -> No longer receives "push notification messages"
>> >
>> > 2a)
>> > A hacker could update device infomations for other devices. BUT !!!!
>> > he has to know the token of other devices, registered with our
>> > server. This means, he needs access to those devices.
>> > => IMO as well not a big risk..
>> >
>> >
>> >
>> > Summary:
>> > I think, if we really have a "extra" pub/private key (or the
>> > accessKey:secret combination) for "device (un)registration", and not
>> > allowing this pub/private key (or the accessKey:secret combination)
>> > on other HTTP calls (e.g. register Push Application, register mobile
>> > Varian, sending): The risk is IMO minimal.
>> >
>> >
>> > Thoughts ?
>> >
>> >
>> >
>> >
>> >
>> > On Sun, May 19, 2013 at 10:58 AM, Matthias Wessendorf
>> > <matzew at apache.org <mailto:matzew at apache.org>> wrote:
>> >
>> > Another idea....
>> >
>> > We generate, for EACH variant, an "access-key" with a generated
>> > secret(password). This accessKey:secret combination would be,
>> > similar to the previous email, ONLY be able to perform updates
>> > for "device (un)registration".
>> >
>> > It would be NOT possible to use this combination for sending
>> > messages to a device, (read: our HTTP send interface would not
>> > allow this accessKey:secret combination).
>> >
>> >
>> > Not, sure, but this is (I guess) a bit simpler, initially,
>> > instead of using private/public key approach.
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > On Sat, May 18, 2013 at 12:48 AM, Matthias Wessendorf
>> > <matzew at apache.org <mailto:matzew at apache.org>> wrote:
>> >
>> > Hi,
>> >
>> > once the app is installed on the phone (or launched in a
>> > browser),
>> > we (as discussed in the spec/mailing list) need to upload
>> > the "device token" (or channelID) from the actual
>> > device/channel to the Unified Push Server.
>> >
>> >
>> > My questions:
>> > Is it safe, if every "Mobile Variant" has a Private/Public
>> > Key ???
>> >
>> > The UP server keeps the private one.
>> > Once we register a new mobile variant (e.g. HR for Android,
>> > HR for iPad, HR for iPhone, ...) EACH variant has ONE
>> > Private/Public key
>> >
>> >
>> > The Public Key of this combo would be "coded" into the
>> > actual mobiel application...
>> >
>> > On EVERY iOS app, it would use the PubKey from the iOS
>> > Variant, on EVERY JS-app, it would use the PubKey from the
>> > SimplePush Variant, etc
>> >
>> >
>> > So, that means EVERY installation (on the devices) would
>> > have that pbulci key...
>> >
>> > Would that be (extremely) odd, if "1 Mio Russian hacker"
>> > would have that public key, used on the device, to perform
>> > some sort of "auth" (e.g. via HTTP BASIC (just saying.....))
>> > against the server, in order to upload the "device token" ??
>> >
>> >
>> > Note: This Private/Public key would/should be EXCLUSIVE for
>> > "device registration". And really ONLY.. :-)
>> >
>> > So that this "Private/Public key" pair can NOT be used
>> > (==invalid) for sending messages to the installations, or
>> > creating the Push-Applications / Mobile Variant Constructs.
>> >
>> >
>> >
>> > Greetings,
>> > Matthias
>> >
>> > --
>> > Matthias Wessendorf
>> >
>> > blog: http://matthiaswessendorf.wordpress.com/
>> > sessions: http://www.slideshare.net/mwessendorf
>> > twitter: http://twitter.com/mwessendorf
>> >
>> >
>> >
>> >
>> > --
>> > Matthias Wessendorf
>> >
>> > blog: http://matthiaswessendorf.wordpress.com/
>> > sessions: http://www.slideshare.net/mwessendorf
>> > twitter: http://twitter.com/mwessendorf
>> >
>> >
>> >
>> >
>> > --
>> > Matthias Wessendorf
>> >
>> > blog: http://matthiaswessendorf.wordpress.com/
>> > sessions: http://www.slideshare.net/mwessendorf
>> > twitter: http://twitter.com/mwessendorf
>> >
>> >
>> >
>> >
>> > --
>> > Matthias Wessendorf
>> >
>> > blog: http://matthiaswessendorf.wordpress.com/
>> > sessions: http://www.slideshare.net/mwessendorf
>> > twitter: http://twitter.com/mwessendorf
>> >
>> > _______________________________________________
>> > aerogear-dev mailing list
>> > aerogear-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130522/487060d5/attachment-0001.html
More information about the aerogear-dev
mailing list