[aerogear-dev] Security for "Device Registration"
Matthias Wessendorf
matzew at apache.org
Wed May 22 06:05:36 EDT 2013
ok,
I will write something, so that we have concrete things to talk about
On Wed, May 22, 2013 at 11:25 AM, Bruno Oliveira <bruno at abstractj.org>wrote:
> I'm fine on have a hangout anytime, but at least to me (abstractj) will be
> useless, until I get some working code for Pushee to validate ideas.
>
> Matthias Wessendorf wrote:
> > 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 <mailto:matzew at apache.org>> wrote:
> >
> >
> >
> >
> > On Wed, May 22, 2013 at 12:13 AM, Bruno Oliveira
> > <bruno at abstractj.org <mailto: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>
> > > <mailto: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>
> > <mailto: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>
> > <mailto: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
> > <mailto:aerogear-dev at lists.jboss.org>
> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org <mailto:
> 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
> > _______________________________________________
> > 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/59a2cae1/attachment-0001.html
More information about the aerogear-dev
mailing list