Base64 Encoding is a MIME content encoding scheme. Its mechanics are described in Wikipedia.
Basically, every 3 bytes (octets) becomes four Base64 Characters. Those 64 Characters are: ALL THE UPPERCASE LETTERS, all the lowercase letters, 0 through 9, + and /. Occasionally, Base64 strings end in one or two = signs. This makes Base64 pretty easy to spot if you're looking for it.
Base64 is very useful, and it has a few cousins (such as uuencoding). Command-line tools for encoding and decoding Base64 exist for almost every platform. Try installing the package named "base64" (OSX: from Darwinports, Linux: apt-get or yum, BSD: pkg_add or use the ports tree) if you don't have it installed already. Also, the leetkey plugin I discussed in the FireFox plugins article can encode and decode Base64 on the fly!
Base64 was originally meant to help transfer binary data across platforms (such as between mail servers on different architectures) without any corruption or data loss. Different platforms handle line-breaks and character encoding differently, but the subset of characters listed above remains consistently the same on all major operating systems.
Since us mortals are generally bad at binary math and array indices, Base64 also gets used to obfuscate things like passwords. Okay, the fact that the algorithm is well known also has a little to do with it. This has been done for a very long time. I first started tinkering with Base64 way back in the day when I was trying to figure out how to "decrypt" passwords that I was seeing with rudimentary network sniffers. Here, you can see HTTP Basic Auth at work. This was a capture from WireShark (click to enlarge)
The Base64 string is "dGVzdDp0ZXN0aW5nMTIz" - Decoding it:
echo -n "dGVzdDp0ZXN0aW5nMTIz" | base64 -dI used echo -n because it supresses the newline character. Since Base64 encodes everything, it will even catch the newline. This isn't as important during decoding as it is encoding. The -d flag on Base64 simply tells it to decode. Encoding is base64's default mode of operation. As you can see, the Base64 string decodes to a username and password separated by a colon. We don't actually have to go through this hassle, though, because Wireshark will decode it right there for you. I simply suppressed that line in the screenshot above.
By the way, even SSL/TLS connections pass HTTP Basic Auth this way, but most SSL sites (and other sites in general) are using vanilla form posts. In reality, this kind of obfuscation is tantamount to plaintext.
Let's look at another ridiculous use of Base64... the ncftp bookmarks file
-bash-3.2$ cat .ncftp/bookmarksWhat's that I see? No, That's not my real password anywhere. Although the base64 version wouldn't make a horrible password in its own right. For what it's worth, at least the permissions on that bookmark file are decent, and ncftp doesn't store the password by default unless you tell it to do so.
NcFTP bookmark-file version: 8
Number of bookmarks: ??
I suppose it doesn't hurt that Base64 is used like this, but it really amounts to security through
ignorance obscurity. It shouldn't be relied upon as the only method of protecting sensitive data.
One great example of something using Base64 practically is GnuPG, when you use ASCII-armoring for things like sharing your public key or for the output file. GnuPG data is binary, but ASCII-Armoring provides the binary data in Base64 (with a checksum at the end as part of an implementation called Radix-64). This is the kind of situation where Base64 truly shines! The resulting output of GnuPG is a block of encoded data like this (which is my public key, feel free to use it to contact me):
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.8 (OpenBSD)
-----END PGP PUBLIC KEY BLOCK-----