Earlier quoted context omitted.
Seems like browser extensions would be the way to go. Here's the SJCL demo: http://bitwiseshiftleft.github.com/sjcl/demo/
SJCL has a bug in their RSA implementation. We're using a good bit of their code with a few changes for our web client. The idea being that we don't want to store passwords, so the webclient stores an encrpyted private key and everything sent to the server must be signed. The users id is a sha256 hash of their public key and all we keep are the public keys. Working so far in FF and Chrome, not even trying it in IE
Javascript encryption
31–40 of 63 posts
Re: Javascript encryption
#32Earlier quoted context omitted.
If your goal is to share state secrets, then no, I wouldn't suggest using JS for crypto. If your goal is to no longer be low hanging fruit for attackers, then yes, I would recommend it.
The terminus of your argument admits to using ROT13 as a cipher. Surely there's some attacker ROT13 bars. While you're at it, Base64 the "ciphertext". There are professional pentesters that can't recognize Base64 on sight! And if you want to get really tricksy, swap the Base64 alphabet around. That'll hoist that fruit up higher. In reality, no credible cryptosystem accepts the flaws I'm talking about.
Re: Javascript encryption
#33Earlier quoted context omitted.
It's worse than that. Among many other things, it's possible for any attacker with an XSS bug in any component of the DOM of that page (cached or fetched fresh) to steal keys. Modern browsers provide no way to verify the whole JS runtime to ensure that no function that your crypto depends on has been backdoored, but every JS implementation allows functions to be overridden. It's the worst possible environment to impl…
How is this any different from a XSS bug resulting in an attacker stealing the plaintext password from a form? Also, given that the client and the server trust each other and communicate securely, doesn't this just get reduced to the probability of having these bugs and nothing more?
Think of it this way: your browser contains some areas whose sole responsibility is to verify the authenticity of a remote server (SSL), and those areas are completely inaccessible from the DOM. So, basically, as long as you can trust your web browser, then you can trust the connection.
But those protections don't exist for JavaScript. An attacker could compromise your server, rewrite your JS, and you'd never notice. (No JS signing capabilities in the browser; no TOFU/POP style architecture.) An attacker could use an SQL injection on your CMS to leave a comment that uses XSS to modify your JS encryption while it's running, and you'd never notice. You could be on an unsecured network and someone could MITM rewrite your JavaScript in-flight, or, in the cases of bad JS crypto implementations (which almost every single one is), simply use a replay attack at their leisure.
There are all kinds of really neat ways to attack JavaScript.
It's true that there are also almost as many ways to attack any other authentication/encryption system, but the point with attacks against JavaScript is that JavaScript adds no extra security at all -- it is at least as vulnerable to any of these as anything else is -- and it adds a false sense of security, and it is vulnerable to things that SSL is not, and in some of the scenarios, you will get absolutely no indication that you've been compromised.
It's just security theatre.
Re: Javascript encryption
#34Earlier quoted context omitted.
It's worse than that. Among many other things, it's possible for any attacker with an XSS bug in any component of the DOM of that page (cached or fetched fresh) to steal keys. Modern browsers provide no way to verify the whole JS runtime to ensure that no function that your crypto depends on has been backdoored, but every JS implementation allows functions to be overridden. It's the worst possible environment to impl…
XSS is in your own control (as a site owner/developer), and it is less likely to happen than the user machine being infested with malware to begin with. And the malware infestation threat has never stopped anyone from advocating native (non-browser) crypto, right?.
If that is your argument, then the conclusion is wrong, because JavaScript implementations are vulnerable to everything that everything else is vulnerable to, and then some.
There is nothing that a JavaScript implementation actually protects you from.
Re: Javascript encryption
#35Earlier quoted context omitted.
... which, implementing JS crypto, you should never do.
If your goal is to share state secrets, then no, I wouldn't suggest using JS for crypto. If your goal is to no longer be low hanging fruit for attackers, then yes, I would recommend it.
Re: Javascript encryption
#36Earlier quoted context omitted.
The terminus of your argument admits to using ROT13 as a cipher. Surely there's some attacker ROT13 bars. While you're at it, Base64 the "ciphertext". There are professional pentesters that can't recognize Base64 on sight! And if you want to get really tricksy, swap the Base64 alphabet around. That'll hoist that fruit up higher. In reality, no credible cryptosystem accepts the flaws I'm talking about.
That's true, but I'm not sure everyone should be quite so defeatist as you with respect to implementing crypto. It has and can be done, after all, it just requires care beyond "hey, my PHP script outputs some HTML." The same goes for many, many aspects of programming: design, object lifecycle, memory allocation, error handling, etc. Programming is hard, and implementing crypto is no different. The difference is that…
Software development in general tolerates (and in some ways even encourages) "acceptable risk". Programmers don't often try to prove that their functions are correct and free of any potential errors. In security-related programming, you can't take the same approach.
Implementing crypto is very, very different. If you're "iterating" the design of your crypto functions, you're doing it wrong.
Re: Javascript encryption
#37Be careful: if you are using a javascript library to encrypt data, you get protection from eavesdroppers, but not from man-in-the-middle attacks. If I can alter data that you send/receive over the wire, I can simply modify your aes function calls to xor the data with a predictable sequence that I generate. The only way to prevent this that I have thought of is to store the site (which has presumably already been acqu…
Nope. Replay attacks. Piece of cake.
The number of things that JavaScript does better than SSL is 0.
Re: Javascript encryption
#38Relevant: http://rdist.root.org/2010/11/29/final-post-on-javascript-cr... The killer for me has always been #7 on Nate Lawson's list: Auditability. How do you tell that your browser is using the right copy of the code to do the crypto?
Re: Javascript encryption
#39Could anyone explain what's the use case for encrypting text on a web page using JavaScript? I don't understand how this library is useful except for situation when used in Chrome extensions like the one used by LastPass. If this lib is used on a page to decrypt/encrypt user data before sending to the server, theoretically it's possible for the host to steal private key simply by injecting a JS code that copies user'…
Suppose you want to store confidential data with the server. You trust the server owners to be the good guys, but you also know that data breaches happen (e.g. equipment theft, FBI seizures, backup tape leaks), so if/when the breach happens the thieves will have made off with encrypted copy of your data. The only way your data is jeopardized is one of the two cases: 1. The people maintaining the service turned out to…
How is this a justification for JavaScript crypto? It might be a justification for some form of crypto, but if that's the case, why not stick with SSL + server-side encryption?
Re: Javascript encryption
#40Earlier quoted context omitted.
Suppose you want to store confidential data with the server. You trust the server owners to be the good guys, but you also know that data breaches happen (e.g. equipment theft, FBI seizures, backup tape leaks), so if/when the breach happens the thieves will have made off with encrypted copy of your data. The only way your data is jeopardized is one of the two cases: 1. The people maintaining the service turned out to…
Exactly. You can never be completely secure, but this mitigates against a large amount of potential problems.
"You can never be completely secure" is not a good justification for security theatre.