A few days ago, while reading a tweet on X, I came across someone who reported that all their cryptocurrency had been stolen from their wallet. This person is technically knowledgeable (they work professionally in IT), meaning they should have never experienced security issues at this level. In this tweet (which you can see below), they explain step by step what happened and how we can avoid the same fate:
Although the thread focuses primarily on crypto (cryptocurrencies and digital trading), as always, I like to consider problems from multiple perspectives. I realized this is an issue that could affect others, too—and if this wake-up call can inspire some security improvements for everyone, that’s even better…
Summarizing the extensive thread (which I highly recommend reading in full), a browser extension (for the Cursor development interface) managed to access the .env file, transmitted the user’s private key to the attacker, and the attacker drained the wallet in just a few hours. The loss was minor (only a few hundred dollars), but this incident demonstrates how even the most cautious can fall victim to supply chain attacks.
It’s true that storing secrets in .env files is a common practice; however nowadays, for applications handling highly sensitive credentials, it’s recommended to use secure vault solutions, such as:
- HashiCorp Vault (open source)
- AWS Secrets Manager
- Google Secret Manager
These systems allow secure storage of credentials and generate temporary, encrypted tokens for access—so that an attacker can only obtain a limited token, not critical credentials.
Another key principle of any secure development system is “environment separation”: that is, have fully separated environments for development, testing, and production (and any parallel systems for quality assurance, additional testing, etc.)
This means each environment must have different access authorizations so that developers—or anyone else involved—never have direct access to production configuration data.
So, summarizing these recommendations:
- Do not store secrets in
.envfiles. - Verify the authenticity of software authors and any extensions you use.
- Use cold wallets exclusively for significant funds.
- Audit extensions regularly.
- Separate your working environments to enhance security.
- Monitor systems regularly.
I’ve always said that “security is the opposite of convenience.”
We usually aim to simplify users’ lives, but once we add “security,” that simplicity often becomes “inconvenience.” Like needing to open an OTP app in addition to entering your credentials—that’s not supposed to be easy.
Still, those of us working on the frontline developing solutions sometimes need to take more security measures—and tolerate greater discomfort than usual—for the sake of both the project at hand and other projects within the company.
Whenever someone secures their systems with just a username and password, I’m reminded that:
- Most people reuse their passwords across some—or all—services…
- Some services have already been compromised, exposing usernames, passwords, etc. (e.g., via haveibeenpwned.com) …
- An encrypted password can be decrypted in a short time…
So, if you ever wonder, “should I do this to enhance security?”—the answer is always YES. Better to err on the side of paranoia than to have something stolen… especially since the ultimate goal is to avoid ending up in a situation like that poor guy experienced. Right?