Almost all passwords and other authentication strings in Cisco IOS configuration files are encrypted using the weak, reversible scheme used for user passwords. To determine which scheme has been used to encrypt a specific password, check the digit preceding the encrypted string in the configuration file. If that digit is a 7, the password has been encrypted using the weak algorithm. If the digit is a 5, the password has been hashed using the stronger MD5 algorithm. For example, in the configuration:
enable secret 5 $1$iUjJ$cDZ03KKGh7mHfX2RSbDqP
the enable secret-encrypted password has been hashed with MD5, whereas in the command:
username jbash password 7 7362E590E1B1C041B1E124C0A2F2E206832752E1A01134D
the password has been encrypted using the weak reversible algorithm.
Will the Algorithm Be Changed?
Cisco has no immediate plans to support a stronger encryption algorithm for Cisco IOS user passwords. If Cisco should decide to introduce such a feature in the future, that feature will definitely impose an additional ongoing administrative burden on users who choose to take advantage of it.
It is not, in the general case, possible to switch user passwords over to the MD5-based algorithm used for enable secret, because MD5 is a one-way hash, and the password cant be recovered from the encrypted data at all. In order to support certain authentication protocols (notably CHAP), the system needs access to the clear text of user passwords and, therefore, must store them using a reversible algorithm.
Key management issues would make it a nontrivial task to switch over to a stronger reversible algorithm, such as DES. Although it would be easy to modify Cisco IOS to use DES to encrypt passwords, there would be no security advantage in doing so if all Cisco IOS systems used the same DES key. If different keys were used by different systems, an administrative burden would be introduced for all Cisco IOS network administrators, and portability of configuration files between systems would be damaged. Customer demand for stronger reversible password encryption has been small.
Assessing the Need for Security
As more users access the Internet, and as companies expand their networks, the challenge to provide security for internal networks becomes increasingly difficult. Companies must determine which areas of their internal networks they must protect, learn how to restrict user access to these areas, and determine which types of network services they should filter to prevent potential security breaches.
It should now be obvious that security must be a consideration at all levels of your network. Complacency is also something you should try to avoid when considering security. The rapidly advancing sophistication of technology means that your security measures are limited in the length of time they will be effective.
Golden Rules of Designing A Secure Network
Security measures keep people honest in the same way that locks do. Cyber thieves by their very nature go after the least defended part of a network. Consider this analogy. In a neighborhood where 25 percent of the homes have home security systems, thieves will target the least defended homes (those without security systems) first. This section provides specific actions you can take to improve the security of your network whether you already have network security in place or are designing a new network.
Document Your Security Plan
This does not mean write down all the network passwords under your keyboard! Instead, as you go through this process of identifying and designing your network security you need to document your findings and resulting security actions. Having a written living security document is vital to proper implementation of your overall network security strategy. It will also help those that come after you understand why the network security was implemented and designed in such a way, so it can also be a learning tool for future network engineers. This document should not be publicly accessible.
Know Your Enemy
This statement refers specifically to cyber thieves who are either attackers or intruders. Consider who might want to circumvent your security measures, and identify their motivations. Determine what they might want to do and the damage that they could cause to your network. For example, does your organization deal in money, electronic commerce, or sensitive data? Any of these can be of value to a thief.
Security measures can never make it impossible for a user to perform unauthorized tasks with a computer system. They can only make performing unauthorized tasks harder. The goal is to make sure the network security controls are beyond the attackers ability or motivation.
Count the Cost
Security measures usually reduce convenience, especially for sophisticated users. Security can delay work and create expensive administrative and educational overhead. It can use significant computing resources and require dedicated hardware. Just as in anything in life, nothing that is worth having is free; you must work for the results you want to receive.
When you design your security measures, understand their costs and weigh those costs against the potential benefits. To do that, you must understand the costs of the measures themselves and the likelihood of security breaches. If you incur security costs out of proportion to the actual dangers, you have done yourself a disservice. For example, very few organizations can actually justify having the extreme security measures found within the Department of Defenses (DOD) network. Yes it is effective, but at what cost?
Identify Your Assumptions
Every security system has underlying assumptions. For example, you might assume that your network is not tapped, or that attackers know less than you do, or that they are using standard software, or that a locked room is safe. All of these assumptions are most likely incorrect and could cause holes in your security policy. Be sure to examine and justify your assumptions. Any hidden assumption is a potential security hole.
A nice rule of thumb here is to be painfully honest concerning your network security requirements and remember that when assumptions are incomplete or not duly considered, it can cause disastrous consequences. Sometimes when you are identifying your assumptions you might find an area of concern within your network that has nothing to do with security, so this is truly a double-edged sword.