7:48 a.m.
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
5:58 p.m.
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>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
6:08 p.m.
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>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>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
6:10 p.m.
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>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>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>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
7:13 a.m.
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(a)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>> 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>> 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
https://lists.jboss.org/mailman/listinfo/aerogear-dev
2:03 p.m.
On Wed, May 22, 2013 at 12:13 AM, Bruno Oliveira <bruno(a)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>> 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>> 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>> 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
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)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
2:28 p.m.
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>wrote:
On Wed, May 22, 2013 at 12:13 AM, Bruno Oliveira <bruno(a)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>> 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>> 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>> 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
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)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
6:25 p.m.
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(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
7:05 p.m.
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(a)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(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(a)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
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)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
7:11 a.m.
Matthias Wessendorf wrote:
Another idea....
I can see a lot of good ideas here, but we have to start to file jiras.
There will be several several ways to make a system secure.
IMO start simple, make it ultra secure later.
We generate, for EACH variant, an "access-key" with a generated
secret(password).
What do you mean about secret? A shared secret? Now we have another
problem, you must encrypt this shared secret.
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.
I'm still confuse, about what do you want to encrypt and why. Why not
only create APP-KEY as a point of start, then we figure out how to
authorize or not a server.
Then several people, including me suggesting it will say "it's not
safe". Then you reply with "fix it" and we can make it work.
On Sat, May 18, 2013 at 12:48 AM, Matthias Wessendorf <matzew(a)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
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
2:02 p.m.
On Wed, May 22, 2013 at 12:11 AM, Bruno Oliveira <bruno(a)abstractj.org>wrote:
Matthias Wessendorf wrote:
> Another idea....
I can see a lot of good ideas here, but we have to start to file jiras.
Right, but I wanted to "validate" these ideas, instead of creating
countless JIRAs, all being closed "won't fix" / "does not make
sense". Main
intention here is really to ask for help, in validating these thoughts
There will be several several ways to make a system secure.
IMO start simple, make it ultra secure later.
yeah, that's my take on it too
>
> We generate, for EACH variant, an "access-key" with a generated
> secret(password).
What do you mean about secret? A shared secret? Now we have another
problem, you must encrypt this shared secret.
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.
>
I'm still confuse, about what do you want to encrypt and why. Why not
only create APP-KEY as a point of start, then we figure out how to
authorize or not a server.
Not sure I understand what you mean, but I am not talking about "authorize
an server" (e.g. for sending mails to devices).
These mails are around: devices registers its "application installation" by
submitting "token" to a mobile Variant, ("I am an instance of you,")
Then several people, including me suggesting it will say "it's not
safe". Then you reply with "fix it" and we can make it work.
Not sure what that means? Why would *I* just reply "fix it"? Again, this
was intended for discussion, not "do this, do that".
>
>
>
>
>
>
>
>
> On Sat, May 18, 2013 at 12:48 AM, Matthias Wessendorf <matzew(a)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
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)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
12:58 a.m.
On Sat, May 18, 2013 at 12:48:31AM +0200, Matthias Wessendorf 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
When you say
private/public key pair, you mean two pairs right? one for
the device, other for the server variant?
Let's clarify this then we can move the discussion further.
--
qmx
1:05 a.m.
On Tue, May 21, 2013 at 5:58 PM, Douglas Campos <qmx(a)qmx.me> wrote:
On Sat, May 18, 2013 at 12:48:31AM +0200, Matthias Wessendorf 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
When you say private/public key pair, you mean two pairs right? one for
the device, other for the server variant?
Let's clarify this then we can move the discussion further.
I think I mean more the Unified Push server has the "private key", while
the device uses the public key,
to perform the "auth" against the server-side variant (e.g. PhoneABC
registers itself with the Android variant)
-M
--
qmx
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)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
1:19 a.m.
On Tue, May 21, 2013 at 06:05:00PM +0200, Matthias Wessendorf wrote:
I think I mean more the Unified Push server has the "private
key", while
the device uses the public key,
to perform the "auth" against the server-side variant (e.g. PhoneABC
registers itself with the Android variant)
Unless you have two key pairs, this adds
zero security to the mix.
amirite, abstractj?
--
qmx
1:27 a.m.
On Tue, May 21, 2013 at 6:19 PM, Douglas Campos <qmx(a)qmx.me> wrote:
On Tue, May 21, 2013 at 06:05:00PM +0200, Matthias Wessendorf wrote:
> I think I mean more the Unified Push server has the "private key", while
> the device uses the public key,
> to perform the "auth" against the server-side variant (e.g. PhoneABC
> registers itself with the Android variant)
Unless you have two key pairs, this adds zero security to the mix.
Not sure I follow, but if _every_ mobile application
(MobileVariantInstance) needs to perform auth against the server to
register itself with the MobileVariant (e.g. the logical construct of an
Android variant), how or why are two key pairs needed.
The public/private key I had in mind is just for the MobileVariant, so that
_every_ devices that know the public key, can perform auth against it.
As said before this key pair is ONLY for working on the data of the
MobileVariantInstance(s). Not more (no sending, no PushApp/MobileVariant
registration; as said before).
Not sure I understand the two key pairs here (e.g. why two)
amirite, abstractj?
--
qmx
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)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
6:46 a.m.
Yup!
Douglas Campos wrote:
On Tue, May 21, 2013 at 06:05:00PM +0200, Matthias Wessendorf wrote:
> I think I mean more the Unified Push server has the "private key", while
> the device uses the public key,
> to perform the "auth" against the server-side variant (e.g. PhoneABC
> registers itself with the Android variant)
Unless you have two key pairs, this adds zero security to the mix.
amirite, abstractj?
7:20 a.m.
Basically a malicious third party, can replace your server. And how do
you check the authenticity of that public key? Once I already was mean
and redirected all the traffic to my evil-server?
What's necessary to us, calls PKI. But this is not something easy to
raise from scratch, so, let's move forward and improve during our
development.
Matthias Wessendorf wrote:
On Tue, May 21, 2013 at 5:58 PM, Douglas Campos <qmx(a)qmx.me
<mailto:qmx@qmx.me>> wrote:
On Sat, May 18, 2013 at 12:48:31AM +0200, Matthias Wessendorf 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
When you say private/public key pair, you mean two pairs right? one for
the device, other for the server variant?
Let's clarify this then we can move the discussion further.
I think I mean more the Unified Push server has the "private key", while
the device uses the public key,
to perform the "auth" against the server-side variant (e.g. PhoneABC
registers itself with the Android variant)
-M
--
qmx
_______________________________________________
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
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
7:01 a.m.
I'm really not sure which e-mail to reply, so just in case, I'll reply all.
Matthias Wessendorf 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 ???
Mobile Variant == An application correct? (I'm looking at
https://gist.github.com/matzew/b918eb45d3f17de09b8f)
Why do you need a public/private key model? Encrypt data exchanged
between client/server? At first glance is it really a priority? Why not
make use of WSS?
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...
Why?
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" ??
I'm really confused about what do you want to achieve. I read the whole
spec and I'm not following.
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
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
1:57 p.m.
On Wed, May 22, 2013 at 12:01 AM, Bruno Oliveira <bruno(a)abstractj.org>wrote:
I'm really not sure which e-mail to reply, so just in case,
I'll reply all.
that's OK :) Thanks for looking at them
Matthias Wessendorf 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 ???
Mobile Variant == An application correct? (I'm looking at
https://gist.github.com/matzew/b918eb45d3f17de09b8f)
An application (installed on a phone) is a "Mobile Variant Instance".
The
MobileVariant it self is just the abstraction, saying there is an one iOS
application (HR for iOS). The actual installations, on the devices are
called "Mobile Variant Instance".
Why do you need a public/private key model? Encrypt data exchanged
between client/server? At first glance is it really a priority?
I don't know - that's why I am asking here :)
Why not make use of WSS?
WebSocketSecure ?
>
> 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...
Why?
I am not sure, I just had that idea. I am not a security expert; I ask here
to validate my ideas. That's all.
>
> 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" ??
I'm really confused about what do you want to achieve. I read the whole
spec and I'm not following.
hrm, perhaps a hangout to "validate" these things?
I will, afterwards, summarize that and will send out the notes.
>
> 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
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)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
4003
days inactive
4008
days old
18 comments
3 participants
participants (3)
-
Bruno Oliveira -
Douglas Campos -
Matthias Wessendorf