3 ms·

The only problem here is that because the Javascript is delivered by the server which is supposedly offering privacy from itself, nothing is stopping the develo

The only problem here is that because the Javascript is delivered by the server which is supposedly offering privacy from itself, nothing is stopping the developers from simply changing the Javascript and stripping away the encryption through either capturing keys or not applying it in the first place. see: http://www.matasano.com/articles/javascript-cryptography/ http://www.matasano.com/articles/javascript-cryptography/

rarrrrrr 14y ago
Of course, but that's not the threat model we're protecting against. Note that we link to that article (and agree with it!) in the discussion. This isn't just for browser based products. The reference implementation is in JS and intended for packaged HTML5 mobile apps, and we'll follow with implementations in C, Python, Java, etc.
- tptacek 14y ago
  You say it's appropriate for browser apps on the the landing page.
  - rarrrrrr 14y ago
    In the browser app scenario, we also declare on that very same page that the threat model is explicitly this: you're an application provider who doesn't want the liability of having a database of plaintext user supplied content. (I.e. protecting a business from its customers' activities.) Not the other way around.
    - alexjeffrey 14y ago
      Nonetheless you do have at least some liability because if your server is compromised for long enough for one or more users to sign in, their details could be captured using modified Javascript and used to decrypt their private data. It does provide protection against hackers stealing the whole database in one shot though.
jacques_chester 14y ago
Javascript replacement is a problem with every single scheme that relies on the browser being an active participant. I know this because I designed such a scheme and it was hilariously, fantastically broken.
- xur17 14y ago
  This is the problem I have with Lastpass - someone could hack their servers, replace the javascript encryption file to send the decryption password to their server, and get all of your passwords.
  - gws 14y ago
    you are talking about web access from a public computer I suppose? if you are connecting from your computer then I suppose the decryption happens in the browser extension and you are safe from the scenario you describe, or am I missing something?
    - xur17 14y ago
      I am talking about either situation. Someone could hack their site (angry employee, outside person, etc), and modify the code to send the decryption password to their server. This would work for either situation since the person could push an update out for the browser extension. I'm sure they are very careful about the security of their system, but they are still one step away from having all of your passwords (a simple extension update, or site javascript modification). If I use a program like keepassx, I know when it's updated, and can verify that it doesn't attempt to communicate with a remote server.
- infodroid 14y ago
  Do you think this can be remedied by moving the code out of the web container? Cryptocat moved away from delivering its crypto code over JS to a browser plugin: http://www.forbes.com/sites/jonmatonis/2012/07/30/cryptocat-increases-security-in-move-away-from-javascript-encryption/ http://www.forbes.com/sites/jonmatonis/2012/07/30/cryptocat-... Do you think a dedicated native client would work? Something like a lightweight site-specific browser with Crypton libs. The same way you can appify sites with Chrome.

rarrrrrr 14y ago

Of course, but that's not the threat model we're protecting against. Note that we link to that article (and agree with it!) in the discussion. This isn't just for browser based products. The reference implementation is in JS and intended for packaged HTML5 mobile apps, and we'll follow with implementations in C, Python, Java, etc.

tptacek 14y ago
You say it's appropriate for browser apps on the the landing page.
- rarrrrrr 14y ago
  In the browser app scenario, we also declare on that very same page that the threat model is explicitly this: you're an application provider who doesn't want the liability of having a database of plaintext user supplied content. (I.e. protecting a business from its customers' activities.) Not the other way around.
  - alexjeffrey 14y ago
    Nonetheless you do have at least some liability because if your server is compromised for long enough for one or more users to sign in, their details could be captured using modified Javascript and used to decrypt their private data. It does provide protection against hackers stealing the whole database in one shot though.

jacques_chester 14y ago

Javascript replacement is a problem with every single scheme that relies on the browser being an active participant. I know this because I designed such a scheme and it was hilariously, fantastically broken.

xur17 14y ago
This is the problem I have with Lastpass - someone could hack their servers, replace the javascript encryption file to send the decryption password to their server, and get all of your passwords.
- gws 14y ago
  you are talking about web access from a public computer I suppose? if you are connecting from your computer then I suppose the decryption happens in the browser extension and you are safe from the scenario you describe, or am I missing something?
  - xur17 14y ago
    I am talking about either situation. Someone could hack their site (angry employee, outside person, etc), and modify the code to send the decryption password to their server. This would work for either situation since the person could push an update out for the browser extension. I'm sure they are very careful about the security of their system, but they are still one step away from having all of your passwords (a simple extension update, or site javascript modification). If I use a program like keepassx, I know when it's updated, and can verify that it doesn't attempt to communicate with a remote server.
infodroid 14y ago
Do you think this can be remedied by moving the code out of the web container? Cryptocat moved away from delivering its crypto code over JS to a browser plugin: http://www.forbes.com/sites/jonmatonis/2012/07/30/cryptocat-increases-security-in-move-away-from-javascript-encryption/ http://www.forbes.com/sites/jonmatonis/2012/07/30/cryptocat-... Do you think a dedicated native client would work? Something like a lightweight site-specific browser with Crypton libs. The same way you can appify sites with Chrome.