Project Management

Help consulting clients create strong password policies

Strong passwords are a great start toward protecting clients' data, but clients need policies that clearly state user responsibility for protecting passwords and connections. Here are tips on what clients should include in their password policies.

 Passwords are the lock and key to your clients' data. While strong passwords are important, clients need to take security a step further and have a solid policy in place on password usage and protection.

Use these tips to help clients write and adopt a policy that protects their data and their users by protecting their passwords.


Some rules regarding passwords seem obvious, but don't take anything for granted. All password policies should state the following in some form:

  • Users should never share passwords with anyone else by speaking, writing, e-mailing, hinting at, or blatantly supplying any password. In some cases, this might even apply to sharing a password with in-house personnel such as a coworker, a direct supervisor, or even a head honcho. Help clients decide how strictly they want to enforce this rule in-house.
  • Users should never share passwords with other users who need to access your accounts in your absence. If users need access to your data, they should arrange with their in-house administrator or you to create a temporary account with the appropriate permissions.
  • Users should never write down their passwords and leave them visible or easily accessible. That includes taping the list to the back of a monitor or the bottom of a keyboard or thumbtacking it onto a bulletin board. Also, don't leave a list of passwords in an unlocked desk drawer or file cabinet.


Passwords slow down a would-be data thief, whether they're internal or external, but systems also need to react appropriately to a possible invasion. Help clients adopt the following policies, as appropriate:

  • A good guess at a password can get an intruder into your system quicker than you might think. Limit the number of times users can attempt to log on. You can help clients determine the right number (it's usually between three and five). Once the user reaches the log on limit, the system should automatically lock out the user for several minutes. The user can try again later or contact their in-house administrator (or you) to release the account.
  • Users should not use the following pieces of data when creating passwords (if the client's system allows users to create their own passwords):

    - Any part of their name or their account name; any part of any family members' names; any part of a pet's name; any part of the company's name; any part of your name or your consultancy's name. In short, no names, period.

    - Any part of their social security number; any part of anyone's social security number.

    - Any part of their birth date; any part of anyone's birth date.

    - Any portion or their address; any portion of the company's address; any portion of your address.

    - No nicknames

    - No slogans, logo text, company jingles, and so on


An active connection requires no password -- the user has already gone through the process of entering their password to gain access. Anything that user can access is vulnerable if they leave their system unattended. For that reason, it's imperative that users log off the network when they're done working or even if they leave their workstation for a few minutes. Here are possible logging out rules clients may want to enforce in a policy:

  • Users should never leave an active connection unattended.
  • Users should log off their network account when done working for the day.
  • Users who store confidential data locally should never leave their systems unattended, even if their confidential files are password protected. You can help users by enabling a password-protected screen saver on their systems.
  • Users who store confidential data locally should log off their PCs when done working.
  • Users who store confidential data locally should password protect their systems.

Passwords are the first line of defense in protecting data, but strong passwords aren't enough. Users must carefully guard their passwords and connections. Clients should apply these policies to all access, not just general user access. For instance, administrators and technicians should be subject to the same rules as users. In short, anyone with access to any part of the system should follow the same general password guidelines.

Additional TechRepublic resources

Get weekly consulting tips in your inbox TechRepublic's IT Consultant newsletter, delivered each Monday, offers tips on how to attract customers, build your business, and increase your technical skills in order to get the job done. Automatically sign up today!


Susan Sales Harkins is an IT consultant, specializing in desktop solutions. Previously, she was editor in chief for The Cobb Group, the world's largest publisher of technical journals.


Hello Susan I read your article with great interest. However, it doesn't touch on actual strong password CONSTRUCTION. We've recently published some password guidance for our staff, but I have a disagreement about something very fundamental - other members of staff feel that allowing special characters in passwords is fine, but, I personally disagree. About 9 months ago, I authored a file naming convention. In it, I suggest that certain characters should not be used in file or folder names. A common one would be the bang symbol (!) or exclamation mark, which is used by programmers to mean EXECUTE. If you embed ! in a path or filename, it's possible that a program could interpret it as a command, or at the very least when programs encounter the path it confuses or breaks them. I see this happen all the time at home, where I am working on encoding my CD collection to MP3. The program I use is not fault tolerant of special characters, so if the CD manufacturer has put a semicolon or a comma or any number of special symbols into one of the internal file names on the CD, the program won't encode it! I am forced to go in and MANUALLY change the name of the file (by REMOVING the semicolon or other symbol) and then the encode runs fine! So that's one practical, real world example of why it's NOT good to put symbols into you file or folder names. I extend this to passwords, because, as the above example indicates, programmers are NOT perfect, programs are NOT fault tolerant, and blindly assuming that multiple systems across your organisation will ALL be fault tolerant of symbols and special characters is a bit naive. Better to be safe than sorry, and avoid these characters altogther, in folder, file names, yes, but also in passwords. Here is the list of special characters that I have forbidden in folder and file names. QUOTE (from Stirling Council File Naming Convention) After an exhaustive look at invalid character restrictions in various environments, including Windows NTFS/FAT, Novell NetWare, and others, we have determined a "master list" of disallowed characters that should not be used in folder or document names: ` ! ? ? $ % ^ & * ( ) _ = + [ ] { } ; : @ # ~ , . < > ? / \ | And, any character you can type with the Alt or Ctrl key. QUOTE ENDS This is due to mainly to caution, but also based on personal experience - the example above of a program unable to parse a .cda file with special characters is NOT the only example I've seen over time. Special characters can also mess up imports of data, if they are embedded in a path for example that's stored in a data table. When the database program reaches that row, it doesn't know how to parse the character, so it either stops, or it skews the imported data, and you then have to go in, remove the character, and reimport. I propose to solve the whole problem by simply forbidding their use. I allow the hyphen character only, as it's extremely useful for separating concepts in folder or file names. Beyond that, there are PLENTY of strong password combinations available with a-z, A-Z, and 0-9. As long as it's long enough, it doesn't NEED special characters (which are hard to remember as well) increasing the chances of any problem. If every program was perfect, and if I could assure myself that every program was totally fault tolerant to all special characters, in either parsing data, importing data, or in passing a password about to validate a user's right of entry, then I probably wouldn't worry. But we aren't there yet. Not quite. Anyway, there is contention about adding this into our password policy. Some folk seem to think special characters are OK. I beg to differ. What is YOUR opinion? I am curious to know what people think about this. I think having special charcters in a password is dangerous, for reasons expressed above, but also, and more practical, it makes passwords MUCH harder to remember, so better to construct a strong password without using special characters - just upper/lowercase alpha, numeric, and hyphen - MUCH easier to remember since they are more common. And removes all danger of some strange problem caused by the presence of these characters. Your thoughts please! Dave

Editor's Picks