cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
73502
Views
29
Helpful
21
Comments
Tim Glen
Cisco Employee
Cisco Employee

History

Traditionally Cisco has used several different methods for storing passwords and keys in IOS.  The older methods are Type 5 (MD5 hash) & Type7 (Vigenere obfuscation). We enabled Type 7 encryption with the CLI service password-encryption command.

There are some newer methods like Type 8 (SHA256) and Type 9 (SCRYPT). At this time my recommendation is to never use Type 5 or Type 7 and absolutely do not EVER use Type 4.   

 

Today in 2021 the recommendation is to use Type 6, Type 8 and Type 9. Type 6 use strong AES 128-bit encryption for storing passwords. If you interested in the details for Types 0,4,5,6,7,8,9 please check out this other document I wrote. I’d like to make a counting joke here but I won’t.

 

Note: Using Type 6 has been supported since 2006, IOS 12.3(2)T and possibly earlier! 

 

For a detailed explanation of each password type please see this document I wrote. 

 

Requirements

In this example I’m working with devices that have reset to factory defaults.

  • Catalyst 9300 with IOS XE 17.3(3)

 Any device that runs modern IOS XE should support Type 6

 

 

 

Configuration Steps

1. Enable AES 128 password encryption

!
configure terminal
  password encryption aes
  key config-key password-encrypt super-secret-password
end
!

 

Managing the Keys

The super-secret-password you used is very important.  It's very important that you store the key somewhere offline.  Be sure to keep in it KeePass, or 1Password or the password vault of your choice. Optimally each device you configure Type 6 on will have a unique Key.

 

Changing the Password

There shouldn’t be too many reasons to change the password key. However, if you have the old password key, changing it is an easy task with no negative effects.

password key change example.png

 

 

Verification

These need to be reviewed \ changed.

Look into running config for Type 7 Passwords

show running-config | include _7_

 

Look into running config for Type 5 Passwords

show running-config | include _5_

 

 

These are safe to use.

Look into running config for Type 6 Passwords

show running-config | include _6_

 

Look into running config for Type 8 Passwords

show running-config | include _8_

 

Look into running config for Type 9 Passwords

show running-config | include _9_

 

 

FAQ

Q: Should we leave service password-encryption in the config?

A: Yes, while it shouldn’t be needed because we’ve enabled Type 6 passwords, leaving service password-encryption in the running config will cause any other Type 5 or Type 7 passwords to be obfuscated instead of being stored in the clear.

 

 

Q: Should I store the key ?

A: YES, the key should DEFINITELY be stored.  In the event that you need to move this devices config to a new device you will need the key.

 

 

Q: What passwords will be converted?

A: According to my tests the following passwords and password types will be converted:

  • TACACS server keys (previously in Type 7)
  • RADIUS server keys (previously in Type 7)
  • vty login passwords (previously in Type 7)

 

Q: What password types will NOT be converted?

A: According to my tests the following passwords and password types will be NOT be converted:

  • enable secret 9
  • BGP MD5 authentication password, instead use BGP TCP Authentication Option
  • OSPF MD5 authentication password, instead use HMAC Authentication
  • HSRP \ VRRP using key-string for authentication,  instead use authentication key-chain which will convert to Type 6

 

 

Q: Can you revert to non-Type 6 passwords?

A: Reverting to non-Type 6 is a manual process.

First, identify all type 6 passwords

Then issue

no password-encryption aes

Then, revert each of the previously identified Type 6 and reconfigure.

 

 

Q: What happens if I need to change the password encryption key?

A: This is typically not needed, however, if you still have the password, good, no problem!  Just change it, see the above example.

Q: What happens if I lose the password encryption key?

A: Moving the passwords in their encrypted form to a new box will be impossible.

Q: What happens if I lose the password encryption key and need to change the password encryption key?

A: I'd call Cisco TAC

Q: Where should I look for changes in the running-config?

A: Typically, I’ve seen Type 5 and Type 7 passwords in the following places:

  • username kashvi password …
  • enable password
  • RADIUS key
  • TACACS key
  • VTY login
  • BGP peer password
  • MKA preshared key

Q: Can I implement password encryption aes on an existing switch?

A: Yes, of course!   Please use the verification commands above to assure that all of your legacy passwords especially Type 5 and Type 7 are converted to the newer Type 6.

Q: I’m deploying a new switch \ router, how should it be configured?

A: Use the configuration script above right from the start. There is no need to use service password-encryption. 

Q: In the event I need to use Type 8 or Type 9 which is more secure?

A: Both Type 8 and Type 9 are secure, feel comfortable using either. 

Q: I don’t see key config-key password-encrypt in the running config…

A: Yes, you shouldn’t. Keeping the key in clear text would be insecure as it may provide a means to decrypt the passwords. The key is stored in a partition that is not accessible by the administrator.

Q: Can I configure Type 6 encryption on my router if my BGP, OSPF, EIGRP peer router doesn’t support it.

A: Yes!  Because the routing protocol’s process on your router will decrypt the password before using it with the peer this should not be a problem.  

Q: Should I be using enable password or enable secret?

A: Definitely use enable secret. If both are configured only enable secret is used.

 

References

Cisco IOS XE Command Reference (key config-key password-encrypt)

Cisco IOS XE Command Reference (password encryption aes)

Encrypt Pre-shared Keys in Cisco IOS Router Configuration

Cisco IOS Command Reference (service password-encryption)

 

 

 

Comments
Hello Kungfuu,

What I found out during my exercise to roll this out in our environment was
that type 6 encryption on radius/tacacs+ keys require 15.2(7)E3. Although
the 15.2.(4)E10 version does support type 6, it does not support type 6 for
radius/tacacs+ quite yet until 15.2(7)E3.

I believe the 3750X model maxes out at the 15.2.(4)E10 version you are
already using so unfortunately the answer is you can't encrypt
radius/tacacs+ keys on the 3750X model. The best you could do for
radius/tacacs+ key encryption would be to convert to type-5. It's not the
great but better than type-7

Fortunately for us, it wasn't a big deal as we were in the process of
upgrading all our IDF switches to 9200L shortly after, so we just replaced
those ones out first
kungfuu72
Level 1
Level 1

Great info. Thanks Neal.

 

On another note, do you know when converting type 7's to type 6's became available in IOS-XE?

TheSDAccount
Level 1
Level 1

> Is there a possibility of router getting its config via tftp or some other source with aes password encryption enabled and it never asking the admin interactively for typing in the master key which is typically the case when it’s enabled first time?

 

> I'm pretty sure this did not work on older IOS but haven't tried it on newer versions.  Test thoroughly.  But from a security perspective putting your clear text master key in the config with the encrypted literally defeats the purpose of the encryption so just don't even try to do that.  If you're going to give away your master key like that then just don't waste your time with encrypting the passwords - leave them in clear text.

 

So, is there an intended automatable method of deploying devices using type 6 credentials?

All permutations of "key config-key password-encrypt" have the potential to be interactive commands (even if logically you know they will not be because no key should exist during autoinstall), so I'm guessing that's what prevents standard automated methods working (ie, merging a file from somewhere to running-conf)

Surely we don't need to touch every newly-built device interactively from now on?  (And using local credentials, no less, as we're using type 6 to secure TACACS keys)

Rich R
VIP
VIP

@TheSDAccount previously you could pre-load a config with type 6 keys in it before the master AES key was configured.
IOS was not able to decrypt and use the keys until you configured the master key via console or SSH but the point was that you could deploy configs with securely encrypted keys that were safe from prying eyes.

Cisco, in their infinite wisdom, have decided to change this now. No, this change is not documented - they are slipping the behaviour change in with a years old bug they're retrofitting to new IOS releases.  IOS will now try to decrypt every type 6 key in the config immediately (on bootup or pasting it in) and if it can't be decrypted (due to no AES key) then the config gets rejected. Currently VPN keys (the oldest type 6 key) are not affected by this but Cisco have told us they will be soon - they intend to apply the change to all type 6 keys.

Despite numerous calls with BUs and developers there has not been a single person in Cisco who can give us a rational explanation for this decision but they insist they're doing it anyway because "somebody, somewhere decided it".  Trying to explain how this makes things less secure just falls on deaf ears.  Even worse: they justified it by saying they made the change because a customer managed to lock themselves out of their devices due to applying bad config so they're doing this to make it easier to break into a device that you've accidentally locked yourself out of - yep they actually said that!!!  When we pointed out that that is exactly what hackers and other malicious users want (devices that are easier to break into) they just went quiet.

We've now given up arguing this after numerous Webex calls and dozens of emails - there is literally nobody left in Cisco (that we or our account team could find) who understands this security properly.

TheSDAccount
Level 1
Level 1

I created my own ability to non-interactively set the master key.

This is a very stupid workaround, but it works.

 

event manager applet setkey
event timer countdown time 5
action 10 cli command "enable"
action 20 cli command "config t"
action 30 cli command "key config-key password-encrypt THEMASTERKEY"
action 40 cli command "no event manager applet setkey"
action 50 cli command "do copy run start"
exit
!

Rich R
VIP
VIP

Nice one @TheSDAccount <smile>

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: