This seems very closely related in spirit to this submission from last month: https://soatok.blog/2021/02/24/cryptography-interface-design-is-a-security-concern/
The more primitive the crypto building blocks are, the more developers are ‘rolling their own’ crypto, even if the building blocks they use are sound.
I do design crypto protocols for a living and I also do risk assessment and review for HSMs and various services. Getting it “right” is a matter of having a very strong engineering culture where security is not just left to a handful of wizards who stand up in defiance against product management. Everyone has to respect it as a foundational part of the development/manufacturing/deployment process.
I laughed pretty hard at someone suggesting SHA2 as a remotely reasonable password hashing choice.
SHA2 with PBKDF2? Sure. SHA2 alone? Please no.
Otherwise the article does make a good point. Personally I think the biggest benefit of the modern HTTP everywhere culture is the widespread proliferation of HTTPS rather than tons of custom protocols.
SHA2 with PBKDF2?
SHA2 with PBKDF2?
PBKDF2-HMAC has some interesting failure modes. Unless you absolutely need FIPS-140 support (because you’re support USG customers), you probably want to use Argon2id.
What I took away from this post is that we need more libraries like libsodium, that offer the top-level primitives that programmers actually use, rather than “safe” versions of things they shouldn’t be using. Tink is sorta there, but we really need to move away from all the terrible failure modes that happen when using crypto wrong and towards things that help you make the right choices. Another good example is Fernet from pyca, which makes some opinionated choices about how to use several primitives, but saves programmers from doing the wrong thing.
PBKDF2 is “if you have to, then ok” type of choice. Use Argon2 or bcrypt if you aren’t forced to use PBKDF2.
It’s a good hash… for a checksum.
Why? I mean, it doesn’t have specific hardening to slow down brute-force attacks but is that all?
Right, it’s not a KDF at all and so trivial to brute force that you might as well be in the clear. It could be a building block in a KDF, but sibling comments have covered that.
Sometimes I need to make layer 7 protocols. I just run it over TLS and I force the use of v1.3 if possible. That is, I can rely on my language’s ssl module and its choices which must comply with TLSv1.3 anyway.
Server-side, HAProxy can handle the TLS layer and load-balance the forwarded plain-text/octet protocol among local servers.
The only thing is that you have to handle certificates. Fortunately, there is Let’s Encrypt and wildcards nowadays.
I’m pretty sure there is still room for improvement, though. Maybe forcing only the strongest cipher suite allowed by TLSv1.3? Controlling session duration?
Tls is solid and you probably can’t do better yourself. The place where nearly everyone fails is in how they manage their keys. You can have the strongest steel door in the world but if you leave the spare key under the potted plant then anyone can come in. Ditto for people generating weak and common keys due to poor entropy in both client and server.
No, you are not. You are responsible for your crypto choices. You are, if you are being responsible, not rolling your own versions of the sensitive stuff. The author conflates choosing the wrong Lego block with failing to create a durable plastic.