Why Authenticate?

Not too long ago, PCs didn’t require a user to type in their user name and/or a password. The computer powered up, and whoever was sitting at the keyboard had full access to anything stored on the machine. Even many networked computers were configured without a login requirement because, after all, “everybody was just like family.” This would be the ultimate “open” system.

It didn’t take long to determine that possibly everyone in the family doesn’t need to see the checkbook program or read each other’s e-mails, but, to protect those resources, it was necessary to know who was sitting at the keyboard. Some applications experimented with using passwords, and people learned to use password protection on shared resources like folders or printers. Once a password was created, it had to be shared with anyone who needed access. If more than one shared resource existed, one of two problems arose. Either unique passwords were necessary for each resource, requiring some users to keep track of multiple passwords and the resource they were associated with, or the same password was used, which meant any user who had legitimate access to one protected resource now had the password for all protected resources.

If someone left under less-than-favorable circumstances, all passwords known to that person had to be changed, and then the other users had to be told about the changes. These early efforts showed right away that leaving security up to the individual users wasn’t reliable and wouldn’t scale well as the network group.

Many organizations have this same problem with the user names/and or passwords used to access their network devices, such as routers and switches, by storing the access user name and/or password locally on the device. The following output demonstrates access requiring only a password (line con 0 and line aux 0) and access using the local database (line vty 0 4).

!
username xyzdotcom password cisco
!
line con 0
 password cisco
 login
line aux 0
 password cisco
 login
line vty 0 4
 login local
end

The preceding techniques were covered in Chapter 2. While both methods work, they have the same shortfalls and security issues as the early networking administrators faced with user data and applications. The example could be made more secure by using techniques covered in Chapter 2, including the following:

Using a different password for each access point
Using complex passwords containing eight or more characters, incorporating uppercase and lowercase letters, plus numbers and symbols
Requiring routine password changes
Using the service password-encryption command to hide the passwords from wandering eyes that could see the configuration

The encryption also reduces the chances of someone being able to capture the passwords if the configuration is included in a Telnet session. Telnet transmits all communications in cleartext.