[aerogear-dev] Security for "Device Registration"

Bruno Oliveira bruno at abstractj.org
Tue May 21 18:13:38 EDT 2013


Is it a priority? If yes, please file a jira.

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


More information about the aerogear-dev mailing list