Re: [aerogear-dev] Security for "Device Registration"

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(a)apache.org <mailto:matzew@apache.org>> wrote: On Wed, May 22, 2013 at 12:13 AM, Bruno Oliveira <bruno(a)abstractj.org <mailto:bruno@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(a)apache.org <mailto:matzew@apache.org> > <mailto:matzew@apache.org <mailto:matzew@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(a)apache.org <mailto:matzew@apache.org> <mailto:matzew@apache.org <mailto:matzew@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(a)apache.org <mailto:matzew@apache.org> <mailto:matzew@apache.org <mailto:matzew@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(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@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 _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev