Enable Secret vs Enable Password
-
I'm in the process of renewing my CCNA and figured I would go through the CCENT and CCNA videos as a quick refresher before sitting the exam. In watching the first few videos in the CCENT series, I noticed that on a couple occasions, when discussing the various password security methods, you mentioned that the 'enable password' password, the little-to-no encrypted password method, would still work if used in conjunction with the stronger 'enable secret' method. Basically, it was said that both would work. I do not believe this is the case.
Once you set the 'enable secret', it effectively disables the 'enable password' password from working any longer to grant priv-exec mode. I believe the only exception would be on very old versions of IOS (but that wouldn't really be relevant for the tests). The 'enable password' is only still present for backwards compatibility but will likely be phased out soon since no one really uses it anymore. This is why it warns you about setting the same password for both -- if you do, even though the 'enable password' won't actually work, it would allow someone to see what the valid 'enable secret' password is and gain access.
So basically, as long as you have the 'enable secret' set, which is what should be used, the 'enable password' can be anything else without concern -- though it should just be disabled.
Unless I'm missing something.
-
Thanks for pointing that out. I didn't realize that one disabled the other.
I just tried it on both ios 15 and 12.4 and yep, using enable secret does disable the enable password. But what I notice is it doesn't get rid of it. So if you issue a no enable secret command the enable password is once again active. That could be an easy mistake to make if someone thinks they are getting rid of the priv exec password when the enable password is still there.
-
Correct, if you remove the 'enable secret', it would leave the other and make it active again. So it's definitely better not to use it at all IMHO.
My understanding is that it's only still even available for backwards compatibility and for working with very old boot images that don't support 'enable secret'. I don't think the latter really applies anymore so I wouldn't be surprised if Cisco just removes it completely soon.
-
@enki
They would mention it.There is one command I ran into that warns it's going to be "deprecated." It has to do with AAA. my mind is drawing a blank right now.
That was my first time running into that term in IOS. A little googling and I learned that is how code is replaced. You warn of deprecation than you just do it.
-
@enki @Daniel-Espinosa
You're correct in the fact that it does prefer the secret over the regular password. At the same time remember it doesn't mean that the enable password isn't in effect. It is as you've stated in a later post,still in effect just not being used and if you remove the enable secret that the enable password is still there.
For the exam, though if both are configured, remember that the
enable secretwill be preferred if deciding between which one will be used.Cisco is has consistently insisted on commands being deprecated (e.g.
do wrforcopy run start) yet both commands continue to find their home in the IOS. This isn't uncommon since there are so many piece of Cisco's old equipment that is still being used out there.
