Password Security

Lab Objectives

• Configure router and switch password security: set the enable secret, console password, VTY password, and enable password encryption.
• Verify the configuration and understand why each setting is required in production networks.

Lab Tasks (Try It Yourself First!)

Complete these tasks WITHOUT looking at the solution below. Use ? and show commands to figure it out.

ASCII Topology (BASE LAB TOPOLOGY — exact IPs shown on every interface)

                    [Internet]
                   203.0.113.1
                        |
                   R1 (Gateway)
              Gi0/0: 10.10.10.1
              Gi0/1: 10.10.20.1
              Gi0/2: 10.10.30.1
                  /     |     \
               R2      R3      R4
   Gi0/0: 10.10.10.2   |   Gi0/0: 10.10.30.2
   Gi0/1: 10.10.40.1   |
              /  \      |
           S1    S2    S3
          /  \    |   /  \
        PC1  PC2 PC3 PC4  PC5

Task 1: Configure Enable Secret on R1

Set the privileged EXEC password to Lab@123 using an encrypted secret.

Task 2: Configure Console Password on S1

On switch S1, set the console line password to Lab@123 and require login at the console. Also set an exec-timeout of 5 minutes.

Task 3: Configure VTY Password and Enable Password Encryption on R1

On R1, set the VTY (telnet/SSH) password to Lab@123, require login, and enable service password-encryption so plaintext passwords in the configuration are not visible.

Think About It: Why is enable secret preferred over enable password, and why is service password-encryption considered only a minimal protection in production?

---

Lab Solution

Task 1 Solution: Configure Enable Secret on R1

What we are doing: We set a cryptographically hashed privileged EXEC password so unauthorized users cannot enter enable mode and change configuration.

R1# configure terminal
R1(config)# enable secret Lab@123
R1(config)# end

• configure terminal — enters global configuration mode to change settings.
• enable secret Lab@123 — sets the enable secret password to Lab@123. The secret is stored hashed (Type 5/Type 8) in the running-config.
• end — returns to privileged EXEC mode.

Why this matters: The enable secret protects privileged mode. Unlike enable password, enable secret uses a one-way hash and is the recommended secure option. In production, this prevents an attacker with read-only access to a configuration file from easily recovering the enable password.

Verify:

R1# show running-config | include enable secret
enable secret 5 $1$EXAMPLE$abcdabcdabcdabcdabcdab

• Expected output shows enable secret 5 <hash> (hashed form). The actual hash will differ on your device; you should NOT see the plaintext Lab@123.

Tip: If show running-config displays enable password (plaintext), replace it with enable secret immediately.

---

Task 2 Solution: Configure Console Password on S1

What we are doing: We secure the management console so physical access or console sessions require authentication, and we set an inactivity timeout.

S1# configure terminal
S1(config)# line console 0
S1(config-line)# password Lab@123
S1(config-line)# login
S1(config-line)# exec-timeout 5
S1(config-line)# end

• line console 0 — selects the console line for configuration.
• password Lab@123 — sets the console password to Lab@123.
• login — requires authentication using the password configured on the line.
• exec-timeout 5 — sets an inactivity timeout of 5 minutes for the console session; this logs out idle users.
• end — exit configuration mode.

Why this matters: The console is a local management port often used for initial configurations and recovery. Requiring a password prevents unauthorized configuration changes when someone has physical access. The exec timeout reduces the risk of an unattended console session being exploited.

Verify:

S1# show running-config | section line con
line con 0
 password 7 08314D5A1C0A
 exec-timeout 5
 logging synchronous

• Expected output shows the console line configuration. Note that if service password-encryption is not enabled, the password may appear in plaintext; with encryption enabled it shows a Type 7 cipher (example above). The exact cipher text will differ.

---

Task 3 Solution: Configure VTY Password and Enable Password Encryption on R1

What we are doing: We require authentication on remote management lines and hide plaintext passwords in the configuration file.

R1# configure terminal
R1(config)# line vty 0 4
R1(config-line)# password Lab@123
R1(config-line)# login
R1(config-line)# end
R1# configure terminal
R1(config)# service password-encryption
R1(config)# end

• line vty 0 4 — selects virtual terminal lines 0 through 4 (common for up to 5 simultaneous remote sessions).
• password Lab@123 — sets the VTY password.
• login — requires the password for remote access (Telnet). For SSH, you would typically use login local with local accounts (covered in advanced lessons).
• service password-encryption — causes the router to obfuscate (Type 7) all plaintext passwords in the running-config to prevent casual observation.
• end — exit configuration mode.

Why this matters: VTY lines control remote device access (Telnet/SSH). Without login and password, anyone could access the device remotely (if management plane is reachable). service password-encryption is useful to hide plaintext passwords from casual viewers; however, Type 7 encryption is reversible and should not be relied on as strong protection in sensitive environments.

Verify:

R1# show running-config | section line vty
line vty 0 4
 password 7 08314D5A1C0A
 login
 transport input telnet
R1# show running-config | include service password-encryption
service password-encryption

• Expected output shows the VTY section contains an encrypted password (Type 7) and login. transport input telnet indicates Telnet is allowed — in production, you would prefer SSH and login local.

Important: service password-encryption changes displayed passwords to Type 7 obfuscated form only; it does not change enable secret which is already hashed securely.

---

Troubleshooting Scenario

Scenario: Console access still accepts no password

Symptom: A colleague can access S1 console without being prompted for credentials. Your task: Find and fix the issue. Hint: Which console line sub-mode command enforces authentication?

Solution:

• Likely the login command is missing under line console 0. Add it:

S1# configure terminal
S1(config)# line console 0
S1(config-line)# password Lab@123
S1(config-line)# login
S1(config-line)# end

• login enforces line-based password checking. Without it, the console does not prompt.

---

Verification Checklist

• enable secret set on R1 (show running-config | include enable secret shows a hash)
• console password and login configured on S1 (show running-config | section line con)
• VTY password and service password-encryption set on R1 (show running-config | section line vty; show running-config | include service password-encryption)

Common Mistakes

Symptom	Cause	Fix
Console still drops to prompt without asking for password	login is missing under line console 0	Add login under console line
VTY not prompting for password	login missing under line vty 0 4	Add login under VTY lines
Passwords visible in running-config	service password-encryption not enabled (for Type 7)	Run service password-encryption (note: Type 7 is weak)
Using enable password instead of enable secret	Older command used — plaintext or less secure storage	Replace with enable secret Lab@123

Challenge Task

Configure R1 to allow only SSH (no Telnet) on VTY lines and require SSH authentication using a local username (admin) with password Lab@123. Do NOT follow step-by-step — build the local user, enable SSH, set line vty 0 4 to transport input ssh and login local. Verify using show run | section line vty and show ip ssh.