Base64 is not encryption

The secrets I found lying around my own Macs

While setting up a new server, I went looking for the usual config details. Instead, I found an old API key in a nameless TextMate buffer and a password that was only base64-encoded in an env file.

Both were still readable. Both would have worked.

This was after a year of small side projects, experiments, and half-finished ideas. I had not done a proper audit in a while. I had treated my own machines as if they were private notebooks instead of places where real secrets live.

How API keys end up in random files

The TextMate one was predictable in hindsight. You test a new API. You paste the key into a quick script. You debug, tweak, comment things out. Somewhere in there, you copy the key into a separate buffer “for a second” so you can reuse it in another file. Then you move on to something else.

That buffer sits there. TextMate autosaves. Months later, you are on a different project on the same machine, and the key is still in a file that does not even have a name.

Anywhere you can paste text will happily keep secrets around: scratch files, temporary shell scripts, notes apps, chat windows with yourself. When you are moving fast, the shortest path is usually copy, paste, run, forget. The forgetting part is the problem.

Base64 is not hiding anything

The password in the env file looked slightly better at first glance. It was not in plain text, but base64-encoded.

I wrote about this earlier in What a 90ms Font Swap Taught Me About Performance Budgets.

Base64 is not encryption. It is an encoding. Anyone who can read the file can decode it instantly. There is no key, no secret, no protection. It just looks less obvious than clear text, which is exactly why it feels acceptable in a hurry.

The logic is simple: “I do not want to see the password in plain form in this file, so I will base64 it.” That solves the visual discomfort, not the security issue.

Why fast building makes this worse

Side projects and experiments have a different rhythm than production work. You are trying things, throwing them away, changing direction. It feels temporary, so you relax rules you would not skip on a client project.

That is how you end up with hardcoded tokens “just for now,” env files copied across machines without checking contents, secrets pasted into chats so you can reach them from another device, and “temporary” notes that live for years.

The problem is that temporary setups have a habit of staying in place. The quick test server becomes the thing you rely on. The “throwaway” script turns into a weekly tool. The risk grows, but the sloppy handling of secrets stays baked in.

What I changed after this mini-audit

After seeing where my own keys and passwords had ended up, I tightened a few habits. Nothing dramatic, just rules that are easy to remember when I am moving fast.

1. Use a password manager for anything that matters

New passwords and long-lived API keys go into a password manager by default. Not in a note, not in a chat, not in a scratch file. If I need it in a terminal or editor, I copy it from there, use it, and let it disappear again.

More on this in my article Logging Food by Talking to Claude.

This removes the excuse of “I will just paste it here for a second so I do not lose it.” The password manager is where it lives. Everything else is a temporary view.

2. Env files with strict access

Env files are still where a lot of configuration happens, including secrets. That is fine, but they should be treated like keys, not like config samples.

For me that means env files live outside version control, have tight file permissions, and are only present on machines that actually need them.

And no more base64 pretending to be protection. If a secret is in an env file, it is treated as sensitive. If that feels too exposed, the file itself needs better handling, not a visual disguise on the value.

3. Never in notes or chat

I do not put passwords or API keys in notes apps or chat anymore. Not for syncing, not for sharing with myself, not as a to-do reminder.

If something needs to move between machines, there are better options than dropping it into a place that is designed to be searchable, synced, and backed up for a long time.

Read also Two Macs, One SSD, and the Sync I Stopped Trusting.

The rule I try to follow now

After cleaning up the old traces, I ended up with a single rule that is easy to remember:

If I would be unhappy seeing this value in a public Git repo, it does not belong in a random file on my machine either.

That rule catches most of the lazy shortcuts. A nameless TextMate buffer is not that different from a public repo if you lose your laptop, sync backups to multiple places, or share your screen while debugging.

This is not a full security model. It is just a way to stop pretending that base64 is a lock, or that “temporary” files stay temporary.