I know the scene all too well. Your researching some problem, some API is returning a 401 or a 403. Maybe someone changed the credentials? Maybe they were reset? You grab the encoded creds and reach for the nearest Base64 decode website to confirm your suspicions.
Or maybe it's the reverse, you get a key and a secret from your ultra protected vault, but the API needs it in a Basic Auth header format. Throw that key and secret and required colon separator into your friendly, helpful, base64 website and you get your Auth header back ready to add to your environment variable or secrets manager.
I know I did this earlier in my career, and I know most of you have done it also. I've even seen you do it while screen sharing. It scares me that some of the worst offenders have been those with access to the most secrets. So what's the deal? Why avoid websites like the above?
I know I did this earlier in my career, and I know most of you have done it also. I've even seen you do it while screen sharing. It scares me that some of the worst offenders have been those with access to the most secrets. So what's the deal? Why avoid websites like the above?
The problem with base64 websites
You trust them too much.
Imagine copying your email account username and password, then pasting them in clear text on some random website. Can you really trust the website to not take those credentials and someday use them to attempt to use your email account for other purposes? Using Base64 websites to encode or decode credentials breaks any security protections or protocols surrounding those credentials. There is little use in using a vault or a password manager if the credentials will simply be pasted into random websites.
To be clear, I still use Base64 websites from time to time when handling non-secure data. Just please, don't use them for anything you wouldn't feel comfortable posting on X, Facebook, Reddit, or the like. So, what's to be done if you're backed into a corner and need to encode or decode some secure data?
Imagine copying your email account username and password, then pasting them in clear text on some random website. Can you really trust the website to not take those credentials and someday use them to attempt to use your email account for other purposes? Using Base64 websites to encode or decode credentials breaks any security protections or protocols surrounding those credentials. There is little use in using a vault or a password manager if the credentials will simply be pasted into random websites.
To be clear, I still use Base64 websites from time to time when handling non-secure data. Just please, don't use them for anything you wouldn't feel comfortable posting on X, Facebook, Reddit, or the like. So, what's to be done if you're backed into a corner and need to encode or decode some secure data?
Base64 data in a more secure manner
As with most things in life, there are several ways to better handle your secure data. Let's go through a few of them below:
1. Don't handle application secrets
This is easier said than done, but the best handling of secrets involves no manual human interaction. For example, if you use a vault, give your application direct access to the needed secret and have the application encode as necessary. This may take more effort and development up front, but following the principle of Least Privilege can keep your application and data safer as you minimize the number of people who have access to those secrets.
2. If you must, keep those secrets local *
I get it. Sometimes your application isn't setup to talk to a vault. Sometimes you need to take a secret through multiple vaults to get it to the right spot. Sometimes, there's just a "sometimes". In these cases, keep those secrets (encoded or decoded) on your local machine. Don't paste them into a random website.
2. If you must, keep those secrets local *
I get it. Sometimes your application isn't setup to talk to a vault. Sometimes you need to take a secret through multiple vaults to get it to the right spot. Sometimes, there's just a "sometimes". In these cases, keep those secrets (encoded or decoded) on your local machine. Don't paste them into a random website.
Windows:
I stopped using Windows for development around a decade ago, so the below is what I could find with some searching and thus it may be wrong. In general, I would suggest using WSL to get easy access to the base64 command from coreutils, or utilize the tools provided in your programming language of choice.
# Base64 encode some data $originalString = "Hello, World!" $encodedString = [Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes($originalString)) # Base64 decode some data $encodedString = "SGVsbG8sIFdvcmxkIQ==" $decodedString = [System.Text.Encoding]::UTF8.GetString([Convert]::FromBase64String($encodedString))
*nix
Mac, Linux, and other Unix like systems either have the base64 command built in, or make it easy to get. With the base64 command you can easily encode and decode data from the terminal.
# Encode some data echo "Hello World" | base64 # => SGVsbG8gV29ybGQK # Decode some data echo "SGVsbG8gV29ybGQK" | base64 -d # => Hello World
Pretty much every Programming language ever created
Yes, your programming language of choice has some means to base64 encode and decode data. Some are easier than others. I will only show an example for JavaScript below. You can google / claude / chat gipity the other languages, but let's be honest, you're just gonna throw this into the dev console of Chrome.
// Encode the data, deja vu?
btoa("Hello World")
// => 'SGVsbG8gV29ybGQ='
// Decode the data
atob('SGVsbG8gV29ybGQ=')
// => 'Hello World'* A Quick note on different implementations: Different implementations may have slight differences when encoding and decoding across different tools. These tend to be minimal such as encoding the newline character. In general try to use the same tool for your decoding and encoding needs and be aware of the slight differences that may occur.
Let me know if you have any fun stories related to base64 data, or if you have any feedback on the above.
@mattacton
matt.acton@hey.com