|
|
|
|
|
|
| |
One-time password generators, encryption keys and biometric devices may offer excellent security but the fact is that most organizations use the cheaper and established User-Identification (user-ID or username) and Password log-on authentication process. Whilst some organizations should adopt more sophisticated (secure) tools and methodologies, in many cases such systems are not cost-effective. The traditional approach may well provide the security your organization needs. Even so, there is still room for optimizing the security of the typical password system. This article contains recommendations for beefing up the security of your password system. |
|
Password Assignment
One of the first issues in designing a password system is to decide whether passwords will be assigned to users or whether employees will be able to choose their own passwords. Studies have consistently shown that user generated systems are less secure because users are prone to select personally related words, common words and words in general. Words are likely to be in dictionaries that can be used by dictionary crackers (password cracking programs which compare words in a dictionary file with the secret passwords).
Words can also be cracked by brute force approaches based on the A to Z character set. Nevertheless, where a user-generated system is in force it is still possible to establish a number of password selection rules to increase
security. |
|
Composition
Passwords should consist of eight to twelve characters, derived from the entire character set (upper-case, lower-case, letters, numbers, special characters, symbols) available to users. This increases the time necessary for crackers to effect brute force password cracks, thereby increasing their exposure to being caught. Passwords should contain at least one number and at least one special character or symbol. This defeats dictionary cracking approaches which rely on comparing possible passwords with the words in a dictionary file. Note that dictionary files used by crackers include English dictionaries, foreign language dictionaries, names of films, people's (and pets') names and other word collections. |
|
Lifecycle
Passwords should be changed every two months and when employees leave the organisation. For accounts with access to highly classified or sensitive material, passwords may need to be changed monthly or weekly. The user should be assigned or asked to choose a new password before he or she can reconvene system usage. |
|
|
Logging In
A password should never be echoed or printed on screen during or following its entry by a user. A random character overprint, or a series of asterixes, usually help users ensure that they are typing in the correct password (the correct number of characters).
As soon as a user has obtained authorized access to his or her account, the following should be printed on screen: the time and date of each - or at least the last - password assignment/validation, and the person to whom it applies.
This enables a valid user confirm that he or she was the last person to use the account. If the time and date do not look familiar the user can contact the system administrator, as an unauthorized penetration might have occurred.
When logging-in, a user should be locked out of the system after three to five consecutive incorrect password attempts. The user should be forced to personally contact the system administrator (and present some kind of identification) in order to gain access. Also, following an incorrect password attempt, the system should pause for 30 to 60 seconds before invalidating the entry so that rapid retries (via an automated, high speed, trial-and-error password cracking program) can be prevented.
Once logged-in, a user should not be able to log in at a different terminal. Also, it is worthwhile establishing "approved times or hours" for logging in, so that any attempts outside these hours (by an intruder) will be denied. The approved hours could be standard working hours or hours negotiated between the system administrator and the user. |
|
Password Encryption
The transmission and storage of passwords should be encrypted. They can be encrypted using either one-way encryption or two-way encryption. One-way encryption systems transform the password so that no one can recover the original password. With two-way encryption it is possible to determine the original password from the encrypted version by comparing an entered password with the stored, decrypted password. One-way encryption offers better protection because when a user logs onto the system, his or her password is one-way encrypted. This encrypted version is compared with the stored, encrypted password. Hence, the same encryption method and key to encrypt the entered password must be used before a comparison can be made. Furthermore, passwords should be encrypted during transmission in order to foil wire-tapping. |
|
Terminal Management
Users should be encouraged to conceal the view of their password entry from passers-by. They should be required to log-out whenever they have finished an account session, even if it is only for only a matter of minutes. Having logged out they should clear their screen as quite often the user-ID is displayed as being logged out. After all, security penetration can occur in a matter of minutes. Ideally, a password-access screen saver should be installed on each terminal. This should be set to load after the terminal has been inactive for several minutes. If the wrong password is entered then the user is locked out and the system must be rebooted. |
|
Logs and Audit Trails
Password activity should be recorded by the system administrator to facilitate audit trails. Automatic logging is facilitated by most high-end operating systems or by third party applications. The following activities should be recorded: successful log-ins, unsuccessful log-in attempts, use of the password changing procedure, and the locking of a user-ID when the applicable password reaches the end of its lifetime. For each recorded event, the audit record should include the date and time of the event, the type of event, the offered user-ID for unsuccessful log-in attempts, the actual user-ID for other events, and the origin of the event (for example, the terminal or access port ID).
Where technically feasible the audit trail should not contain unencrypted (clear text) passwords, incorrectly entered passwords or character strings, because these could expose the password of a legitimate user who mistakenly types his or her user-ID or password. If possible, certain audit reports should be generated and distributed to users so that they can check for themselves whether someone else has used their account. Only authorised personnel, such as the system administrator, should have access to the audit trail file.
Also, passwords and the associated information should be stored in a highly secure area of the network - ideally on a stand-alone system not connected to the organisation's network. |
|
Real-time Notification
The system administrator should be automatically notified after an accumulation of three to five unsuccessful log-in attempts from a single access port or user-ID. Frequent notifications may indicate that a penetration attempt is in progress, warranting investigation.
As mentioned above, upon a successful log-in, the user should also receive notification of the date and time of his or her last log-in (attempt) and the location of the last log-in. The helps the user maintain vigilance over his or her own account. |
|
System Administrator's Responsibilities
The system administrator or person responsible for assigning passwords should firstly ensure that default user-IDs (for instance, SYSTEM, SUPERVISOR, GUEST, TEST, MASTER) and passwords are disabled or changed before anyone can use the network. One way of facilitating this is to establish all standard user IDs as being expired.
If it is necessary to prevent exposure of the password to the system administrator such measures as the following should be taken: ensure that the user is present during password generation (if a computer generation system is used) so that the user can obtain and shield the assigned password from the system administrator. Otherwise, if the password is to be sent or delivered to the user, print the password on a sealed multi-part form so that the password is not visible on the top page of the form.
Likewise, the system administrator should be able to generate or facilitate the change of the user's password without seeing it.
Where a user's password is to be changed on the belief that his or her account may have been compromised, the system administrator should verify the user's personal identification before changing the password. Ideally, the user should present him or herself personally to the system administrator. Otherwise, the verification should take place over the telephone with the system administrator confirming a number of personal and professional details in order to confirm the user's identity.
When a system administrator is required to create an account for a new employee it is important to keep the account inoperative until the newcomer is given, or chooses, a password. If a password generation system is used then the account should be opened in the presence of, and the password given to, the user. Where the organisation has a user generated process, the first log-in should be with an expired password which the user must immediately replace.
The system administrator should be promptly notified when an employee resigns, or is retrenched or dismissed. There should be an established account termination procedure, recognising that the user may continue to work for the organisation for a number of weeks. The user's system access should be limited to only those activities necessary to continue with his or her responsibilities until he or she leaves the organization. When the user leaves, the user-ID and password should be removed from the network.
In addition, the system administrator should regularly revalidate all user-IDs, passwords, organizational telephone numbers and work addresses (and any other relevant contact details). This ensures that an authorized person is responsible for his or her own account, telephone and work location. |
|
User's Responsibilities
Users of the network should assume a degree of responsibility for maintaining the security of the network resources they use. This includes taking all measures to keep their user-IDs and passwords secret (not kept in desks, on walls, sides of terminals, on post-it notes, stored in a function key or anywhere in the user's work-space); monitoring their own accounts for illegitimate use; reporting any suspected misuse; logging off when not using their machines; locking their floppy disk drives; ensuring that no illegitimate software is installed on their machines; and taking other security measures as deemed necessary by the organization.
It is highly desirable for each employee to undergo training in the organization’s security policy. As an example, the policies for changing passwords, should be clear to all personnel - that is, any instructions to change a password should meet with the established organizational procedure.
This enables users to recognize suspicious circumstances. An incident some years ago took place whereby someone posed as a system administrator and asked users to change their passwords. The cracker was then able to capture all the newly entered passwords! |
|
Special Rules for User-Generated Passwords
Apart from the recommendations described above, here are some specific guidelines that you can give to users who are required to select their own password:
Don't use a word contained in English or foreign language dictionaries, spelling lists, books of names or other lists of words.
Don't use your first, middle or last name in any form or any of your spouse's, children's or pet's names in any form.
Don't use personal information easily obtained from you (that is, likely to be found in a diary) such as the street number, suburb, town or city where you live; the birth dates of people close to you; the name of a sporting team you follow; and so on.
Don't use a password consisting of all digits or all characters.
Don't write your password down.
Do use a password of at least eight characters.
Do mix upper-case and lower-case.
Do mix numbers, letters and special characters.
Do include at least one special character or symbol.
Do use a method of remembering your password so that you won't have to write it down. |
|
Conclusion
Hopefully, the measures described above will assist you strengthen your password system. Give some consideration to establishing a computer generated password system, if you have not already done so. Although organizational personnel may baulk at first - and complain that they won't remember the words, etc - if the reasons for doing so are clearly and respectfully explained, it is likely that they will accept the new system. Also, once an employee is "forced" (has no choice but) to adopt a computer-generated password he or she will probably soon get used to it and have little difficulty remembering it. After all, our banks give us Personal Identification Numbers (PINs) which we are forced to remember in order to access money from an ATM machine. And most of us remember those! |
|
References
Frede, S. (1994) Internet Security, On the Net
Holbrook, P. and Reynolds J. (1991), Site Security Handbook
Stang, D. (1996) Passwords and Security |
|
| |
| Protecting PHP Scripts with HTTP Authorization Categories : PHP, HTTP, Security, Authentication | | | User Authentication With patUser (part 2) Categories : PHP, Authentication, Security | | | Emergency Response Part 2 of 2 Categories : Other, Site Planning, Security | | | Understanding Modern Denial of Service Categories : Security | | | SQL Injection Attacks: Are You Safe? Categories : General SQL, Security | | | PHP5: Designing And Using Interfaces Categories : PHP, Object Oriented, Interfaces, PHP Classes, Security | | | Writing Secure CGI scripts Categories : CGI, Security | | | Ecommerce security - The developer's side Categories : Ecommerce, Security, Site Planning | | | First issue of the SecuritySearch.Net Vulnerabilit Categories : Security, Vulnerability Report | | | Authentication 101 Categories : Apache, Web Servers, Authentication | | | PHP for Beginners by a Beginner: Simple Login, Logout, and Session Handling Categories : PHP, Sessions, Authentication | | | PHP, MySQL and Authentication 101 Categories : PHP, Databases, MySQL, Authentication | | | The Biggest Vulnerability of All, by Anna Johnson Categories : Human Factors, Security | | | Securing Directories With htaccess Categories : Apache, Security | | | User Authentication With Apache and PHP Categories : PHP, Web Servers, Apache, Authentication | |
| |
|
|