Understanding the differences between the Cisco password \ secret Types

[Tim Glen]

Best Practices

• The enable password command should no longer be used. Use enable secret instead.
• username joeblow password mypass command should no longer be used.  Use username joeblow secret mypass instead.
• Type 4 Passwords should never be used!
• Use Type 6, Type 8 and Type 9 wherever possible.
• Type 0, Type 5 and Type 7 should be migrated to other stronger methods.
• Do NOT use dictionary words. Use random strings for passwords.  Click HERE for a great tool I've been using for years.

Cisco Password Type’s

Type 0

This is cleartext and should never be used in a running or startup-config. Attempting to use Type 0 in modern IOS XE will throw an error as these will be depreciated soon.

Type 4

Cisco created Type 4 around 2013 in an attempt to upgrade Type 5. However, the attempt was severely flawed and resulted in a hash that was weaker than a Type 5 MD5. See the PSIRT below.
Cisco IOS and Cisco IOS XE Type 4 Passwords Issue

 

Type 5

These use a salted MD5 hashing algorithm. These should only be used if Type 6, 8, or 9 is not available on the IOS version you are running. Attempting to use Type 5 in modern IOS XE will throw an error as these will be depreciated soon. In the running config these start with $5$.

Type 6

This is true encryption using 128 bit AES counter mode. The administrator defines a master key which is used by IOS XE to encrypt the password. The encrypted password that is visible in the running-config cannot be copied between devices UNLESS the original Master Key is configured on the new device!

See this document I authored on Configuring Type 6 Passwords

 

Type 7

These use the Vigenere cipher, a very simple algorithm that was cracked in 1995. These are easily reversible with tools on the internet. These should never be used and attempting to use Type 7 in modern IOS XE will throw an error as these will be depreciated soon.

 

Type 8

Type 8 passwords are what Type 4 was meant to be, an upgraded Type 5!  Type 8 is hashed using PBKDF2, SHA-256, 80-bit salt, 20,000 iterations. While this is good, it is still vulnerable to brute-forcing since AES is easy to implement in (GPU) graphics cards. I have not proven it but I believe it is possible that the popular tool HashCat is able to decrypt these. In the running config standard Type 8 start with $8$.

 

Type 9

These use the SCRYPT hashing algorithm defined in the informational RFC 7914. SCRYPT uses 80-bit salt, 16384 iterations. It’s very memory expensive to run the algorithm and therefore difficult to crack. Running it once occasionally on a Cisco device is fine though, this is currently the Best Practice Type password to use. I have not proven it but I believe it is possible that the popular tool HashCat is able to decrypt these.

In the running config standard Type 9 start with $9$.

In the running config convoluted Type 9 start with $14$.

Frequently Asked Questions

Q: Some of these are crack-able, what do I do?

A: Easy answer! NEVER use dictionary words.  Use a random password generator like the one found here.   https://www.random.org/passwords/

Q: Which Password Types are portable between devices?

A: You can copy & paste Types 0,5,7,8,& 9 between devices.

Q: Can Type 6 also be portable between devices?

A: Type 6 can be portable between devices ONLY if you configure the Destination device with the same key config-key password-encryption KEY as was originally used on the Source device.

Q: What if my device with Type 6 experiences hardware failure?

A: Great question,  when configuring Type 6 it’s very important to store the key config-key password-encryption KEY in a secure location as it is NOT recoverable from the devices running configuration, or anywhere else.  Once you enter it at the CLI you will never see it again on the device.

Q: Is this applicable to IOS XR as well?

A: Sorry, I don’t know, maybe I’ll research this and update this post later on if folks ask.

Q: Hashed \ encrypted, what is the difference?

A: Encrypted typically means it is reversible using the key. Hashed is typically one-way. 

Q: When should I use Type 6 encryption?

A: Use Type 6 when the device needs the actual password, eg. routing protocols. Type 6 can also be used when the device needs to recognize the correct password, username kashvi password cisco123, enable secret.

Q: When should I use Type 8 or Type 9 hashing?

A: Hashed passwords can be used when the device needs to recognize the correct password but does not need to transmit it to other devices (routers, FTP servers, etc)

Q: When configuring or restoring a Type 6 password, do I need to enter commands in a specific order?

A: Optimally you will enable password encryption aes, key config-key then the Type 6 password, however, if you enter the Type 6 password first, then enable password encryption aes and the key config-key second that will work as well.   So no it really doesn’t matter as long as the Master Key is defined.

Q: Which is most secure, Type 6, 8 or 9?

A: This is debatable. Since Type 8 & 9 are one-way hashes they could be considered the most secure. However, I believe popular tools are able to brute force Type 8 & 9 and I’m not sure if Type 6 can be brute forced… yet.  

Thanks for reading, please rate or comment to help make this document better!

[kopec2111]

What is the first IOS to support Type 9 hashing?

[ndemers]

Trying to find history of Type 6,8,9 introduction into IOS and IOS-XE.

Main Question : At what point was Type 8 introduced into IOS/IOS-XE code? Some of these features dont support type 8 or 9

Feature	Password Type 6	Password Type 7	Password Type 8	Password Type 9
line con
line vty
bgp neighbor
aaa group server
tacacs-server
radius-server
username
ldp neighbor
ISIS neighbor
snmpv3 community string?
keychain

For reference the command  enable algorithm-type has a history but not the supported algorithms:

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/security/d1/sec-d1-cr-book/sec-cr-e1.html#wp3884449514

enable algorithm-type

To set the algorithm type to hash a user password configured using the enable secret command, use the enable algorithm-type command in global configuration mode. To remove the algorithm type, use the no form of this command.

enable algorithm-type {md5 | scrypt | sha256}

no enable algorithm-type {md5 | scrypt | sha256}
Syntax Description
md5 	

Selects the message digest algorithm 5 (MD5) as the hashing algorithm.
scrypt 	

Selects scrypt as the hashing algorithm.
sha256 	

Selects Password-Based Key Derivation Function 2 (PBKDF2) with Secure Hash Algorithm, 26-bits (SHA-256) as the hashing algorithm.
Command Default

No algorithm type is defined.
Command Modes

Global configuration (config)
Command History
Release 	Modification  15.3(3)M3
This command was introduced.  15.5(1)S
This command was integrated into the Cisco IOS Release 15.5(1)S. 

[g748437]

Hello @Tim Glen 

Question about this part:

Q: Which Password Types are portable between devices?

A: You can copy & paste Types 0,5,7,8,& 9 between devices.

I have tried to copy the Hash for a type 5 and type 8 from one Switch 2960X and use it on another 2960X. The result was that the user could not log in.

So my questions is if there any limitations or requirements for this to work? Configuration related maybe that affects the way the devices interpret the copied hash from another device?

Thanks 

[Tim Glen]

Hi @g748437 

That's very odd behavior. 

I've been copying \ and pasting enable secrets that were hashed with type 5 for years. This has always worked. I've tested copying \ and pasting a username and secret Type 8 combo on a few boxes and it seems to work just fine.  

I'm not aware of any limitations.  Sorry, I can't be more help,  I'd open a TAC case. 

Tim

[bim87]

What's the significant difference between a "standard type 9" hash and a "convoluted type 9" hash?

What's the specific method of defining a convoluted type 9, and or switching between the two?

Update

Found my own answer from NSA's Network Infrastructure Security Guidance:

"If a password is stored using a convoluted Type 9 secret where the secret 9
password hash begins with $14$, it indicates that the password was not recently
changed. The password hash was converted from Type 5 during a previous operating
system upgrade. The convoluted Type 9 secret should be removed by changing the
password to a Type 8 secret with the algorithm-type sha256 keywords"

[toormehdi]

Porting Configuration containing Type 6 passwords for Migrations/Upgrades

Thanks, @Tim Glen for putting this helpful resource and answering my questions earlier. I want to share something which a colleague and I found very interesting and hopefully, we can get some additional information/ reasoning from you or TAC for this.

We are in the process of migrating IPSEC services from ASR to CSRv

We had PSKs defined on ASR and they were encrypted using AES using a master key.

After we had ported the configuration containing many type 6 encrypted PSKs to CSR a bunch of IPSec VPN tunnels wouldn't come up and it made us wonder why.

Here are some observations:

- As you mentioned previously, it didn't really mater whether we defined the master key prior to copying and pasting the configuration. We can define the master key on the new device prior to pasting config or after. 

- Turned out that the keys which do continue to work on ASR but didn't work were on the CSR are the ones where or the original boxes (i.e. ASRs)  the keys were defined with administrator typing the keyword "key 6" when defining the keys. These were the ones which I had mentioned in the earlier comment that for some odd reason remain in clear text even though they are type 6. 

So on ASRs with password encryption aes enabled

• Any passwords / PSKs or other authentication credentials , if entered by the administrator explicitly typing out "key 0",  the box will convert them into key 6,  encrypted and displayed with hash in the running configuration
• Any passwords / PSKs or other authentication credentials, if entered by the administrator by explicitly typing out "Key 6", as understandable will not further encrypt and store it AS-IS in the running configuration.

Now here is what is odd when it comes to ASR vs CSR IOS XR code  

• On the ASRs the VPN peers are able to authenticate with the typed out "key 6" PSKs and one can see the actual key in the running configuration as they were typed
• On the CSRs the VPN peers weren't able to authenticate with the typed out "key 6" PSKs , as if CSRs are trying to decrypt those passwords using the master key since they are type 6, but they were stored in the running configuration as they were typed just like in ASR
• In order for us to make this work, we had to take  the previously defined/typed Key 6 PSKs and insert in CSRs as key 0 PSKs, so CSR can do its magical type 6 encryption and to our surprise this worked and solved our problem. 

So in conclusion, both ASRs and CSRs work similarly when it comes to realizing its user defined/typed key 6 credential and they wouldn't double encrypt/hash but when it comes to actual authentication/verification, ASRs work with what was entered and not try to decrypt it, but CSRs do not work since we assume it to be decryption it even though they never got encrypting in first place.

We wonder if this has anything to do with IOS XR versions, whether the observance above is due to feature change, enhancement or a bug.

[Rich R]

@toormehdi > "We wonder if this has anything to do with IOS XR versions, whether the observance above is due to feature change, enhancement or a bug."
That is impossible to answer without stating exactly what versions of IOS-XE/IOS-XR you were using on the ASR and CSR.  You didn't actually mention any full model numbers so you could be referring to products which run IOS-XE or IOS-XR so it would also be useful to clarify exactly what products you were referring to.

Another possibility is that you might have copied trailing spaces or special characters at the end of some encrypted keys which invalidated those keys - a mistake I've seen a number of times with passwords and keys in the past.

[nayzaw.win]

Can I check if NEXUS 7710 username creation support type 9 secret password?

Currently, all our username is type-5 password.

[RAHCDPBC]

I am looking for some clarification on this article. It states type 6 uses AES-128 and type 8 uses SHA-256. It the states that type 8 is decryptable, but SHA-256 is a hashing algorithm and is one way. Was this meant to be listed in type 6 that uses the AES-128 encryption method?

[Rich R]

@RAHCDPBC what it actually states is "I have not proven it but I believe it is possible that the popular tool HashCat is able to decrypt these".  Cracked may be a more accurate term than decrypted in this context.  https://hashcat.net/hashcat/ is very good at brute force cracking hashes - which is effectively the same as decrypting a password because it works out what string would produce the hash in question.  Hashes are one way, as you say, but with enough time, CPU power and the right techniques - they can be cracked.  By contrast an encrypted password (type 6) can be instantly decrypted with 100% certainty using the AES master key.