Managing User Account and Password Security

Usernames and passwords are key to network security, and you use them to control initial access to your system. Although the network administrator assigns usernames and passwords, users can generally change their passwords. Thus, you need to ensure that users have information about what constitutes a good password. In this section, we’ll look at the security issues related to user accounts and passwords, including resource-sharing models and user account and password management.

Network Resource-Sharing Security Models

You can secure files that are shared over the network in two ways:

• At the share level

• At the user level

Although user-level security provides more control over files and is the preferred model, implementing share-level security is easier for the network administrator. Let’s examine these two security models and their features.

Share-Level Security

In a network that uses share-level security, you assign passwords to individual files or other network resources (such as printers) instead of assigning rights to users. You then give these passwords to all users who need access to these resources. All resources are visible from anywhere in the network, and any user who knows the password for a particular network resource can make changes to it. With this type of security, the network support staff will have no way of knowing who is manipulating each resource. Share-level security is best used in smaller networks, where resources are more easily tracked.

Note 

Windows 95/98 and Windows NT/2000 support share-level security.

User-Level Security

In a network that uses user-level security, rights to network resources (such as files, directories, and printers) are assigned to specific users who gain access to the network through individually assigned usernames and passwords. Thus, only users who have a valid username and password and have been assigned the appropriate rights to network resources can see and access those resources. User-level security provides greater control over who is accessing which resources because users do not share their usernames and passwords with other users (or at least they shouldn’t). User-level security is, therefore, the preferred method for securing files.

Note 

Windows NT/2000, NetWare, and Unix support user-level security.

Managing Accounts

First and foremost, you manage access to network resources through a user account and the rights given to that account. The network administrator is charged with the daily maintenance of these accounts. Common security duties include renaming accounts and setting the number of concurrent connections. You can also specify where users can log in, how often they can log in, at what times they can log in, how often their passwords expire, and when their accounts expire.

Disabling Accounts

When a user leaves the organization, you have three options:

• Leave the account in place.

• Delete the account.

• Disable the account.

If you leave the account in place, anyone (including the user to whom it belonged) can log in as that user if they know that user’s password. Therefore, leaving the account in place is a security breach. Deleting the account presents its own set of problems. If you delete an account and then create a new one, the numeric ID associated with that user (UID in Unix, SID in Windows Server) is lost. It is through this number that passwords and rights to network resources are associated with the user account. If you create a new user account with the same name as the user account you deleted, the identification number of the new account will be different from that of the old account, and thus none of the settings of the old account will be in place for the new account.

Note 

This same concept holds true for NetWare, although NetWare does not use a number to uniquely identify each entity. Each NDS object (including users) is a unique object ID.

Your best practice is to disable an account until a decision has been made as to what should happen to the account. Perhaps you’ll want to simply rename the account when a new person is hired. When you disable an account, it still exists, but no one can use it to log in. You might also disable an account (rather than deleting it) if someone leaves for an extended period (for example, on maternity/paternity leave or medical leave). In most network operating systems, disabling an account involves changing a setting to say something like Account Disabled.

Disabling Temporary Accounts

Because of the proliferation of contract and temporary employees in the information technology industry, you need to know how to manage temporary accounts. A temporary account is used for only a short period (less than a month or so) and then disabled.

Managing the accounts of temporary employees is easy. You can simply set the account to expire on the employee’s anticipated last day of work. The NOS then disables, but does not delete, these accounts on the expiration date.

Setting Up Anonymous Accounts

Anonymous accounts provide extremely limited access for a large number of users who all log in with the same username, which is often Anonymous or Guest. An anonymous login is frequently used to access FTP files. You log in with the username Anonymous and enter your e-mail address as the password.

Tip 

Users don’t necessarily enter their correct e-mail address. If you really want to know where on the Internet the user is located, use third-party software to verify IP addresses and Internet domain names.

Avoid using anonymous accounts for regular network access. If someone is using an anonymous account, you cannot track who manipulated a file. Windows NT/2000 comes with the anonymous account Guest disabled. NetWare does not automatically create a guest account. You should not change these default setups.

Some web servers create an Internet user account to allow anonymous access to the website. The Internet user account is automatically created and allowed to access the web server over the network. The password is always blank. You never see a request to log in to the server. This is done automatically. Without this account, no one would be able to access your web pages.

Warning 

Do not rename the Internet user account or set a password. If you do so, the general public will not be able to view your website. If you want to secure documents, use another web server, secure HTTP, Windows NT domain and file security, or NetWare Directory Services security.

Limiting Connections

You may want to limit the number of times a user can connect to the network. Users should normally be logged in to the network for only one instance, because they can only be in one place at a time. If the system indicates they are logged in from more than one place, someone else might be using their account. When you limit concurrent connections to one, only a single user at a single workstation can gain access to the network using a particular user account. Some users, however, might need to log in multiple times in order to use certain applications or perform certain functions. In that case, you can allow the user to have multiple concurrent connections.

Limiting the location from which a user logs in can be important also, because typical users shouldn’t log in to the network from any place but their own workstation. Although in theory this is true, it is not often implemented in most corporations. Users move stations, often not taking their computers with them. Or they have to log in at someone else’s station to perform some function. Unless you require really tight security, this restriction requires too much administrative effort. Both NetWare and Windows NT/2000 can limit which station(s) a user is allowed to log in from; however, by default, user accounts are not restricted in this respect. This is probably acceptable in most cases. If you really want to tighten security, restrict users to logging in from their assigned workstations. By default, Windows NT/2000 servers do not allow a regular user to log in at the console because most users should not be working directly on a server. They can do too much damage accidentally. In NetWare, the console interface is entirely different and is not used to access network resources, so this is not an issue.

Renaming the Maintenance Account

Network operating systems automatically give the network maintenance (or administration) account a default name. In Windows NT/2000, this account is named Administrator; in Unix, it is Root, and in NetWare, it is Admin. If you don’t change this account name, hackers already have half the information they need to break in to your network. The only thing they’re missing is the password.

Rename the account to something innocuous or use the same naming convention that is used for regular users. For example, jmorris is a much better choice than super is. Here is a list of common names that you should not use:

• Admin

• Administrator

• Analyst

• Audit

• Comptroller

• Controller

• Manager

• Root

• Super

• Superuser

• Supervisor

• Wizard

• Any variation on the above

Managing Passwords

Like any other aspect of network security, passwords must be managed. Managing passwords involves ensuring that all passwords for user accounts follow security guidelines so that they cannot be easily guessed or cracked, as well as implementing features of your network operating system to prevent unauthorized access.

What Makes a Strong Password?

Generally speaking, a strong password is a combination of alphanumeric and special characters that is easy for you to remember and difficult for someone else to guess. Unfortunately, many users try to make things easy on themselves and choose passwords that are easy to guess. Let’s look at some characteristics of strong passwords.

Minimum Length

Strong passwords should be at least 8 characters, if not more. They shouldn’t be any longer than 15 characters so that they are easy to remember. You need to specify a minimum length for passwords because a short password is easily cracked. For example, there are only so many combinations of three characters. The upper limit depends on the capabilities of your operating system and the ability of your users to remember complex passwords. Users will forget passwords that are too long, so you must balance ease of remembrance with the level of security you need to implement.

The Weak List

Here are some passwords that you should never use:

• The word password

• Proper names

• Your pet’s name

• Your spouse’s name

• Your children’s names

• Any word in the dictionary

• A license plate number

• Birth dates

• Anniversary dates

• Your username

• The word server

• Any text or label on the PC or monitor

• Your company’s name

• Your occupation

• Your favorite color

• Any of the above with a leading number

• Any of the above with a trailing number

• Any of the above spelled backward

There are others, but these are the most commonly used weak passwords.

Using Characters to Make a Strong Password

Difficult-to-crack passwords do not have to be difficult to remember and include a combination of numbers, letters, and special characters (not just letters, not just numbers, not just special characters, but a combination of all three). Special characters are those that cannot be considered letters or numbers (for example, $ % ^ # @). An example of a strong password is tqbf4#jotld. Such a password may look hard to remember, but it is not. The following sentence uses every letter in the English alphabet: The quick brown fox jumped over the lazy dog. Take the first letter of each word, put the number 4 and a pound (#) symbol in the middle, and you have a strong password.

To consistently get strong passwords, you can use auditing tools, such as a crack program that tries to guess passwords. If you use strong passwords, the crack program should have great difficulty guessing a password. Use special characters and numbers in the middle of the password, for example, under43gate@w#ay. Do not use just a regular word preceded or ended by a special character. Good crack programs strip off the leading and trailing characters in their decryption attempts.

Here are a few examples of strong passwords:

• run4!cover

• iron$steel4

• four$score

I’d include a few more, but I don’t want to give away all my secrets!

Warning 

Never write your password on a note and stick it under your keyboard or on your monitor. This is the most common network security breach.

NOS Password Management Features

All network operating systems (including NetWare, Unix, and Windows NT/2000) include functions for managing passwords so that the system remains secure and passwords cannot be easily hacked with crack programs. These functions include automatic account lockouts and password expiration.

Automatic Account Lockouts

Hackers (as well as users who forget their passwords) attempt to log in by guessing the user’s password. To ensure that a password can’t be guessed by repeatedly inputting different passwords, most network operating systems have a feature that allows the account to be disabled, or locked out, after several unsuccessful login attempts. Once this feature is enabled, the user cannot log in to that account even if the correct password is entered. This feature prevents a potential hacker from running an automated script to continuously attempt logins using different character combinations for the password.

After a lockout is activated, to log in successfully the user must ask the network support staff to unlock the account if the network operating system doesn’t unlock it after a preset period. In high-security networks, it is usually advisable for an administrator to manually unlock every locked account rather than letting the NOS do it automatically. In this way, the administrator is notified of a possible security breach.

Warning 

Be careful not to lock yourself out. With many network operating systems, only administrators can reset passwords. If you are the administrator and you lock yourself out, only another administrator can unlock your account. If you are the only administrator, you have a problem. Many NOS vendors do have solutions to this problem, but the solution will cost you.

Password Expiration

Passwords, even the best ones, do not age well over time. Eventually someone will guess or crack a password if it never changes. The impact of someone guessing your password is reduced—even if a password is guessed—if passwords are set to expire after a certain amount of time. After this time (which varies and can be set by the administrator), the old password is considered invalid, and a new one must be specified. This new password is valid until it expires and another password must be specified.

Most organizations set up passwords to expire every 30 days. After that, users must reset their passwords immediately or during the allotted grace period. Some systems give the user a few grace logins after the password has expired. As the administrator, you should limit this grace period to a number of times or days.

Tip 

Each network operating system specifies a password expiration period. If your organization’s policy states that users must change their passwords every 30 days, check to see if your operating system is enforcing that. For example, in NetWare the default expiration date is every 40 days and therefore might need to be changed.

Unique Passwords and Password Histories

In older versions of many network operating systems, users could reset their passwords to their original form after using an intermediary password for a while. More recent network operating systems prevent this practice by using password histories.

A password history is a record of the past several passwords used by the user. When the user attempts to use any password stored in the password history, the password fails. The operating system then requests a password change again. When implementing a password history policy, be sure to make the password history large enough to contain at least a year’s worth of password changes. For a standard 30-day life span password, a history of 12 or 13 passwords will suffice.

Advanced users know about the history feature. Creating a good password takes some time. Once a user finds a password, the human tendency is to want to keep it and use it for everything, which is counter to good security policy. If a user really likes a particular password or does not want to remember a new one, he or she will try to find a way around password histories. For example, one user admitted changing her password as many times as it took to defeat the history log. She then changed the password one last time back to her original password. This can take less than five minutes of a user’s time.

Administrators can force users to change their passwords so that they are unique. The latest operating systems (including NetWare 4.x and later, as well as Windows NT 4) require unique passwords. All passwords are stored, and, depending on the NOS, more than 20 passwords can be stored. Reverting to any of the previous passwords is not allowed.