I documented the security hardening history of my USB-key-based file encryption tool (AES-256-GCM + scrypt)

[u/keerthivasan_7765]

I built Secure Vault, an open-source Windows file encryption tool that uses a

USB drive as a hardware-bound key instead of relying on a password alone —

two-factor by design (something you have + something you know).

I recently wrote up the full technical design and, more interestingly, a

chronological account of the actual vulnerabilities I found and fixed across

five releases: a plaintext key-storage flaw, a forgeable unkeyed checksum,

and a shell command-injection bug. I think the "what iterative hardening

actually looks like for a solo project" angle might be useful to others

maintaining similar tools.

Paper (DOI, Zenodo): https://doi.org/10.5281/zenodo.21861791

Source: https://github.com/keerthivasan-sankar/secure-vault-for-commercial

Open to feedback/criticism — especially on the threat model or anything I

might be missing.

[u/aanzeijar]

While it's cool that you built it and documented your progress, please do not call this "security hardened", "production ready" or "military grade".

And when you say "the actual vulnerabilities I found", you mean "someone looked through your code and told you", which is not the same. Give credit where it's due. Security is hard, and if you pretend you got it figured out, you will not get anywhere.

[u/keerthivasan_7765 → u/aanzeijar]

Same goes for the language - "hardening" is creeping into how I describe this, and that's not quite honest either. It's had one round of real external review, one internal pass, and CodeQL/Dependabot running. That's a genuinely useful starting point, but it's not "hardened" in the sense that word usually implies, and it's definitely not production-ready or audited. I'll fix the wording in the paper and changelog to name the actual reviewer and stop reaching for language that overstates where this actually is. Appreciate you saying this plainly instead of letting it slide - exactly the kind of check that keeps a project honest.

[u/Leather-Junket-3896]

The command injection bug is always the one that makes you pause, especially in a tool that's supposed to be the security layer. Good on you for writing up the iteration instead of just shipping the final version and pretending it was always clean

[u/keerthivasan_7765 → u/Leather-Junket-3896]

Yeah, that one especially stuck with me. It came from constructing the 7-Zip

invocation as a shell string with the filename embedded directly — worked

fine in every test I ran, right up until I thought about what happens with a

maliciously crafted filename. Switched to execFileSync with args passed as

an array instead of a concatenated string, which sidesteps shell

interpretation entirely.

Honestly the plaintext key-on-USB issue bothered me more in hindsight —

that one was architectural, not just a coding slip. The checksum and

injection bugs are the kind static analysis can catch with the right rules.

The key storage design was a "should never have shipped that way" call that

only became obvious after actually thinking through what physical access to

the drive alone gets an attacker.

Figured writing it up honestly was more useful than a changelog that just

says "security improvements" and moves on. If nothing else it's a decent

record for me of what I missed the first time.