FTA:"THAT ATTACK SOUNDS COMPLICATED! SURELY, YOU'RE BETTER OFF WITH CRYPTO THAN WITHOUT IT?
There are three misconceptions embedded in that common objection, all of them grave..."
I guess I shouldn't lock my car, either, right? After all, someone could simply break my windows and steal whatever I have inside. Or maybe, just maybe, using some protection actually is better than using no protection, provided you don't put more faith in the protection than the protection warrants. Just like I wouldn't store gold bars in my car, I wouldn't use jscrypto to protect things that were too important for that level of protection. I will, however, feel okay about keeping my sunglasses in my car, and I will feel okay about using jscrypto to send my phone number over email.
I'm glad you mentioned this because I feel it's worth a response.
When you develop protocol or infrastructure code the more general the facility is that you develop the less control you have over how the result is going to be used.
For example SSL was originally developed for the purpose of making people feel safe transmitting their credit card numbers to e-commerce websites. Credit cards (like cars) have a pretty predictable upper bound on the financial loss should this system break.
However, the SSL/TLS protocol was very general and it has grown to be used for everything under the sun today. From protecting Twitter APIs to "launch the missiles"-type critical systems.
So when you advocate a general technique like Javascript browser crypto, you don't get to qualify it with "only for stuff that really isn't worth attacking anyway". You don't know in advance what data it's going to be used for, much less what the value of that data will be to attackers in the future.
"actually, i think an honest look at the security/privacy mechanisms provided by today’s tools precisely describes a case where ‘a little better than awful’ would be preferred. my mother emailed me some bank account information just last week. there isn’t any exploit required there. security software experts have failed horribly to provide tools that actual living breathing human beings might use and this is why most of them have just given up and use hotmail.
i personally find it astounding that the kind of people who will deny this probably have an actual brand new credit card sitting in their unlocked mailbox and feel perfectly comfortable with this fact.
your information’s security is only as strong as it’s weakest link. this includes the locks on your home, your mailbox, and the granularity you shred your trash with."
This sentiment falls victim to the fallacy that something is secure because it should be secure. The commenter is right that the "security software experts" have failed to protect his mom. But Javascript cryptography doesn't care. It's still insecure. Engineering is a spectacular douchebag, but it is in charge nonetheless.
Given the option between his mom sending it unencrypted, and encrypting it with an easy-to-use extension he set up for her, why not encrypt it? Surely it can't _hurt_ an already horrible situation?
Both of these options are worse than not mailing banking information at all. Both of them are worse than encrypting properly, which, in this mom's case, means installing PGP.
Yes, in this case, bad crypto can make a bad situation worse: it can create a false sense of security.
And in the general case, bad crypto does much worse things than that. Logging in without a password. Flipping bits in a cookie to become any user on the system. Gaining admin privileges. Spoofing authorities to collect secrets from users.
Bad crypto does not care how horrible your mom has it. Engineering says, bad crypto is going to be bad no matter how hurt your feelings are.
Link me to a well written PGP tutorial that even normally experienced people can use with Gmail. Perhaps this would be more useful than all this JS Crypto.
I simply disagree on practical terms. If I have the choice between the two, I am going to make my mom encrypt it with this library. That doesn't mean I feel perfectly safe and secure about it, but I feel better than not having encrypted it at all. Much like using a car alarm - I know it cannot ultimately prevent someone from stealing my car, but it certainly weeds out all but the most persistent attackers.
Moreover, for noncritical things, like my example of fantasy football plans, this appears to be a perfectly reasonable solution.
Does anything qualify as 'real crypto'? Every implementation will always and forever have weaknesses. I don't have a problem with someone putting together a package that makes it easy to do crypto stronger than rot13 - isn't that a step forward? We'd all like GPG/PGP easy in the browser with native code, but until then, what's wrong with an intermediate step that appears to be at least pretty good and fairly easy to use? Maybe it's not enough for organizing a coup, but for keeping your fantasy football strategies a secret - why not?
Code that has been written and/or audited by cryptographers would qualify as 'real crypto.' I don't think anybody has a problem with someone putting together this package; the only problem is with the lack of a proper notice that the code hasn't been audited.
That's a fair point. The idea that it could be used "for demonstration purposes only", though, seems to go too far in that direction. It seems like a useful library, just not for organizing a coup.
I would argue that rot13 is better than unencrypted, and that this is a step up from rot13. Sure, it's imperfect, but it's still better than nothing, and while I'm only a mediocre programmer, it appears to be easy-to-use, to boot. Better-than-nothing and easy-to-use seems like something more useful than "for demonstration purposes only", don't you think?
The company I work for (who for obvious reasons I will refuse to mention) refuses to implement standard cryptographic practises in its product. Several months after starting there, and after a lot of loud complaining, I managed to get them to switch to using bcrypt instead of plaintext passwords in the backend database. Only in the next release are they switching to using TLS for logins, and even then sometimes defaulting to a clearly fucked Javascript implementation of cryptography to send the password (using public key crypto with global server key that only changes on server restart, with replay attacks galore).
The one thing I can say about the JS cryptography is that it normally protects somewhat against passive sniffing attacks, but when it's as broken as this, it doesn't even accomplish that task.
This sort of thing seems chronic in the industry, and it's dismaying.
And as we both know, the "passive sniffing attacker" is a myth. If you can sniff packets, you can intercept traffic. We don't reason about security mechanisms by tying the attackers hands behind their back.
Management made the decision that my trivial change to eliminate replay attacks was "too much effort". I am inclined to agree, since even with such a change the effort required to circumvent their entire so-called security is minimal.
Next quarter they're introducing e-commerce solutions. Dear god.
One might argue that, if an unnamed company's e-commerce solution would put a lot of people at risk, and an unnamed engineer can prove it, that unnamed engineer has an ethical obligation to discreetly report the vulnerability first to the unnamed company, then to successively more influential and more public venues (e.g. consumer protection groups, security research groups, etc.), until the company responds.
I guess I shouldn't lock my car, either, right? After all, someone could simply break my windows and steal whatever I have inside. Or maybe, just maybe, using some protection actually is better than using no protection, provided you don't put more faith in the protection than the protection warrants. Just like I wouldn't store gold bars in my car, I wouldn't use jscrypto to protect things that were too important for that level of protection. I will, however, feel okay about keeping my sunglasses in my car, and I will feel okay about using jscrypto to send my phone number over email.