[aerogear-dev] Security for "Device Registration"
Matthias Wessendorf
matzew at apache.org
Wed May 22 01:03:06 EDT 2013
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130522/3c7708d0/attachment-0001.html
More information about the aerogear-dev
mailing list