Encoding vs. Encryption vs. Hashing: What Network Engineers Actually Need to Know

The One-Sentence Version of Each

• Encoding transforms data into a different representation for compatibility or transport — reversible by design, no secret required.
• Encryption transforms data so it can only be reversed by someone holding the correct key.
• Hashing transforms data into a fixed-length fingerprint that cannot be reversed at all — only verified by re-hashing a guess and comparing.

Cisco Type 7 gets called "encryption" in a lot of documentation and forum posts, but functionally it's closer to encoding: there's no secret key involved, just a fixed, publicly documented XOR table. Anyone with the algorithm — which has been public for decades — can reverse it instantly. That's why tools like our own Type 7 decoder exist and work reliably on every valid hash.

Encoding: Base64, URL Encoding, Type 7

Encoding exists to make data safe to transmit or store in a particular format — not to hide it. Base64 turns binary data into ASCII text so it survives email transport. URL encoding escapes special characters so a query string doesn't break. Cisco Type 7 XORs each byte against a fixed 53-entry lookup table so a password doesn't sit in the config file as raw plaintext at a glance.

The common thread: none of these require a secret to reverse. The "key" — if you can call it that — is the algorithm itself, and the algorithm is public. Security through this kind of obfuscation only works against a human skimming a file with their eyes, not against anyone who bothers to look up how the encoding works.

Encryption: AES, and Cisco Type 6

Real encryption requires a key that isn't embedded in the same document as the ciphertext (ideally). AES-256, for example, is computationally infeasible to reverse without the key, even with significant compute resources. Cisco's Type 6 password encryption is a genuine (if dated) example on IOS devices: passwords are AES-encrypted using a master key stored separately via the key config-key password-encrypt command — meaning a leaked config file alone isn't enough to recover the passwords, unlike Type 7.

The security of any encryption scheme lives entirely in how well the key is protected. An encrypted config file with the key sitting in the same backup archive offers little more protection than Type 7 does.

Hashing: SHA-256, scrypt, and Cisco Type 8/9

Hashing is the only one-way transformation of the three. Feed it any input and you get a fixed-length output; feed it the same input again and you get the same output, but there's no mathematical way to go backward from the hash to the original input. This is exactly what you want for password storage: the system only ever needs to verify a login attempt, never recover the original password.

Cisco Type 8 (PBKDF2-SHA256) and Type 9 (scrypt) are both salted, iterated hashes designed specifically to resist brute-force and rainbow-table attacks — scrypt additionally makes large-scale GPU cracking expensive by being memory-hard. Neither can be "decoded" the way Type 7 can. If you've forgotten a Type 8/9 password, the only real recovery path is resetting it, not reversing it — that's the entire point.

Quick Reference

How to Recognise Each One in a Cisco Config

You can usually tell what protects a password by looking at how it is stored. A Type 7 string begins with two digits, which are the starting position in the lookup table, followed by hexadecimal characters, for example password 7 0822455D0A16. Type 5 hashes start with $1$, Type 8 with $8$ and Type 9 with $9$. A line that shows password 0, or a bare password with readable text, is plaintext.

This is why the digit after the keyword matters so much. It names the scheme, and the scheme decides whether someone who reads the file can recover the password. Two of the schemes can be reversed by anyone: plaintext and Type 7. The others cannot be reversed, only guessed at.

Run this on a device to see every line that carries a credential, and read the type number on each one.

Common Mistakes That Come From Mixing Them Up

• Calling Base64 "encryption". Base64 is a format. Anyone can decode it, so an API key or password stored that way is effectively in plaintext.
• Storing the key next to the data. An encrypted file with its key in the same folder, repository or backup protects almost nothing.
• Using a fast general-purpose hash for passwords. Hashes such as MD5 or plain SHA-256 are designed to be quick, which helps an attacker who tries billions of guesses. Password storage needs a slow, salted scheme such as the PBKDF2 and scrypt used by Types 8 and 9.
• Hashing something you need to read back. A hash cannot be reversed, so it is the wrong tool for a secret that a system must use later, such as an SNMP key or a RADIUS shared secret. Those need encryption, or a vault.

Which One Should You Use?

Ask what the system must do with the value later.

• If it only needs to check a password someone types, use a salted, slow hash. This is the case for administrator logins, so use secret with Type 8 or 9.
• If it needs to use the value again, use real encryption and protect the key separately, or keep the secret in a dedicated vault.
• If you only need to carry data through a system that handles text, use an encoding, and never rely on it for secrecy.

A salt is a random value added before hashing, so two users with the same password get different hashes and precomputed tables stop working. Type 7 has no salt, which is one more reason it fails. For a full migration plan, see migrating from Type 7 to Type 9, and for a review of your current devices use the password security checklist.

Summary

Encoding changes the format and can be undone by anyone. Encryption hides data from anyone without the key. Hashing produces a one-way fingerprint, which is what you want for stored passwords. Cisco Type 7 is encoding, not encryption, so treat any Type 7 password as readable and move to Type 8 or 9 for logins.