Colin Percival

I agree that cloud hosting opens up many new vectors of attack, but I completely disagree about building the app from the ground up.

The larger your app is, the less likely it is to be secure. A better strategy is to keep your app lean and mean, and build it off of existing security technologies which have proven to be reliable.

But as we've seen with Heartbleed, some of your security measures will fail. Its important to follow the principle of least privileged, and to isolate your system as much as possible; for instance, Colin Percival uses stunnel to isolate OpenSSL from his webserver[1]. This solution is far from perfect, and it still puts your private key at risk in a Heartbleed-like event. But that majority of your user's data is kept away from OpenSSL; it limits your exposure.

[1] http://www.daemonology.net/blog/2009-09-28-securing-https.html

"Crypto can't be a «bit broken». It can't be «mostly working». Either it's 100% correct, or you shouldn't have bothered doing it at all. The weakest link breaks the whole chain."

I completely agree. Ever seen a password hash mega-post on paste-bin? Bought to you by bad crypto. Saying "I don't
know" is one of the hardest things to do, and also one of the most powerful. I applaud you for knowing your limits in this regard. I like to say crypto is like surgery, best left for the experts. You never want to "I kinda messed up that triple bypass," because there are major consequences for it. The same is true for virtually all aspects of cryptography. Thank you for this post!

Edit: Here a link to a blog post that was discussed recently on HN that is pertinent: http://www.daemonology.net/blog/2013-06-17-crypto-science-not-engineering.html

The author mentions HMAC at the end. I think HMAC is really an underrated technique. I remember reading Colin Percival's classic Cryptographic Right Answers[0] and saw a section about "symmetric signatures." I pondered to myself what scheme I could use for that before I looked at the answer: of course it's just HMAC. I feel like this is another perspective that ought to be more widely known: if you want something to be like a signature, but the two parties (or just a single party at different times) can share a key, HMAC really is the right answer. Things like, a server needs to cryptographically sign a cookie to prevent tempering: that's HMAC. Or a server needs to know an API request is coming from an expected client: that's also HMAC.

[0]: https://www.daemonology.net/blog/2009-06-11-cryptographic-right-answers.html

> If I have legitimate reason to believe that an exploit does not affect me (especially if it's because I acknowledged its possibility and programmed defensively against it), why would I automatically act as if I were breached too?

Your argument hinges on the word "legitimate." I don't do security, but "it looks good to me" is not a legitimate reason to believe that the exploit does not affect you (for any value of "me"). OTOH "I've never used the versions of OpenSSL that have this bug" is a legitimate reason to believe that you're not affected, e.g. Tarsnap's explanation [1]. I'd also recommend that post for another take on what defensive programming looks like in this context.

[1] http://www.daemonology.net/blog/2014-04-09-tarsnap-no-heartbleed-here.html

on HN: https://news.ycombinator.com/item?id=7562125

As a subscriber on the list, "more value" (to me) is provided in a couple of ways:

- I seem to like the weekly selection; the editorial choices on which articles are likely to be of interest of the group.

- Kale includes older posts, sometimes from months back, sometimes more obscure or funny, that are still interesting to read now.

- I get the top stories in a weekly email that I can process weekly. If I feel I've kept myself reasonably up to date with current news, that means a quick scan. But after a couple of weeks of vacation, processing just three issues of Hacker Newsletter is sufficient to catch up.

By the way, http://www.daemonology.net/hn-daily/ is also convenient to catch up after a long time.

It’s possible some projects do this correctly but I suspect most have a false sense of security as the compiler will elide all stores that are happening in a struct about to be freed and there’s no C/C++/LLVM language that’s really immune from this [1].

Usually a more thorough approach is to turn on malloc scribbling, ASAN or valgrind which is something Darwin’s allocator can be told to do (it’ll scribble separate uninitialized and freed patterns).

I could see the appeal of there being a magic value though. I think that’s what memset_s is for so hopefully your favorite project is doing that properly.

[1] http://www.daemonology.net/blog/2014-09-04-how-to-zero-a-buffer.html