No, you don't -- technically. But whether you can enter enable mode without one depends on how you log in.
Here's the instant gratification version:
You can enter via the console without an enable password, but you will be stuck in user mode if you use a simple vty login password without an enable password set.
Here's the long-winded StackExchange answerer version:
Cisco authentication is kind of a mess for a beginner. There's a lot of legacy baggage there. Let me try to break this down in a real-world sense.
Everyone that has any business logging into a router or switch pretty much goes directly to privileged (enable) mode. The user mode is basically a front lobby, and serves little more purpose than to keep the draft out. In large organizations where you have vast networks and equally vast pools of labor, it may be justifiable to have someone who can knock on the front door and make sure someone is still there. (That is, to log in and run the most trivial commands just to see that the device is, in fact, responding and not on fire.) But in every environment I've ever worked in, tier 1 had at least some ability to break things.
As such, and particularly in a scenario like yours, knowing the enable password is obligatory to get anything done. You could say this is a second level of security -- one password to enter the device, another to escalate to administrative privilege -- but that seems a little bit silly to me.
As already noted, you can (and many people do) use the same password, which doesn't help much if someone has gained unauthorized access via telnet/ssh. Having static, global passwords shared by everyone is arguably more of an issue than having just one token required to enter. Finally, most other systems (services, appliances, etc.) don't require a second layer of authentication, and are not generally considered insecure because of this.
OK, that's my opinion on the topic. You'll have to decide for yourself whether it makes sense in light of your own security stance. Let's get down to business.
Cisco (wisely) requires you to set a remote access password by default. When you get into line configuration mode...
router> enable
router# configure terminal
router(config)# line vty 0 15
router(config-line)#
...you can tell the router to skip authentication:
router(config-line)# no login
...and promptly get hacked, but your attacker will end up in user mode. So if you have an enable password set, at least you have somewhat limited the damage that can be done. (Technically, you can't go any further without an enable password either. More on that in a moment...)
Naturally, no one would do this in real life. Your minimum requirement, by default and by common sense, is to set a simple password:
router(config-line)# login
router(config-line)# password cisco
Now, you will be asked for a password, and you will again end up in user mode. If you're coming in via the console, you can just type enable
to get access without having to enter another password. But things are different via telnet, where you will probably get this instead:
$ telnet 10.1.1.1
Trying 10.1.1.1...
Connected to 10.1.1.1.
Escape character is '^]'.
User Access Verification
Password: *****
router> enable
% No password set
router>
Moving on... You probably already know that, by default, all your configured passwords show up as plain text:
router# show run | inc password
no service password-encryption
password cisco
This is one of those things that tightens the sphincter of the security-conscious. Whether it's justified anxiety is again something you have to decide for yourself. On one hand, if you have sufficient access to see the configuration, you probably have sufficient access to change the configuration. On the other hand, if you happen to have carelessly revealed your configuration to someone who doesn't have the means themselves, then ... well, now they do have the means.
Luckily, that first line in the snippet above, no service password-encryption
, is the key to changing that:
router(config)# service password-encryption
router(config)# line vty 0 15
router(config-line)# password cisco
Now, when you look at the configuration, you see this:
router(config-line)# do show run | begin line vty
line vty 0 4
password 7 01100F175804
login
line vty 5 15
password 7 01100F175804
login
!
!
end
This is marginally better than plain-text passwords, because the displayed string isn't memorable enough to shoulder-surf. However, it's trivial to decrypt -- and I use that term loosely here. You can literally paste that string above into one of a dozen JavaScript password crackers on the first Google results page, and get the original text back immediately.
These so-called "7" passwords are commonly considered "obfuscated" rather than "encrypted" to highlight the fact that it is just barely better than nothing.
As it turns out, however, all those password
commands are deprecated. (Or if they're not, they should be.) That's why you have the following two options:
router(config)# enable password PlainText
router(config)# enable secret Encrypted
router(config)# do show run | inc enable
enable secret 5 $1$sIwN$Vl980eEefD4mCyH7NLAHcl
enable password PlainText
The secret version is hashed with a one-way algorithm, meaning the only way to get the original text back is by brute-force -- that is, trying every possible input string until you happen to generate the known hash.
When you enter the password at the prompt, it goes through the same hashing algorithm, and should therefore end up generating the same hash, which is then compared to the one in the configuration file. If they match, your password is accepted. That way, the plain text isn't known to the router except during the brief moment when you are creating or entering the password. Note: There's always the chance some other input can generate the same hash, but statistically it's a very low (read: negligible) probability.
If you were to use the above configuration yourself, the router will allow both the enable password
and enable secret
lines to exist, but the secret wins from the password prompt. This is one of those Cisco-isms that doesn't make much sense, but it's the way it is. Furthermore, there's no secret
equivalent command from line configuration mode, so you're stuck with obfuscated passwords there.
Alright, so we now have a password that can't be recovered (easily) from the config file -- but there's still one problem. It's being transmitted in plain text when you log in via telnet. No good. We want SSH.
SSH, being designed with more robust security in mind, requires a little extra work -- and an IOS image with a certain feature set. One big difference is that a simple password is no longer good enough. You need to graduate to user-based authentication. And while you're at it, set up an encryption key pair:
router(config)# username admin privilege 15 secret EncryptedPassword
router(config)# line vty 0 15
router(config-line)# transport input ssh
router(config-line)# no password
router(config-line)# login local
router(config-line)# exit
router(config)# ip ssh version 2
router(config)# crypto key generate rsa modulus 1024
Now you're cooking with gas! Notice this command uses secret
passwords. (Yes, you can, but shouldn't, use password
). The privilege 15
part allows you to bypass user mode entirely. When you log in, you go straight to privileged mode:
$ ssh admin@10.1.1.1
Password: *****
router#
In this scenario, there's no need to use an enable password (or secret.)
If you're not yet thinking, "wow... what a clusterfudge that was", bear in mind there's a whole other long-winded post still lurking behind the command aaa new-model
, where you get to dive into things like external authentication servers (RADIUS, TACACS+, LDAP, etc.), authentication lists (which define the sources to use, and in which order), authorization levels, and user activity accounting.
Save all that for a time when you feel like getting locked out of your router for a while.
Hope that helps!
Best Answer
So I want to answer the questions as they appear.
Question: And when turning encryption on on all passwords like: service password-encryption, does it encrypt the encrypted password above, or does only encrypt the clear text password? Answer: Only clear text passwords are changed.
Question: If it encrypts the clear text password it will only be necessary to do enable password without encrypting it first, since service password-encryption will do it, how about that? Answer: Correct. The person entering the command will enter the password in clear text because the Cisco security mechanism will obscure it with a hash.
Question: One more thing. The key used for service password-encryption and enable secret is this dynamically made for each router or is it a static key, equal to all cisco routers(probably not)? Answer: No "encryption keys" are dynamically made because the password is not being encrypted. Instead, it's being "hashed". When you show the running config and look at the non-clear text password, it's in that format because the device took that clear text password and passed it through the MD5 hashing algorithm and saved the result in the config. So not even the device knows your clear-text password. Here's how it works. Let's say you type in your password to login. The device takes the password that you typed in and runs it through the MD5 hash and gets a result. If THAT result matches what's in the config file, you're in. No encryption needed.
BONUS: ENCRYPTION VS HASH To keep it simple since this bonus would be for another forum: Hashing algorithms such as MD5 are "cryptographic" by nature. BUT - the difference between a HASH and ENCRYPTION is that encryption is always "reversible" via DEcryption (the key that you spoke of earlier). A HASH is not mathematically reversible. It simply takes a character string, runs it through a mind numbing mathematical process then outputs a result. For example, if you take the letter A and put it through a mathematical hash algorithm like MD5, A would always (ALWAYS) result as 7FC56270E7A70FA81A5935B72EACBE29 (see onlinemd5.com). B would be something completely different than A's output, but the hash would ALWAYS give the same output for B every time. The more "complex" your hashing algorithm, the more "cryptographic" (not encrypted) your password is.