There is no generalist developer in the world that will come up with HMAC when given the "secure hash algorithm" tool and the knowledge that you can "sign" or "protect" a message concatenating it with a key. HMAC is surprisingly intricate.<p>That there is no simple, intuitive alternative to HMAC is a  strong reason not to allow developers to work at the "picking algorithms and constructions" level of cryptography.<p>The rule is, "data in motion should be secured with TLS, data at rest should be secured with PGP".<p>What worried me about posts like this is that they communicate the idea that, if you just know a couple more things (like, "HMAC"), you can get crypto right. No. For instance, this article doesn't explain how to safely compare HMACs. The intuitive way to compare securely is drastically insecure. The correct way to do it is surprisingly intricate.<p>If you're typing the letters H-M-A-C into your code, you're doing it wrong.