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

Reply via email to