So I'm trying to figure out what we gain from this … now instead of putting your variantID in the JS, you are putting the variantID and a secret in the JS. I don't see any security gain here so trying to figure out what we gain. On Jun 20, 2013, at 10:12 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > Hi, > > with the use of this helper, it is "safe" (I think) to use the window.btoa function(see details), to perform a (simple) Base64 encoding. > > Base64 encoding is required, since the "Device Registration" HTTP REST endpoint now uses HTTP_Basic (for details see the matching thread). > > Currently we perform this code for "channel registration": > > $.ajax({ > contentType: "application/json", > dataType: "json", > type: "POST", > url: url, > headers: { > "ag-mobile-variant": variantID > }, > data: JSON.stringify({ > category: messageType, > deviceToken: endpoint.channelID, > clientIdentifier: alias > }) > }); > As mentioned on the "Security thread", the variantID is no longer a header, it is part of the HTTP_Basic auth process. > > This is a (local) JavaScript change that I did. It works fine so far: > > $.ajax({ > contentType: "application/json", > dataType: "json", > type: "POST", > crossDomain: true, > url: url, > headers: { > "Authorization": "Basic " + window.btoa(variantID + ":" + secret) > }, > data: JSON.stringify({ > category: messageType, > deviceToken: endpoint.channelID, > alias: alias ///// NOTE:: the key has changed.......... > }) > }); > The important thing: we add the "Authorization": "Basic " header and using the mentionedwindow.btoa() function for the actual encoding. > > The same applies for the DELETE (unregistration). > > Any thoughts? Otherwise, I'd send a PR. > > Ah.... the dependency agains the Base64.js polyfill library would/should be included in our "grunt" build for "distribution", or would it be "just" declared (yeah, that's details but asking for curiousity) > > -- > 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

Hi, with the use of this helper <https://github.com/davidchambers/Base64.js>;, it is "safe" (I think) to use the |window.btoa| function(see details <https://developer.mozilla.org/en-US/docs/Web/API/window.btoa>), to perform a (simple) Base64 encoding. Base64 encoding is required, since the "Device Registration" HTTP REST endpoint now uses HTTP_Basic (for details see the matching thread <http://lists.jboss.org/pipermail/aerogear-dev/2013-June/003233.html>). Currently we perform this code for "channel registration": |$.ajax({ contentType:"application/json", dataType:"json", type:"POST", url: url, headers: { "ag-mobile-variant": variantID }, data: JSON.stringify({ category: messageType, deviceToken: endpoint.channelID, clientIdentifier: alias }) }); | As mentioned on the "Security thread", the |variantID| is no longer a header, it is part of the HTTP_Basic auth process. This is a (local) JavaScript change that I did. It works fine so far: |$.ajax({ contentType:"application/json", dataType:"json", type:"POST", crossDomain: true, url: url, headers: { "Authorization":"Basic" + window.btoa(variantID +":" + secret) }, data: JSON.stringify({ category: messageType, deviceToken: endpoint.channelID, alias: alias ///// NOTE:: the key has changed.......... }) }); | The important thing: we add the |"Authorization": "Basic "| header and using the mentioned|window.btoa()| function for the actual encoding. The same applies for the |DELETE| (unregistration). Any thoughts? Otherwise, I'd send a PR. Ah.... the dependency agains the |Base64.js| polyfill library would/should be included in our "grunt" build for "distribution", or would it be "just" declared (yeah, that's details but asking for curiousity) -- 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

Just one addition http://tools.ietf.org/html/rfc2617#section-4

Bruno Oliveira wrote: > Don't feel safe because you're doing something with Base64 or using > basic authentication. It doesn't guarantee safety, the HTTP Basic > Authentication scheme is not considered a secure method without TLS/SSL, > because username and password are passed over the network in cleartext. > > For this reason we will replace it with Digest or Hawk into the near > future. > > Matthias Wessendorf wrote: >> Hi, >> >> with the use of this helper >> <https://github.com/davidchambers/Base64.js>;, it is "safe" (I think) to >> use the |window.btoa| function(see details >> <https://developer.mozilla.org/en-US/docs/Web/API/window.btoa>), to >> perform a (simple) Base64 encoding. >> >> Base64 encoding is required, since the "Device Registration" HTTP REST >> endpoint now uses HTTP_Basic (for details see the matching thread >> <http://lists.jboss.org/pipermail/aerogear-dev/2013-June/003233.html>). >> >> Currently we perform this code for "channel registration": >> >> |$.ajax({ >> contentType:"application/json", >> dataType:"json", >> type:"POST", >> url: url, >> headers: { >> "ag-mobile-variant": variantID >> }, >> data: JSON.stringify({ >> category: messageType, >> deviceToken: endpoint.channelID, >> clientIdentifier: alias >> }) >> }); >> | >> >> As mentioned on the "Security thread", the |variantID| is no longer a >> header, it is part of the HTTP_Basic auth process. >> >> This is a (local) JavaScript change that I did. It works fine so far: >> >> |$.ajax({ >> contentType:"application/json", >> dataType:"json", >> type:"POST", >> crossDomain: true, >> url: url, >> headers: { >> "Authorization":"Basic" + window.btoa(variantID +":" + secret) >> }, >> data: JSON.stringify({ >> category: messageType, >> deviceToken: endpoint.channelID, >> alias: alias ///// NOTE:: the key has changed.......... >> }) >> }); >> | >> >> The important thing: we add the |"Authorization": "Basic "| header and >> using the mentioned|window.btoa()| function for the actual encoding. >> >> The same applies for the |DELETE| (unregistration). >> >> Any thoughts? Otherwise, I'd send a PR. >> >> Ah.... the dependency agains the |Base64.js| polyfill library >> would/should be included in our "grunt" build for "distribution", or >> would it be "just" declared (yeah, that's details but asking for >> curiousity) >> >> >> -- >> 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 > -- abstractj _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Thu, Jun 20, 2013 at 5:32 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: On Jun 20, 2013, at 10:28 AM, Bruno Oliveira <bruno(a)abstractj.org&gt; wrote: > Just one addition http://tools.ietf.org/html/rfc2617#section-4 Right … even on the iOS and Android side of things, it is still very easy to "decrypt" a base64 encoded string. Using HTTPS would help but that is not foolproof either so we may want to think of some other method. sure - and nothing new here :) But better than nothing, for now

> > Bruno Oliveira wrote: >> Don't feel safe because you're doing something with Base64 or using >> basic authentication. It doesn't guarantee safety, the HTTP Basic >> Authentication scheme is not considered a secure method without TLS/SSL, >> because username and password are passed over the network in cleartext. >> >> For this reason we will replace it with Digest or Hawk into the near >> future. >> >> Matthias Wessendorf wrote: >>> Hi, >>> >>> with the use of this helper >>> <https://github.com/davidchambers/Base64.js>;, it is "safe" (I think) to >>> use the |window.btoa| function(see details >>> <https://developer.mozilla.org/en-US/docs/Web/API/window.btoa>), to >>> perform a (simple) Base64 encoding. >>> >>> Base64 encoding is required, since the "Device Registration" HTTP REST >>> endpoint now uses HTTP_Basic (for details see the matching thread >>> <http://lists.jboss.org/pipermail/aerogear-dev/2013-June/003233.html>). >>> >>> Currently we perform this code for "channel registration": >>> >>> |$.ajax({ >>> contentType:"application/json", >>> dataType:"json", >>> type:"POST", >>> url: url, >>> headers: { >>> "ag-mobile-variant": variantID >>> }, >>> data: JSON.stringify({ >>> category: messageType, >>> deviceToken: endpoint.channelID, >>> clientIdentifier: alias >>> }) >>> }); >>> | >>> >>> As mentioned on the "Security thread", the |variantID| is no longer a >>> header, it is part of the HTTP_Basic auth process. >>> >>> This is a (local) JavaScript change that I did. It works fine so far: >>> >>> |$.ajax({ >>> contentType:"application/json", >>> dataType:"json", >>> type:"POST", >>> crossDomain: true, >>> url: url, >>> headers: { >>> "Authorization":"Basic" + window.btoa(variantID +":" + secret) >>> }, >>> data: JSON.stringify({ >>> category: messageType, >>> deviceToken: endpoint.channelID, >>> alias: alias ///// NOTE:: the key has changed.......... >>> }) >>> }); >>> | >>> >>> The important thing: we add the |"Authorization": "Basic "| header and >>> using the mentioned|window.btoa()| function for the actual encoding. >>> >>> The same applies for the |DELETE| (unregistration). >>> >>> Any thoughts? Otherwise, I'd send a PR. >>> >>> Ah.... the dependency agains the |Base64.js| polyfill library >>> would/should be included in our "grunt" build for "distribution", or >>> would it be "just" declared (yeah, that's details but asking for >>> curiousity) >>> >>> >>> -- >>> 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 >> > > -- > abstractj > > _______________________________________________ > 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 _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Thu, Jun 20, 2013 at 5:46 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: > > On Jun 20, 2013, at 10:34 AM, Matthias Wessendorf <matzew(a)apache.org&gt; > wrote: > > > > > On Thu, Jun 20, 2013 at 5:32 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: > >> >> On Jun 20, 2013, at 10:28 AM, Bruno Oliveira <bruno(a)abstractj.org&gt; >> wrote: >> >> > Just one addition http://tools.ietf.org/html/rfc2617#section-4 >> >> Right … even on the iOS and Android side of things, it is still very >> easy to "decrypt" a base64 encoded string. Using HTTPS would help but that >> is not foolproof either so we may want to think of some other method. >> > > > sure - and nothing new here :) > But better than nothing, for now > > > Not sure I agree … seems like a waste if we know we won't use it in the > future. Might as well have Bruno working on something real and get that in > for August rather than just sitting on something that isn't right. > Ok,.. should I remove the security work I did ? wondering why there was no feedback on the actual thread > > > >> > >> > Bruno Oliveira wrote: >> >> Don't feel safe because you're doing something with Base64 or using >> >> basic authentication. It doesn't guarantee safety, the HTTP Basic >> >> Authentication scheme is not considered a secure method without >> TLS/SSL, >> >> because username and password are passed over the network in >> cleartext. >> >> >> >> For this reason we will replace it with Digest or Hawk into the near >> >> future. >> >> >> >> Matthias Wessendorf wrote: >> >>> Hi, >> >>> >> >>> with the use of this helper >> >>> <https://github.com/davidchambers/Base64.js>;, it is "safe" (I >> think) to >> >>> use the |window.btoa| function(see details >> >>> <https://developer.mozilla.org/en-US/docs/Web/API/window.btoa>), to >> >>> perform a (simple) Base64 encoding. >> >>> >> >>> Base64 encoding is required, since the "Device Registration" HTTP >> REST >> >>> endpoint now uses HTTP_Basic (for details see the matching thread >> >>> <http://lists.jboss.org/pipermail/aerogear-dev/2013-June/003233.html >> >). >> >>> >> >>> Currently we perform this code for "channel registration": >> >>> >> >>> |$.ajax({ >> >>> contentType:"application/json", >> >>> dataType:"json", >> >>> type:"POST", >> >>> url: url, >> >>> headers: { >> >>> "ag-mobile-variant": variantID >> >>> }, >> >>> data: JSON.stringify({ >> >>> category: messageType, >> >>> deviceToken: endpoint.channelID, >> >>> clientIdentifier: alias >> >>> }) >> >>> }); >> >>> | >> >>> >> >>> As mentioned on the "Security thread", the |variantID| is no longer a >> >>> header, it is part of the HTTP_Basic auth process. >> >>> >> >>> This is a (local) JavaScript change that I did. It works fine so far: >> >>> >> >>> |$.ajax({ >> >>> contentType:"application/json", >> >>> dataType:"json", >> >>> type:"POST", >> >>> crossDomain: true, >> >>> url: url, >> >>> headers: { >> >>> "Authorization":"Basic" + window.btoa(variantID +":" + secret) >> >>> }, >> >>> data: JSON.stringify({ >> >>> category: messageType, >> >>> deviceToken: endpoint.channelID, >> >>> alias: alias ///// NOTE:: the key has changed.......... >> >>> }) >> >>> }); >> >>> | >> >>> >> >>> The important thing: we add the |"Authorization": "Basic "| header >> and >> >>> using the mentioned|window.btoa()| function for the actual encoding. >> >>> >> >>> The same applies for the |DELETE| (unregistration). >> >>> >> >>> Any thoughts? Otherwise, I'd send a PR. >> >>> >> >>> Ah.... the dependency agains the |Base64.js| polyfill library >> >>> would/should be included in our "grunt" build for "distribution", or >> >>> would it be "just" declared (yeah, that's details but asking for >> >>> curiousity) >> >>> >> >>> >> >>> -- >> >>> 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 >> >> >> > >> > -- >> > abstractj >> > >> > _______________________________________________ >> > 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 > _______________________________________________ > 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

On Jun 20, 2013, at 10:49 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: On Thu, Jun 20, 2013 at 5:46 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: > > On Jun 20, 2013, at 10:34 AM, Matthias Wessendorf <matzew(a)apache.org&gt; > wrote: > > > > > On Thu, Jun 20, 2013 at 5:32 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: > >> >> On Jun 20, 2013, at 10:28 AM, Bruno Oliveira <bruno(a)abstractj.org&gt; >> wrote: >> >> > Just one addition http://tools.ietf.org/html/rfc2617#section-4 >> >> Right … even on the iOS and Android side of things, it is still very >> easy to "decrypt" a base64 encoded string. Using HTTPS would help but that >> is not foolproof either so we may want to think of some other method. >> > > > sure - and nothing new here :) > But better than nothing, for now > > > Not sure I agree … seems like a waste if we know we won't use it in the > future. Might as well have Bruno working on something real and get that in > for August rather than just sitting on something that isn't right. > Ok,.. should I remove the security work I did ? wondering why there was no feedback on the actual thread Not sure which thread but honestly it's hard to respond to everything. I try to read and respond but I'm working on lots of things other than push right now so I'll admit that I skim through a lot of the multiple MLs I subscribe to in order to be able to actually get work done. Otherwise I could end up just reading/replying to e-mail all day.

> > > >> > >> > Bruno Oliveira wrote: >> >> Don't feel safe because you're doing something with Base64 or using >> >> basic authentication. It doesn't guarantee safety, the HTTP Basic >> >> Authentication scheme is not considered a secure method without >> TLS/SSL, >> >> because username and password are passed over the network in >> cleartext. >> >> >> >> For this reason we will replace it with Digest or Hawk into the near >> >> future. >> >> >> >> Matthias Wessendorf wrote: >> >>> Hi, >> >>> >> >>> with the use of this helper >> >>> <https://github.com/davidchambers/Base64.js>;, it is "safe" (I >> think) to >> >>> use the |window.btoa| function(see details >> >>> <https://developer.mozilla.org/en-US/docs/Web/API/window.btoa>), to >> >>> perform a (simple) Base64 encoding. >> >>> >> >>> Base64 encoding is required, since the "Device Registration" HTTP >> REST >> >>> endpoint now uses HTTP_Basic (for details see the matching thread >> >>> <http://lists.jboss.org/pipermail/aerogear-dev/2013-June/003233.html >> >). >> >>> >> >>> Currently we perform this code for "channel registration": >> >>> >> >>> |$.ajax({ >> >>> contentType:"application/json", >> >>> dataType:"json", >> >>> type:"POST", >> >>> url: url, >> >>> headers: { >> >>> "ag-mobile-variant": variantID >> >>> }, >> >>> data: JSON.stringify({ >> >>> category: messageType, >> >>> deviceToken: endpoint.channelID, >> >>> clientIdentifier: alias >> >>> }) >> >>> }); >> >>> | >> >>> >> >>> As mentioned on the "Security thread", the |variantID| is no longer a >> >>> header, it is part of the HTTP_Basic auth process. >> >>> >> >>> This is a (local) JavaScript change that I did. It works fine so far: >> >>> >> >>> |$.ajax({ >> >>> contentType:"application/json", >> >>> dataType:"json", >> >>> type:"POST", >> >>> crossDomain: true, >> >>> url: url, >> >>> headers: { >> >>> "Authorization":"Basic" + window.btoa(variantID +":" + secret) >> >>> }, >> >>> data: JSON.stringify({ >> >>> category: messageType, >> >>> deviceToken: endpoint.channelID, >> >>> alias: alias ///// NOTE:: the key has changed.......... >> >>> }) >> >>> }); >> >>> | >> >>> >> >>> The important thing: we add the |"Authorization": "Basic "| header >> and >> >>> using the mentioned|window.btoa()| function for the actual encoding. >> >>> >> >>> The same applies for the |DELETE| (unregistration). >> >>> >> >>> Any thoughts? Otherwise, I'd send a PR. >> >>> >> >>> Ah.... the dependency agains the |Base64.js| polyfill library >> >>> would/should be included in our "grunt" build for "distribution", or >> >>> would it be "just" declared (yeah, that's details but asking for >> >>> curiousity) >> >>> >> >>> >> >>> -- >> >>> 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 >> >> >> > >> > -- >> > abstractj >> > >> > _______________________________________________ >> > 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 > _______________________________________________ > 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 _______________________________________________ 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

On Jun 20, 2013, at 10:56 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: On Thu, Jun 20, 2013 at 5:54 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: > > On Jun 20, 2013, at 10:49 AM, Matthias Wessendorf <matzew(a)apache.org&gt; > wrote: > > > > > On Thu, Jun 20, 2013 at 5:46 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: > >> >> On Jun 20, 2013, at 10:34 AM, Matthias Wessendorf <matzew(a)apache.org&gt; >> wrote: >> >> >> >> >> On Thu, Jun 20, 2013 at 5:32 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: >> >>> >>> On Jun 20, 2013, at 10:28 AM, Bruno Oliveira <bruno(a)abstractj.org&gt; >>> wrote: >>> >>> > Just one addition http://tools.ietf.org/html/rfc2617#section-4 >>> >>> Right … even on the iOS and Android side of things, it is still very >>> easy to "decrypt" a base64 encoded string. Using HTTPS would help but that >>> is not foolproof either so we may want to think of some other method. >>> >> >> >> sure - and nothing new here :) >> But better than nothing, for now >> >> >> Not sure I agree … seems like a waste if we know we won't use it in the >> future. Might as well have Bruno working on something real and get that in >> for August rather than just sitting on something that isn't right. >> > > Ok,.. should I remove the security work I did ? wondering why there was > no feedback on the actual thread > > > Not sure which thread but honestly it's hard to respond to everything. I > try to read and respond but I'm working on lots of things other than push > right now so I'll admit that I skim through a lot of the multiple MLs I > subscribe to in order to be able to actually get work done. Otherwise I > could end up just reading/replying to e-mail all day. > Ok. I have two options: * keep the http_basic, and improve in the next weeks I guess keep it if you're not removing it for the other clients. The JS client will need to be updated.

* remove the http_basic for SimplePush, and wait for something real there. -Matthias > > > > >> >> >> >>> > >>> > Bruno Oliveira wrote: >>> >> Don't feel safe because you're doing something with Base64 or using >>> >> basic authentication. It doesn't guarantee safety, the HTTP Basic >>> >> Authentication scheme is not considered a secure method without >>> TLS/SSL, >>> >> because username and password are passed over the network in >>> cleartext. >>> >> >>> >> For this reason we will replace it with Digest or Hawk into the near >>> >> future. >>> >> >>> >> Matthias Wessendorf wrote: >>> >>> Hi, >>> >>> >>> >>> with the use of this helper >>> >>> <https://github.com/davidchambers/Base64.js>;, it is "safe" (I >>> think) to >>> >>> use the |window.btoa| function(see details >>> >>> <https://developer.mozilla.org/en-US/docs/Web/API/window.btoa>), to >>> >>> perform a (simple) Base64 encoding. >>> >>> >>> >>> Base64 encoding is required, since the "Device Registration" HTTP >>> REST >>> >>> endpoint now uses HTTP_Basic (for details see the matching thread >>> >>> < >>> http://lists.jboss.org/pipermail/aerogear-dev/2013-June/003233.html>). >>> >>> >>> >>> Currently we perform this code for "channel registration": >>> >>> >>> >>> |$.ajax({ >>> >>> contentType:"application/json", >>> >>> dataType:"json", >>> >>> type:"POST", >>> >>> url: url, >>> >>> headers: { >>> >>> "ag-mobile-variant": variantID >>> >>> }, >>> >>> data: JSON.stringify({ >>> >>> category: messageType, >>> >>> deviceToken: endpoint.channelID, >>> >>> clientIdentifier: alias >>> >>> }) >>> >>> }); >>> >>> | >>> >>> >>> >>> As mentioned on the "Security thread", the |variantID| is no longer >>> a >>> >>> header, it is part of the HTTP_Basic auth process. >>> >>> >>> >>> This is a (local) JavaScript change that I did. It works fine so >>> far: >>> >>> >>> >>> |$.ajax({ >>> >>> contentType:"application/json", >>> >>> dataType:"json", >>> >>> type:"POST", >>> >>> crossDomain: true, >>> >>> url: url, >>> >>> headers: { >>> >>> "Authorization":"Basic" + window.btoa(variantID +":" + secret) >>> >>> }, >>> >>> data: JSON.stringify({ >>> >>> category: messageType, >>> >>> deviceToken: endpoint.channelID, >>> >>> alias: alias ///// NOTE:: the key has changed.......... >>> >>> }) >>> >>> }); >>> >>> | >>> >>> >>> >>> The important thing: we add the |"Authorization": "Basic "| header >>> and >>> >>> using the mentioned|window.btoa()| function for the actual encoding. >>> >>> >>> >>> The same applies for the |DELETE| (unregistration). >>> >>> >>> >>> Any thoughts? Otherwise, I'd send a PR. >>> >>> >>> >>> Ah.... the dependency agains the |Base64.js| polyfill library >>> >>> would/should be included in our "grunt" build for "distribution", or >>> >>> would it be "just" declared (yeah, that's details but asking for >>> >>> curiousity) >>> >>> >>> >>> >>> >>> -- >>> >>> 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 >>> >> >>> > >>> > -- >>> > abstractj >>> > >>> > _______________________________________________ >>> > 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 >> _______________________________________________ >> 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 > _______________________________________________ > 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 _______________________________________________ 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

Right … even on the iOS and Android side of things, it is still very easy to "decrypt" a base64 encoded string. Using HTTPS would help but that is not foolproof either so we may want to think of some other method.