3

I'm trying to update the enable secret and account password on a Cisco3560-CG switch with an encrypted password shared by devices throughout the company. I use the following command for the enable secret and get the following output.

enable secret 5 <encrypted password>
ERROR: The secret you entered is not a valid encrypted secret. To
enter an UNENCRYPTED secret, do not specify type 5 encryption. When
you properly enter an UNENCRYPTED secret, it will be encrypted.

We've used this encrypted password successfully on many other devices so I know it's a valid encrypted secret, but we haven't used it on any other 3560-CG's.

We've tried updating to the latest OS (15.2.2E6) and rolling back to 15.0.2 and neither helps. I can add an enable secret in clear text, but that doesn't work for our organizational policy.

Has anyone else run into this issue on this or any other model of Cisco switch?

Improve this question

1 Answer 1

Reset to default
3

You are receiving the error because the "password" you are entering is not a proper MD5 hash. Check to verify that you are trying to enter a complete MD5 hash and that it is not another type of hash. Cleartext, Type 4 or Type 7 passwords will not suffice.

You may be trying to use a password obscured by a Vigenère cipher. The Vigenère cipher is often refered as a Type 7 password. It is associated with the service password-encryption and enable password 7 supersecretpwcommands.

Type 7 password hashes look something like this:

098f6bcd4621d373cade4e832627b4f6

Type 5 (MD5) hashes look a little something like this:

$1$jR5i$.HDBuKq.wIDOn2EYpCPYc0

Cisco Type 5 hashes will always be comprised of 3 elements, separated by $.

For the above example:

  • 1 - Denotes a salted hash
  • jR5i - 24-bit randomly generated salt value
  • .HDBuKq.wIDOn2EYpCPYc0 - MD5 hash

Jeremy Stretch does a great write-up on how Cisco leverages MD5 here:

http://packetlife.net/blog/2008/jul/9/a-bit-more-detail-on-ios-password-hashes/

Improve this answer
4
  • TDurden, thanks for the info. What we're using is definitely an MD5 hash. It is structured as you've showed above, and it also works as type 5 on other devices. I was able to force it by copying the config to ftp, adding the enable secret and username/pw manually, and then doing a config replace. Everything works as expected after that, so the issue is sort of "fixed" but the question of why the process doesn't work from the CLI remains.
    – ams264s
    Commented Mar 15, 2017 at 16:20
  • Glad the workaround works. Best guess is that there could have been trailing spaces or you might be running into a bug. bst.cloudapps.cisco.com/bugsearch/bug/CSCsy24510 has something similar but there is not much information.
    – TDurden
    Commented Mar 15, 2017 at 17:33
  • 1
    Yeah I'm guessing a bug. I've checked and double checked trailing spaces, plus the command originally failed from a script which would have failed for all the devices were it trying to push out a malformed hash. Oddly enough, after doing the config replace, the MD5's are working from the CLI again. I'll go ahead and mark your answer as correct since the problem seems to be resolved for now. Thanks for your help.
    – ams264s
    Commented Mar 15, 2017 at 18:25
  • I got the same issue in 15.2(2)E5 and it was because of the salt length.
    – palvarez
    Commented Oct 1, 2019 at 12:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.