Types of Authentication

When attempting to gain management access to a Cisco router, this can be done in a variety of ways, including the following:

  • Console port

  • Auxiliary port

  • Telnet

  • Hypertext Transfer Protocol (HTTP) and HTTP with Secure Socket Layer (HTTPS)

  • Secure Shell (SSH)

  • Simple Network Management Protocol (SNMP)

Each of these methods presents a certain level of security risk. However, you can secure each method by using password authentication. You can authenticate access in many ways, including the following:

  • No passwords

  • Static passwords

  • Aging passwords

  • One-time passwords (OTP)

  • Token card services

Each of these authentication methods has advantages and disadvantages. The following sections cover these methods in more detail.

No Password Authentication

The worst type of authentication method is to not configure passwords on your device, whether on a Cisco router or even your PC. If some networking devices do not have passwords, they prevent remote access to the device. This is true of Cisco routers with Telnet. If a virtual type terminal (VTY) line and a privileged EXEC password have not been configured on a Cisco router, you cannot Telnet to it.


Note that it is possible to allow VTY access to a router without a line password by using the no login command. Never do this on a Cisco router because anyone then can remotely Telnet to your router without authenticating.

However, I would never leave this to chance. Always configure some method of authentication for every type of access in the device?or, if possible, disable methods of access that are not used. Some type of authentication method is better than nothing.

Static Password Authentication

The most common method of authentication is to use static passwords, with or without user accounts. This is probably one of the most popular methods of securing Cisco routers. However, static passwords have the following problems:

  • If the account password becomes compromised, the device is compromised. You can fix this by changing the password, but you might not detect this for a period of time, if at all.

  • How static passwords are chosen can create security risks. Using names, birthdays, and common words is popular among users. A good password should have a mixture of letters, numbers, and special characters.

  • The most secure form of a static password is a random string of characters, but this presents another security issue: Users write down these passwords because they are hard to remember, and they tape them to the border of their monitors, available for everyone to see.

  • Some methods of access require multiple people to perform the same tasks using the same account, such as root in UNIX or Administrator in Microsoft Windows. When the administrators use the same account, it becomes more difficult to manage: More people have access to the password, making the account less secure. It becomes a management headache to manage password changes because multiple people must be notified.

  • Static passwords are susceptible to eavesdropping attacks if the password information is not encrypted (such as with Telnet connections).

  • These passwords are susceptible to password-cracking programs if a hacker can gain access to your password file.

Typically, static passwords are used in small environments in which access attacks are not that much of a concern; however, they are, by no means, a secure method of authentication.


I highly recommend that you not use accounts that are required on a system, such as root in UNIX or Administrator in Windows, for management purposes. Instead, create a separate management account for each administrator, and let each user assign a password to the account that falls under the guidelines defined in your security policy concerning passwords. Then disable the default management account by assigning a random string of letters, numbers, and special characters. Lock up this password in case you ever need access to these accounts in emergency situations. Plus, you always should monitor attempted access to these disabled accounts: This indicates that a probable access attack is occurring.

Aging Password Authentication

To help overcome the issues that static passwords have, some administrators use aging passwords. With aging passwords, the password is valid for a predefined period of time. When the time period expires, the password is no longer valid. Typically, a password history file is used to ensure that when a user is forced to change his password, it isn't changed to a password that the user previously used for the account.

Most administrators think that by using aging passwords, they have removed all the disadvantages of static password configurations. In reality, aging passwords are not that much more secure than static passwords. About the only advantage that aging passwords have over static passwords is that if an account was compromised and the user of the account was forced to change the passwords, the hacker then is locked out of the account.


Most hackers are aware of this process and install keystroke-capturing programs that you install in the login script that is executed when the user logs in. In this situation, if the user is forced to change the password, the capturing script sees this information and sends it to the hacker.

Given the ingenuity of the hacker to use keystroke-capturing programs, aging password authentication does not have any real advantage over static passwords. Note that Cisco routers support static passwords, but they do not support aging passwords.


My main concern with static and aging password authentication is that they are susceptible to eavesdropping attacks for many types of remote-access connections, such as Telnet, FTP, HTTP, RCP, RSH, and others. Therefore, if you are using static or aging passwords, I highly recommend that you use some method that encrypts the authentication information between the user and the resource, to prevent eavesdropping attacks. Some remote-access tools that you can use include SSH, HTTPS, and Secure Copy (SCP).

Also be careful about backing up resources across the network, especially because their password files will be susceptible to eavesdropping. Chapter 5 discusses how you can centralize authentication functions and keep user and password information on a security server that you can back up locally. Chapter 5 also discusses how to securely back up a router's configuration file, to prevent eavesdropping attacks.

One-Time Password Authentication

One-time passwords (OTPs) were developed specifically to deal with the limitations and security issues of static and aging passwords. Unlike static and aging passwords, OTPs can be used only once: After a password is used, it no longer is valid.

A password-generator program is used to generate a list of passwords, with the S/Key algorithm, which uses an MD5 hash function, generating the list. This process typically is accomplished through a password calculator program in which the user enters a secret key or phrase into the program. The program then generates a file containing a list of valid OTPs. The passwords can be used for authentication purposes for resources that use the S/Key algorithm. When a password is used, it becomes invalid.

OTP authentication has a few advantages over static and aging passwords:

  • The applications that users employ do not have to be changed, easing the implementation of OTP.

  • These passwords are typically secure from password-cracking programs because of the nature in creating these random passwords. However, if the hacker can guess the secret key that was used to generate the list of passwords, there is a chance that he can determine the OTPs that were generated.

  • OTP defeats eavesdropping attacks. Even if a hacker sees the password, it is too late to use it because the user is authenticated and the password becomes invalid.

  • If a hacker is lucky enough to guess a randomly generated OTP, he is granted access to the account one time; subsequent access requires the hacker to get lucky again guessing a randomly generated OTP.

OTPs have one main disadvantage: They generate a file with the random OTPs. Because the file might contain 10, 20, or even 100 passwords, the user has a tendency to print this file and keep it on or in his desk. The user then uses this printout to log in to a device, choosing one of the passwords in the list and crossing it off after it is used. Anyone who has access to the user's desk can compromise his account.

In addition, if this file is printed to a network printer, it can be compromised through eavesdropping. Note that Cisco routers do not support OTP innately.


The main weakness of OTPs is that they are susceptible to eavesdropping. When the hacker knows the passwords stored in the file, he easily can gain unauthorized access to this user's account; from here, the hacker can install keystroke-capturing and backdoor programs to overcome the OTP authentication method for authorizing access to the user's device or resource.

Token Card Services

Of all of the methods discussed so far, the most secure authentication method is to use token cards and token card services. When using a token card solution, a user uses a special hardware device called a token card. This card is about as small as a credit card or PCMCIA card, but it has integrated circuits and typically an LED display. This card is synchronized with a token card server by the time of day.

One of two methods is used to handle authentication with token card services:

  • Time-based authentication

  • Challenge-based authentication

With the first method, the user enters a password or PIN into the token card, which then is used on a one-way hash function along with the time of day. Note that the time of day is not an exact time, but it is based on a time period. Therefore, the card and the token card server must have a time defined on them that is not very different. This information, along with the account name, is sent to the service that the user is trying to log in to, as shown in Step 1 of Figure 3-1. In Step 2, the service forwards this information to a token card server. The token card server then looks up the user's account name in a local database, along with the user's password or PIN; it runs it through the same one-way hash function that the token card used, along with the time of day. The token card server authenticates the request and passes back the result, shown in Step 3. In Step 4, the service passes back the authentication success or failure to the user.

Figure 3-1. Token Card Authentication Process


With the second method of handling authentication with token card services, instead of using the time of day, the token card solution uses a challenge, which is synchronized between the card and the token card authentication server. The challenge used with this kind of token card solution is similar to the challenge that PPP's CHAP uses. Otherwise, the authentication process is the same as that shown in Figure 3-1 with the time of day token card solutions.

The main advantage of this solution over the OTP process described in the last section is that a token card solution does not generate a file of valid random passwords: A password is generated each time that the user needs to authenticate.

However, token card solutions have their own set of problems:

  • Cost

  • Additional software

  • Synchronization between the token card and token card server

Probably the main disadvantage of token card servers is their cost: You need a token card for each server (they run about $50 to $75), and you need a server with token card software running on it to handle authentication requests. For many companies, this can be cost prohibitive.

Second, to use a token card solution, your resources must support integration of token card software. This is not always possible, based on your service or resource. For example, a Cisco IOS router does not support authentication directly to a token card server. Instead, it requires a central authentication server, such as Cisco Secure ACS, which handles the interoperability with the token card server (again, this increases your implementation cost). In some instances, some devices, services, or resources do not support token card integration.


The Cisco Secure ACS authentication server supports integration with the following token card solutions:

  • ActivCard Token Server 3.1

  • CRYPTOCard CRYPTOAdmin 5.16

  • PassGo (formerly AXENT) Defender version 5.16

  • RSA ACE/Server version 5.0 and ACE/Client version 1.1.2 for Windows 2000

  • Secure Computing PremierAccess Server version 3.1

  • Vasco Vacman Server version 6.0.2

The third problem with token card solutions deals with the synchronization between the token card and the token card server. It is important to point out that because the random OTP that is generated by the token card uses the time of day or a challenge, the card and the token card server must be synchronized; otherwise, authentication will fail. This can present a manageability issue for aging cards because the battery process used on the cards might cause a synchronization problem. Troubleshooting this kind of problem is not easy. Plus, when the token card generates the random password, it is typically good for only a short period of time, such as 1 minute. Therefore, the user immediately must type in the OTP to authenticate or will have to re-enter his password or PIN on the token card to generate a new password. This can create a lot of headaches for your users, especially slow typists.

Token card servers typically are used in environments that need to use random passwords to prevent eavesdropping attacks in secure environments. In these situations, companies are very concerned about access attacks, and the additional cost of a token card solution is negligible compared with the repercussions of a hacker gaining unauthorized access to a critical resource. Also, if you need to access services and resources remotely across a public network on which passwords are susceptible to eavesdropping, a token card solution provides a secure authentication solution.