<div dir="ltr">1a)<div><div style="font-family:arial,sans-serif;font-size:13px"><font face="arial, sans-serif">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) :) </font></div>
</div><div><font face="arial, sans-serif"><br></font></div><div style><font face="arial, sans-serif">whoops, typos ===> </font></div><div><div><font face="arial, sans-serif">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) :) </font></div>
</div><div><font face="arial, sans-serif"><br></font></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, May 19, 2013 at 11:08 AM, Matthias Wessendorf <span dir="ltr"><<a href="mailto:matzew@apache.org" target="_blank">matzew@apache.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Concerns with both approaches<div><br></div><div><br></div><div>1) </div><div>It would be possible to register new devices, if the pub/private key (or the <span style="font-family:arial,sans-serif;font-size:13px">accessKey:secret combination) would be hacked.</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">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.</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px">Similar for SimplePush. The SimplePush Network/Server, generates UUIDv4 key, for every channel, so IMO.... it's hard to "hijack" that as well. </span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px">=> But I may be just naive.</span></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br>
</span></div><div><font face="arial, sans-serif">1a)</font></div><div><font face="arial, sans-serif">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) :) </font></div>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">2) hacker can update device info</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px">If the </span>pub/private key (or the <span style="font-size:13px;font-family:arial,sans-serif">accessKey:secret combination) are being compromised. it is possible to update informations for a certain device. IF... he know the "token".</span></div>
<div><span style="font-size:13px;font-family:arial,sans-serif">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).</span></div>
<div><span style="font-size:13px;font-family:arial,sans-serif">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"</span></div>
<div><span style="font-size:13px;font-family:arial,sans-serif"><br></span></div><div><span style="font-size:13px;font-family:arial,sans-serif">2a)</span></div><div><span style="font-size:13px;font-family:arial,sans-serif">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.</span></div>
<div><span style="font-size:13px;font-family:arial,sans-serif">=> IMO as well not a big risk.. </span></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br>
</span></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">Summary:</span></div><div><span style="font-family:arial,sans-serif;font-size:13px">I think, if we really have a "extra" </span> pub/private key (or the <span style="font-size:13px;font-family:arial,sans-serif">accessKey:secret combination) for "device (un)registration", and not allowing this </span> pub/private key (or the <span style="font-size:13px;font-family:arial,sans-serif">accessKey:secret combination) on other HTTP calls (e.g. register Push Application, register mobile Varian, sending): The risk is IMO minimal.</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px"> Thoughts ?</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br>
</span></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, May 19, 2013 at 10:58 AM, Matthias Wessendorf <span dir="ltr"><<a href="mailto:matzew@apache.org" target="_blank">matzew@apache.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Another idea....<div><br></div><div>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".</div>
<div><br></div><div>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).</div><div><br></div>
<div><br></div><div>Not, sure, but this is (I guess) a bit simpler, initially, instead of using private/public key approach.</div><div><br></div><div><br></div><div><br></div><div><br></div>
<div><br></div><div><br></div><div><br></div></div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, May 18, 2013 at 12:48 AM, Matthias Wessendorf <span dir="ltr"><<a href="mailto:matzew@apache.org" target="_blank">matzew@apache.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hi,</div><div><br></div><div>once the app is installed on the phone (or launched in a browser),</div>
<div>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.</div>
<div><br></div><div><br></div><div>My questions:</div><div>Is it safe, if every "Mobile Variant" has a Private/Public Key ???</div><div><br></div><div>The UP server keeps the private one.</div><div>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</div>
<div><br></div><div><br></div><div>The Public Key of this combo would be "coded" into the actual mobiel application...</div><div><br></div><div>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</div>
<div><br></div><div><br></div><div>So, that means EVERY installation (on the devices) would have that pbulci key...</div><div><br></div><div>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" ??</div>
<div><br></div><div><br></div><div>Note: This Private/Public key would/should be EXCLUSIVE for "device registration". And really ONLY.. :-)</div><div><br></div><div>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.</div>
<div><br></div><div><br></div><div><br></div><div>Greetings,</div><div>Matthias</div><span><font color="#888888"><div><br></div>-- <br>Matthias Wessendorf <br><br>blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>
sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a>
</font></span></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>Matthias Wessendorf <br><br>blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>
twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a>
</div>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Matthias Wessendorf <br><br>blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>
sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a>
</div>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Matthias Wessendorf <br><br>blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>
sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a>
</div>