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...
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?
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.
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...