[aerogear-dev] Security for "Device Registration"
Bruno Oliveira
bruno at abstractj.org
Wed May 22 05:25:07 EDT 2013
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
More information about the aerogear-dev
mailing list