Password Management

This page focuses on password management issues, not good and bad passwords. It argues that the standard advice to never write passwords down is often wrong and needs to be evaluated in the context of each site's specific needs.

• When to Write Down Passwords
  
• Users and Passwords

When to Write Down Passwords

I'm going to take a contrarian point of view here and argue that one of the most widely repeated recommendations regarding passwords is simply wrong. In discussing how to create good passwords, ensure that users don't use bad passwords and protect existing passwords, no one (that I've seen) ever considers the security implications of lost root or administrator passwords. Security includes assuring access to systems as well as protecting systems from intruders and unauthorized access. A system that is inaccessible or unconfigurable due to a lost root or administrator password can be just as useless as a system crashed by a denial of service attack or trashed by intruders and may remain in this state much longer than a system brought down by a DOS attack.

The stronger passwords are, i.e. the harder they are for an informed human to guess or automated program to crack, the more frequently they are changed and the less frequently they are used, the more likely they are to be forgotten. Lost passwords are discovered when they are needed. Typically they are discovered when an administrator attempts to log into a server that is not frequently logged into as an administrator, to perform some configuration change or after a crash when some recovery procedure requiring administrative access is attempted. Just when it's needed, the administrator realizes he or she has forgotten the password. The person most likely to discover the forgotten password is the one who uses it most frequently, but not often enough to firmly fix it in memory. When other less frequent users of the account are queried, they are likely to have forgotten the password also.

There is nothing fictitious or hypothetical about lost administrator passwords. The problem is almost entirely caused by the widespread obsession with not writing passwords down (or the failure to follow site policies for administrator passwords where a site has formal policies). The discovery of lost passwords frequently comes at a bad time and there is a good chance that the person or organization that has forgotten the password does not know the techniques used to recover a lost password. Not all systems have documented procedures for recovering lost administrator passwords. By the time that the techniques for recovering a lost password are learned or a consultant who knows the techniques engaged or the system rebuilt, the consequences of a lost administrator password can be as severe as poor backup procedures or a successful intrusion.

Nearly everyone who discusses the matter, says passwords should never be written down, or if they are written down, multiple passwords should not be kept together or include account or system names. I disagree. Every site needs to carefully evaluate how to best protect passwords given the specific needs and characteristics of the site. I believe that for many sites this will include writing passwords down and keeping them in a secure place or places. In some cases it will even include writing system and or account names with the password. Personally, I believe that ordinary user passwords should never be written down (or shared) because an administrator can always give the user a new password, which the user may or may not have to change, whenever a password is forgotten. Once procedures for both administrator and user passwords are established, they should become policy and be documented.

Very small sites with one or less full time computer staff are perhaps the most vulnerable to lost passwords and to written passwords stored insecurely. Such sites are most likely not to have official policies on the matter. A single individual who administers systems is most likely to forget their passwords and the least likely to know password recovery procedures. They may forget or choose not to pass on the passwords when they leave their current position, especially if they leave under adverse circumstances.

Such sites should seriously consider a policy that requires the system administrator to write down administrator passwords and identify the system they go with, immediately following any password change. If the standard root or administrator account name is changed then the changed account name must also be included. As soon as the passwords are written down they should be placed in a sealed envelope and given to the person in charge or a specific designated person who has access to a safe or safety deposit box in which the passwords will be stored. The passwords should be spot checked at least once early in a new employee's tenure and the employee should know that it is grounds for termination if they do not provide accurate and timely password updates. Perhaps this too extreme but small businesses should consider the implications of how dependent they may be on a single individual who is the only one who knows all the administrative passwords.

If a site has several technical staff, who all know and use the adminstrative passwords to a very small number of computers and each is logged into frequently, there may be no need to write passwords down. Good passwords cannot be remembered unless they are used almost immediately; the action of typing the password helps. After a few times, your fingers to some extent remember the pattern of typing the password. With program generated passwords and different passwords for each system, I find that if I do not use a password for much over a week, even if I used it frequently for a significant period of time before, that I have considerable difficulty remembering it.

Once staff need to start remembering more than about three good passwords for different systems, the nature of most jobs will make it likely that some will be used much more frequently than others and that the less used are likely to be forgotten. If a few staff share administrative access to a few or more computers, writing the passwords in a standard order (without system identifiers) on small piece of paper that is kept in wallets or purses is adequate. When the number of systems reaches the point that it becomes confusing which password goes with which system or if staff have varying access to the computers, the machines should be identified. They should be identified by physical location or characteristics that cannot be determined on-line. Specifically passwords should never be identified by host name or IP address. When anyone with access to the passwords leaves or a purse or wallet lost or stolen, all shared administrative passwords should be changed. They should also be changed every two or three months or other period with which staff is comfortable.

I agree with most others that it is very poor practice to put passwords in any visible location or in any unsecured drawer or other container in the general vicinity of a computer. A Post-it on a monitor is about the worst possible place to keep a password. I think that given the nature of what is kept in purses and wallets, that very few staff leave these where they are not adequately secure for a typical business environment. I think these specific locations represent a good tradeoff between convenience and security. Alternatively passwords might be kept in secure, non personal, storage facilities. The possible impact of such storage on off hour operations, where a needed password is forgotten, should be considered. For example, if passwords are kept in locked drawer in an IT manager's office, will they be available when night or weekend staff may have need of them?

I can only speculate on how large sites with many servers, each of which may be accessed administratively by multiple staff, handle passwords but logically there are only a limited number of basic approaches. Every computer (or NT domain) might have a unique administrator password. As the number of unique passwords becomes large, this certainly creates serious management issues. Alternatively all computers that perform a similar functional role or access the same sets of resources could have the same password. This should simplify management issues but unless done carefully to assure that different functions are in fact protected by different passwords, could create security issues by giving some staff access to resources to which they should not have access. Sharing administrative passwords more widely, across unrelated machines makes no sense as it effectively negates any meaningful internal security and internal security is still as much an issue as external network threats. Large sites are going to have a significant number of passwords that will need to change either periodically or when employees leave. I can't visualize any scenario in which individual employees won't have to deal with more passwords than can reasonably be remembered.

I have difficulty imagining the persons who change the passwords, especially if they have to change several at a time, relying on their memory and verbally telling others who need to know, what the new passwords are. Hopefully its obvious why at least standard unencrypted e-mail is a less secure method of distributing new passwords than paper.

I can think of no form of electronic password storage that can be more secure than paper storage. For starters, electronically stored passwords may be accessible on the network with the computers they are supposed to protect. There are enough issues protecting shadow password files and SAMs without having to protect some file that has administrator passwords for all the systems at a site. If the computer is standalone, the situation is marginally better but in 18 years, I've never seen a single computer that I consider as secure as my wallet. If the passwords are in plain text, such as a word processing document, why not forget security and use e-mail as a convenient password storage and distribution system? If they are encrypted, whether its a password protected word processing document or one of the products to store and manage passwords there are new issues. Either the encryption is strong and can't be broken without the product/document password, in which case you are right back to where you started. How do you protect the password to the password storage location because if you loose that you are really in serious trouble. And if the encryption can be broken, your entire network is at risk if anyone who shouldn't, can get ahold of the file containing passwords.

Sorry, computer industry security experts, I have yet to hear of a security mechanism available to small businesses that's more secure or cost effective than a piece of paper and a wallet, purse or safe. If you know of one please let me know but until you do, please stop saying not to write down passwords.

By their very definition, good passwords that avoid easy associations, are not easy to remember. If not used frequently, they will be forgotten. Security policies should not try to prevent such passwords from being written down but insure that they are kept in appropriately secure locations with timely access by staff who need to use them.

Users and Passwords

Users tend to regard account names and passwords as nuisances. Given complete freedom in the matter, most would probably opt for short shared department account names without passwords. Given unique account names, users would prefer no password and if passwords are required will opt for the shortest, easiest to remember passwords, policy or the system will allow. Password cracking programs achieve the success that they do because most users insist on selecting from a small universe of easily remembered words and names. Users vary these as little as the system will allow when the system enforces length or character composition requirements on user selected passwords.

Most companies have new employee orientation which typically includes some introduction to the computer systems. This should always include training regarding passwords. It should include an explanation of any formal security policies that are in place and where to find the full policy. It should try to convince users of the useful role that good passwords play. If a real example of damage to the company or a similar company can be used, this might help convince the employees of the real need served by good passwords.

The training should discuss the characteristics of good and bad passwords. If examples of good passwords are presented in either a group setting or reused from session to session, the training should make clear not to use any example password as a real password. A password generator such as password.pl may be used to present a significant number of good passwords that change each viewing. The constants, and possibly the Perl source code, should be adjusted so the displayed passwords are consistent with the site policies and system requirements. Users should be discouraged from writing down passwords and be told that the IT department can clear their password or create a new one when needed. The IT department must be highly responsive when a lost password request is received or users will not regard this as a convenient approach and will write down passwords.

Many systems today allow an administrator to place some limits on the passwords users may select. These are rarely as flexible as security oriented staff would want. Some of the things that may be controlled are the minimum length of the password, the number of old passwords preserved to prevent users from reusing previous passwords, the number of alphabetic characters, the number of non alphabetic characters and the number of characters not in the previous password. Most systems allow setting a period after which users must change their password and a minimum amount of time between password changes.

If a system doesn't keep a history of meaningful length (8 or more) and doesn't enforce a minimum change interval, users can change their password when required and immediately change it back, effectively keeping the same password indefinitely. User's should not know what the history length is; it's best to simply tell them that the system does not allow the reuse of old passwords.

Often, products or options can be added to a system to force users to choose "better" passwords. If these are not configurable to your site and users, the passwords that they force users to create, may be too difficult. If the filter is not reasonably sophisticated, users may find trivial passwords that meet the requirements. If users have to use passwords they find too difficult to remember, they will write them down and they will keep them in the most accessible location not specifically forbidden in company policy. Most users have difficulty with any password that includes both upper and lower case letters, one or more digits and one or more symbols though these are typically the best passwords. Longer passwords with all letters may be a better solution for some users. Password checking tools available today are unlikely to be able to force users to use passwords that can't be cracked by sophisticated cracking tools. With training, these may encourage users to at least try to pick good passwords but that's about the best that can be hoped for.

The difficulty of required passwords should be considered in setting the time allowed between forced changes. The more difficult the system forces the passwords to be, the longer the interval should be. Even very difficult passwords that are used frequently will be learned and retained by most users. The more frequent the changes, the more likely the passwords will be written down. Rather than force ordinary users to change their passwords with excessive frequency, accounts should be disabled as soon as possible after employees leave a company. If the technology department receives advance notice of departures, they can take advantage account expiration options that most systems provide. Set departing user's accounts to be disabled automatically the day after their last day.

Most systems today allow administrators to assign passwords to users when the user is first created and when a password is forgotten. Typically the user is required to change this password the next time that they log onto the system so even the administrator will not know the password. In such systems, users should be instructed to never give their passwords to anyone, including system administrators. An alternative is to have system administrators assign all passwords and not allow users to change passwords. This will insure that passwords to conform to whatever character variation requirements that are required by the site policy. If passwords are changed on a periodic basis, this will impose a significant administrative burden.

Another approach relies more on training and policy than technology. A organization can adopt a policy that employees are solely responsible for their own password and are responsible for any activities conducted by their account, even if they can prove they were not or could not have been on the system at the time the activity in question was performed. If employees have recieved adequate training on password creation, then it is assumed that they either gave their password to someone, saved it on paper or electronically in a manner that someone was able to find it or did not follow instructions and created a password that could be guessed or broken. This approach is obviously mutually exclusive with administrator assigned passwords. Also network and security technology must be such that user passwords cannot be sniffed or obtained by other means. Further, password checking programs as discussed in the next paragraph cannot be used. In any of these situations, employees may correctly argue that others have access to their passwords and therefore the employee may not be reasonably held accountable for actions performed with the password.

As discussed previously, I do not believe password cracking programs provide a useful tool for system administrators. If they are to be used, no system administrator should ever take it upon themselves to use such a program without unequivocal permission from above. If the checking is being initiated at IT staff suggestion, not only should IT management give its approval but the general counsel, human resources or corresponding authority should also confirm that no organization policy or laws are being broken.

Two generalizations regarding passwords and security are true: 1) the use of good passwords as opposed to obviously poor passwords significantly improves security and 2) stronger passwords are harder to remember. Other common generalizations may be suspect. Hopefully this page has convinced the reader to question some of the common wisdom regarding passwords. If those responsible for the security of systems reject inapplicable generalizations, they have a much better chance of freshly evaluating how passwords and related policies can best be used to practically improve security at their site. The results may or may not be consistent with conventional recommendations.

Top of Page - Site Map

Copyright © 2000 - 2014 by George Shaffer. This material may be distributed only subject to the terms and conditions set forth in http://GeodSoft.com/terms.htm (or http://GeodSoft.com/cgi-bin/terms.pl). These terms are subject to change. Distribution is subject to the current terms, or at the choice of the distributor, those in an earlier, digitally signed electronic copy of http://GeodSoft.com/terms.htm (or cgi-bin/terms.pl) from the time of the distribution. Distribution of substantively modified versions of GeodSoft content is prohibited without the explicit written permission of George Shaffer. Distribution of the work or derivatives of the work, in whole or in part, for commercial purposes is prohibited unless prior written permission is obtained from George Shaffer. Distribution in accordance with these terms, for unrestricted and uncompensated public access, non profit, or internal company use is allowed.