The members of the group involved in those mobile apps are pretty savvy. But you are right, a web app dev might be a better choice for you to talk to, or a secure plugin.
-tim On 5/26/14, Apostolis Xekoukoulotakis <[email protected]> wrote: > Someone else to ask or any more advice. The URL you gave me is for mobile > apps. > > By the way, what was your app and what problems did it have? > On May 27, 2014 3:19 AM, "Tim Prepscius" <[email protected]> wrote: > >> I would strongly suggest you spend more time initially getting feed >> back on your idea rather than implementing it. >> >> It is a hard lesson that I personally learnt in my last project. >> >> Good luck to you, >> >> -tim >> >> On 5/26/14, Apostolis Xekoukoulotakis <[email protected]> wrote: >> > Thanks for the info. I have some responses inline. >> > >> > Now I am going to implement CSP as proposed by Felix's url. The good >> thing >> > with websockets is that they don't rely on jsonp to send cross-origin >> data. >> > So i can disable all scripts both inline and from any other source >> > except >> > 127.0.0.1 and still receive data from websockets. >> > >> > 2014-05-23 3:11 GMT+03:00 Tim Prepscius <[email protected]>: >> > >> >> You might also try posting to the guardian dev mailing list >> >> >> >> https://guardianproject.info >> >> >> >> They have a bunch of experience, possibly could give valuable >> >> information. >> >> >> >> -tim >> >> >> >> >> >> On 5/22/14, Tim Prepscius <[email protected]> wrote: >> >> > Interesting. >> >> > >> >> > I'm not sure if the approach you are describing is a good one or >> >> > not. >> >> > In some ways, you are opening yourself up to attacks >> >> > that might not exist if everything was packaged together. >> >> > >> >> > >> >> > >> >> > Some things to think about: >> >> > >> >> > I do not need to compromise your client to get to the 127.0.0.1 web >> >> > server. I can use any web page the user visits. >> >> > >> >> >> > I use cookie authentication and have set socket.io to reject >> cross-origin >> > requests. >> > >> > >> >> > If I discover a bug in the 127.0.0.1 web server, I could use that to >> >> > keep track of the client in the web browser. (I'm assuming that >> >> > basically data is passing remote-server -> web-client -> >> >> > localhost-server -> web-client) >> >> >> >> Yes this is the data path but only for important staff that require >> > encryption . >> > Well if there is a bug in the server, we are screwed anyway. >> > >> > >> >> > The web browsers, I believe, do SHAs of plugins, packaged items, >> >> > before running them. While this might not be "real security," it >> >> > might be more secure than a web server resides on disk and is never >> >> > fully sha'd. In theory, the security of let's say OSX, passes from >> >> > the security chip to the operating system, which should, but >> >> > doesn't, >> >> > check the Chrome, which then checks the plugin. >> >> > >> >> > How are you going to update your 127.0.0.1 web server. How are you >> >> > going to prevent your web server from being updated by a malicious >> >> > actor. >> >> > >> >> >> > I dont really know exactly. I would definitely sign my package. >> > >> > >> >> > >> >> > >> >> > These came to me off the top of my head. Their worth is dubious! >> >> > ;-) >> >> > >> >> > Good luck! >> >> > >> >> > -tim >> >> > >> >> > >> >> > >> >> > On 5/22/14, Apostolis Xekoukoulotakis <[email protected]> wrote: >> >> >> So there will be 2 servers, one local per client and one global >> server >> >> >> that >> >> >> provides content(json). >> >> >> >> >> >> >> >> >> 2014-05-23 2:44 GMT+03:00 Apostolis Xekoukoulotakis >> >> >> <[email protected] >> >> >: >> >> >> >> >> >>> Yes!! actually I'll use socket.io. >> >> >>> >> >> >>> >> >> >>> 2014-05-23 2:42 GMT+03:00 Tim Prepscius <[email protected]>: >> >> >>> >> >> >>> Can you describe what you mean by: >> >> >>>> >> >> >>>> the attacker will still not have the private key since all >> >> >>>> cryptography happen in the nodejs of the user. >> >> >>>> >> >> >>>> It seems as though you are saying that there will be a web server >> >> >>>> running client side, from which the web app will make ajax calls >> to. >> >> >>>> Is this what you mean? >> >> >>>> >> >> >>>> On 5/22/14, Apostolis Xekoukoulotakis <[email protected]> wrote: >> >> >>>> > Thanks Felix. Your advice is sound. I am going to look at your >> >> >>>> references. >> >> >>>> > >> >> >>>> > So my app is indeed packaged but I don't use node-webkit. In my >> >> case, >> >> >>>> > if >> >> >>>> > the client is compromised in the browser, the attacker will >> >> >>>> > still >> >> not >> >> >>>> have >> >> >>>> > the private key since all cryptography happen in the nodejs of >> the >> >> >>>> > user. >> >> >>>> > >> >> >>>> > But he would be able to ask the server to sign arbitrary >> documents >> >> >>>> which is >> >> >>>> > still really bad. >> >> >>>> > On May 22, 2014 11:33 AM, "Felix Hammerl" < >> [email protected]> >> >> >>>> wrote: >> >> >>>> > >> >> >>>> >> Hi, >> >> >>>> >> >> >> >>>> >> you have to trust the server in a host-based security setting. >> If >> >> >>>> >> you >> >> >>>> >> want >> >> >>>> >> to mitigate that, have you considered packaged (not hosted!) >> >> >>>> >> apps? >> >> >>>> Check >> >> >>>> >> out Chrome Apps, Firefox Apps, node-webkit, atom-shell, ... >> >> >>>> >> It all boils down to what you threat model is. Also, you >> probably >> >> >>>> >> don't >> >> >>>> >> want to roll your own authentication mechanism. You also might >> >> >>>> >> want >> >> >>>> >> to >> >> >>>> >> avoid doing funky stuff with removing the script sources and >> >> loading >> >> >>>> them >> >> >>>> >> from arbitrary locations... >> >> >>>> >> Recommended read for js security and threat models (be sure to >> >> check >> >> >>>> out >> >> >>>> >> the discussion, too!): >> >> >>>> >> >> >> http://tankredhase.com/2014/04/13/heartbleed-and-javascript-crypto/ >> >> >>>> >> >> >> >>>> >> >> >> >>>> >> Cheers >> >> >>>> >> Felix >> >> >>>> >> >> >> >>>> >> >> >> >>>> >> On Wed, May 21, 2014 at 7:57 PM, Apostolis Xekoukoulotakis < >> >> >>>> >> [email protected]> wrote: >> >> >>>> >> >> >> >>>> >>> Hello everyone. I am thinking of using openpgp as an >> >> authentication >> >> >>>> >>> mechanism form my site and more. Send a random number to the >> >> >>>> >>> client, >> >> >>>> the >> >> >>>> >>> sessionId, which he then has to sign and send back. >> >> >>>> >>> >> >> >>>> >>> I was also worried that if someone could attack my server, he >> >> could >> >> >>>> send >> >> >>>> >>> arbitrary js code to the client and thus all clients would be >> >> >>>> >>> compromised. >> >> >>>> >>> So I decided to create a nodejs app that users would have to >> >> >>>> >>> install >> >> >>>> >>> locally that would provide them those js scripts. >> >> >>>> >>> >> >> >>>> >>> They would only have to contact the server for content. So >> >> >>>> >>> now >> I >> >> am >> >> >>>> >>> worried about someone injecting js code into the content. >> >> >>>> >>> If I wrote a parser that removed script tags, I suppose this >> >> >>>> >>> would >> >> >>>> >>> be >> >> >>>> >>> secure, right? >> >> >>>> >>> >> >> >>>> >>> The apps goal is to let users issue new currencies, that is >> >> >>>> >>> why >> >> >>>> >>> is >> >> >>>> >>> security is very important. >> >> >>>> >>> >> >> >>>> >>> _______________________________________________ >> >> >>>> >>> >> >> >>>> >>> http://openpgpjs.org >> >> >>>> >>> Subscribe/unsubscribe: http://list.openpgpjs.org >> >> >>>> >>> >> >> >>>> >> >> >> >>>> >> >> >> >>>> >> _______________________________________________ >> >> >>>> >> >> >> >>>> >> http://openpgpjs.org >> >> >>>> >> Subscribe/unsubscribe: http://list.openpgpjs.org >> >> >>>> >> >> >> >>>> > >> >> >>>> _______________________________________________ >> >> >>>> >> >> >>>> http://openpgpjs.org >> >> >>>> Subscribe/unsubscribe: http://list.openpgpjs.org >> >> >>>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> -- >> >> >>> >> >> >>> >> >> >>> Sincerely yours, >> >> >>> >> >> >>> Apostolis Xekoukoulotakis >> >> >>> >> >> >>> >> >> >> >> >> >> >> >> >> -- >> >> >> >> >> >> >> >> >> Sincerely yours, >> >> >> >> >> >> Apostolis Xekoukoulotakis >> >> >> >> >> > >> >> _______________________________________________ >> >> >> >> http://openpgpjs.org >> >> Subscribe/unsubscribe: http://list.openpgpjs.org >> >> >> > >> > >> > >> > -- >> > >> > >> > Sincerely yours, >> > >> > Apostolis Xekoukoulotakis >> > >> _______________________________________________ >> >> http://openpgpjs.org >> Subscribe/unsubscribe: http://list.openpgpjs.org >> > _______________________________________________ http://openpgpjs.org Subscribe/unsubscribe: http://list.openpgpjs.org
