A post on HackerNews today was getting some discussion about a blog post titled Hell Is Overconfident Developers Writing Encryption Code. In it the author points out a flawed implementation of secret sharing that was performed by a startup, and how many cases fly under the radar due to not having a public blog post and walking through their code.
A quick and non-explanatory review of things before reading the article:
- Authenticated Modes like GCM & CCM should be used for ciphers.
- Also meaning that modes like CBC & CTR should not be used.
- Rolling your own crypto is a broad statement. It can mean anything from the underlying cryptography to the implementation of a popular cryptography library.
Most critically, “rolling your own crypto” means spending any innovation tokens at any level of abstraction on cryptography without adequate assurance of correctness and/or peer review from cryptography experts (preferably ones with at least some experience breaking other implementations). ~ Soatok
- User passwords should be hashed, not encrypted.
- If something is encrypted, don’t store the decryption key anywhere near it.
Keep it secret, keep it safe. ~ Gandalf
- Follow KISS: Keep it simple stupid.
- This is useful for most things, but especially things involving cryptography.
- It also would mean follow a standard approach: In most cases, a secrets manager, or an EZPZ E2E app, would be better options.
I do want to allow for human empathy here. Being a fullstack dev is hard, and I can’t imagine all the different things they need to account for, as I’m not one. Needing to deeply understand one field is rough, and I’m not even there. Imagine being relied on to understand 10+ fields! I think being humble is key when it comes to implementing more impactful functionalities like cryptography, authentication, authorization, or any other specific feature of an app that could make a big boom if something is done wrong.
Having a coworker you trust check your work, advocating for yourself and your team that a security review needs to be done regarding certain implementations (or the whole app, if one hasn’t been done), and getting penetration tests done whenever large-scale changes or functions are created can all help push the security of the application forward.
Think of a JWT implementation from a fresh dev’s new project that hasn’t worked with JWTs before. It’s really easy to appear like it’s working correctly, but if certain things haven’t been specifically checked for that are only ever needed when working with JWTs, they might have gotten overlooked. It’s easy to make the mistake of saying “Well since the token was returned and the app lets me see this authZ protected page, it’s good to go!”. Especially if you’ve just worked with cookies until then.
Age was pointed out as a good utility for this, and I hadn’t run into it before, so I figured why not give it a go! Installation was super easy:
brew install ageAnd using it is just as easy:
$ cat secretMsg.txt
Keep it secret, keep it safe.
$ age -p secretMsg.txt > secretMsg.txt.age
age: using autogenerated passphrase "waste-task-reject-grab-place-inform-asset-embody-day-vivid"
$ cat secretMsg.txt.age
age-encryption.org/v1
2 │ -> scrypt ur7yoxPGyZx6No2twZVs9A 18
3 │ ZfT2nGWDLx25QCPNeBYKBKcQ0k+H92mSMSoz/Kn//LE
4 │ --- pLRarED5g1UpAEaTddLmo3lvW434rhQOQywNSnpegh0
5 │ !�穮D�(^Xr�^_^T���p�^E^H/^V��^N^S�^A�]#��a�n=�pW�p^Q���;xq���^Oƞ^Q��
$ age -d secretMsg.txt.age
Keep it secret, keep it safe.The startup author had pointed out he had issues using PGP/GPG:
“That’s still software I have to trust and install. In fact, I just tried, and got lost immediately. I found OpenPGP which has a half-dozen email-related packages for MacOS (didn’t try: proprietary/paid, and all about specific email clients that I don’t need), and found GPG which has two installers for Mac. I tried one, and it needs root access to install itself. Why would I give some software root access just to encrypt a secret? It certainly doesn’t increase my trust in it.”
The author also shared it on Reddit, where a person had suggested using GPG, or Signal as a fallback for even easier use. His response to that individual contained:
I haven’t tried Signal, but it’s one more thing I’d need to evaluate and decide whether to trust.
Other tooling suggested by other users & the author:
Regarding the HVault, one user left an interesting comment about a feature I didn’t know existed:
Only tangential to this post, but if you need a way to share secrets with your teams (or whoever), Hashicorp Vault is pretty decent. They don’t even need login access. Instead of sharing secret values directly, you wrap the secret which generates a one-time unwrapping token with a TTL. You share this unwrapping token over a traditional communication method like Slack or e-mail or whatever, and the recipient uses Vault’s unwrap tool to retrieve the secret. Since the unwrapping token is one time use, you can easily detect if someone intercepted the token and unwrapped the secret (by virtue of the unwrapping token no longer working). This hint tells you the secret was compromised and needs to be rotated (you just need to follow-up with the person to confirm they were able to retrieve the secret). And since you can set a TTL, you can place an expectation on the recipient too — for example, that you expect them to retrieve the secret within 10 minutes or else the unwrapping token expires.
All of this has the added benefit that you’re not sharing ciphertext over open channels (which could be intercepted and stored for future decryption by adversaries).
Simple, small mistakes or misunderstandings can easily spiral out of control and result in an exploit / data breach when the way those systems work are not fully understood. It’s easy to tap out and fall back to the standard of situation-specific industry standard recommendations; use the right tool for the job :-)
This is a collection of my cybersecurity notes & projects.
I graduated from Dakota State University with a MS in Cyber Defense & BS in Cyber Operations. Since then I've worked as a Malware Analyst with the U.S. Army Cyber Command, and am now a Web Application Security Consultant.
I'm a big fan of open security standards for applications and workflow automation when it comes to security testing. The easier it is to identify and replicate, the more secure everyone's apps can be! My other writings and projects are scattered across the web, but can be found in the links page.
Contact me: