There's a number of ways that hackers -- let's call them unauthorized users -- can crack operating system passwords. The first, of course, is brute force. In this case, he or she gains access to the authentication screen of the system and gets the password through arithmetic trial and error. (Remember: The unauthorized user will also need a login name to go along with the password.) This is made substantially easier for the intruder if the system administrators use weak passwords that are easy to guess, or if system administrators fail to change default passwords (this includes default passwords used by vendors during the installation process). Believe it or not, sometimes users with access to the system password have the password written down (underneath their keyboards or the top drawers of their desks).
For systems that have remote access for vendor problem resolution and updates, there may also be default or common passwords in use. Sometimes IT staff will share the password with other privileged users, or use the same password for multiple systems. Passwords are also sometimes hardcoded into infrastructure software that may be compromised (i.e. directory synchronization scripts). Finally, in this economic downturn, administrators and other privileged users (like software developers) may walk away with system passwords if their passwords are not changed. These workers, who usually have an intimate knowledge of the inner workings of the organization, have been known to engage in malicious activity against the organization, or in some cases, to copy sensitive data (such as client account information) to sell or use for fraudulent activities.
So what are some strategies to prevent operating system passwords from being cracked? The answers can be lumped into three areas of security: processes, people and technology. Strategies for protecting system passwords include:
For processes (example policies and processes):
- Change all default passwords on each new and existing system.
- Don't use the same password for privileged user accounts between systems.
- Change passwords often (most organizations change the passwords on sensitive systems every 30 days or when personnel changes have been made).
- Restrict administrative access only to those personnel who truly need it.
- Never write down a system password (or any password).
- Do not allow software scripts to contain system-level account or password information.
- Create unique passwords for development and support personnel with access tailored to their function (someone developing a database shouldn't need root privilege in order to define the content fields -- though there will be arguments from them that they do).
- Maintain privileged accounts based on a worker's status. (When an employee joins a particular project team, create a new account based on the role performed. When his or her job changes, change or remove the privileges no longer needed. If he or she leaves the company, remove all privileges in a timely manner.)
- Where possible, disable an account after a predetermined number of failed authentication attempts.
- If the system contains highly sensitive information and requires minimal system-level access, consider the use of multifactor or hardware-based tokens in place of system-level passwords, and protect these under lock and key. Note: Some companies require multifactor authentication for any person accessing sensitive information.
- Use generated passwords or phrases (i.e. "the Philadelphia Phillies are the best baseball team in the league") and don't restrict yourself to alpha-numeric characters. Use symbols whenever possible instead of an eight-character password with numbers.
- Disable or disconnect any backdoor access to the systems until required (such as modems, Citrix access, etc.).
- Keep sensitive systems out of main business areas and communications closets, and provide physical isolation (cabinets with locks, computer rooms, locked offices, etc.).
- Protect and validate any backup media during a system recovery. (Old accounts can be reinstated as part of a system recovery, so ensure old data doesn't contain old authentication information. Change it or delete it immediately if it does.)
As in any case, common sense and direction from your security team, with cooperation from the IT department, should be used in determining the best methods of securing your system passwords.
For more information:
- Read more about best practices for a privileged access policy to secure user accounts.
- Learn how to make the case for enterprise IAM centralized access control.
This was first published in September 2009