Comment by wonnage | Hacker News Reader

Comment by wonnage | Hacker News Reader

Security is a series of tradeoffs. Remember the Debian SSL fiasco? Turns out even when every Debian/Ubuntu user's SSH keys were essentially useless, the world did not explode. Or consider the state of the internet in the 90-early 2000s - security was basically a joke, article author would've bust an artery raving about all the ways YOU ARE PWNED RIGHT NOW. Oh, and it looks like people are okay with Dropbox even though it occasionally fails horribly and lets you see other peoples' files.

It turns out for the vast majority of use cases, even broken crypto is Good Enough. That has to do with two things.

For you to be worrying about initialization vectors and block modes you need to first have a reason to be working at that level - answer "no" for most webapp use cases.

Secondly, and ignored by security fearmongerers: you need to have something of value commensurate with the efforts you've put toward security.

This is the mindset of a cryptography professional: true, chances are what you're using is broken. But whether that's a problem depends on who you are. If you're the NSA, you might be concerned with crazy shit like China building quantum computers and factoring all your primes (I'm making this up). Whereas you might be the latest social.ly startup, your users have no privacy anyway, security is more of an image concern (it looks bad to be on the front page of HN with security bug) than a real one.

No, it does not turn out that for the vast majority of cases, broken crypto is good enough.

It turns out that for the vast majority of cases, broken crypto schemes don't have enough users for the tiny minority of software security people who look at crypto to bother beating up.

Once one of those systems becomes popular, crypto pentesters finally get around to poking at them, and, lo and behold, thousands of users are discovered to have been communicating effectively in the clear for years.

It's one of the more pernicious evil memes in our field that "if you're not the NSA, everything you do is broken, so just try the best you can". No. The attacks we're talking about take 50-200 lines of Ruby code and less than 30 seconds to run. There's no excuse for being exposed to them. We mercilessly mock people who screw up SQL queries, but then act like it took a network of intelligence service supercomputers to break our amateurish cryptosystems. We'd all be better off if fewer people tried their hand at building these systems in the first place. Use PGP, or Keyczar, or NACL. If you're typing the letters "A-E-S" into your code, you're doing it wrong.

Right. To paraphrase: it turns out that for the vast majority of cases the "security holes" in the system aren't due to broken crypto. So what's the practical difference?

No! In the majority of cases where people use crypto, they do in fact have trivially exploitable crypto vulnerabilities.

Well, we're in agreement there - and I'd go further to say if you find yourself concatenating strings and feeding them to hash algorithm you're probably doing it wrong too. It's insecure and it's more work, and it's stupid.

I just wanted to point out the more general notion that, from a business perspective, even a colossal failure like Dropbox's is more of a PR disaster than anything else. And until that equation changes, security will be at the bottom of the totem pole.

I tend to view things like this the same way. Yes, all that advice is good. But all the effects that the listed minutiae deal with are way, way down the priority list of any real-world application. Specifically they're well below the threshold where a compromise of the user's computer via other means and/or a compromise of the human communication processes involved is a bigger threat.

The MAC example is a good one. You're at the point where you're trying to protect your app against a chosen ciphertext attack (pretty far up the sophistication scale), and trying to decide the MAC mode. The text in the article makes you sound like a total idiot for not knowing what the "right" choice is and making you worry that you might not get it right.

And then you get hacked because one of your admins had a ssh key on her phone and it got stolen.

Too much security analysis is missing Big Picture issues...

How is this helpful? How does it help to point out that so many of the people who are deploying crypto are so boned that their systems are compromised before the crypto even comes into play? Help me understand this. If you can't get the basic systems programming concerns of your software right, what business does your system have telling users that it's "cryptographically secured"?

First: I agree with all of your practical advice. I'm making a meta point to security people like you and the author of the linked post.

And I'm not sure it's "helpful" really . It's more musing on whether or not this kind of advice is hurting more than helping. What you are saying amounts to "Crypto is really hard so use expert-authored solutions." But in my experience what people hear is "Crypto is Hugely Important and I'm using a expert-authored solution and using the same jargon, so you need to listen to me about all that security stuff and do what I say even though it's totally impractical."

Broadly, I guess I'm thinking that this creates little BOfH monsters, where a more nuanced, "big picture" frame might engender more thought about costs and tradeoffs.

I would not have written the same post Tony wrote.

Generally: I'm comfortable writing about crypto when the subject is "how you would practically break a system that makes mistake X or mistake Y". I'm not comfortable about posts with prescriptive content.

I am also not comfortable with posts that condone building cryptosystems out of primitives, even when they limit the solution space to well-regarded tuples of those primitives. If I had to write a prescriptive post about crypto, it would state clearly: you cannot DIY this, and you must use a vetted cryptosystem; your choices include NACL, Keyczar, and PGP.

for not feeling comfortable with perscriptive posts you certainly make a lot of them

That's kind of the point though. If you're trying to decide your MAC mode you're already doing it wrong and should be looking at something higher level that does it for you.

And yet it still doesn't protect you from the stolen phone (or whatever -- bad password or password in email, SQL injection on the backend, bribed employee, etc...), which is I argue an immensely greater practical threat. So why do we keep reading blog posts about cryptographic minutiae instead of the real threat?

Obviously it's because the cryptography as a field is technically interesting and "security best practices" isn't. And there's nothing wrong with that from the perspective of someone looking for interesting links on HN. But honestly I feel like that kind of tunnel vision has reached the point where it's actually hurting security practice rather than helping.

Seriously? I'm not sure I know how to argue with this.

It doesn't bother you that, if you do it wrong, that by watching a bit of traffic and sending a few thousand page requests I might be able to impersonate any user on your system?

The linked post isn't even an interesting or exciting thing about crypto, it's not even news, it's just reiterating the usual thing - you shouldn't be doing this yourself.

In fact the linked blog post is exactly about best practices.

If you don't know how to argue with a point, maybe it's because you're not in an argument. :)

Obviously it "bothers me" that crypto is easy to get wrong. My point was that other things bother me more, and I don't think this genre of blog post (or your very typical reaction to criticism thereof) is helpful to improving security. See my other post -- are you one of those little BOfH monsters enabled by a little crypto knowledge? Are you sure?

Reply on news.ycombinator.com