S 4.48 Password protection under Windows systems
Initiation responsibility: Head of IT, IT Security Officer
Implementation responsibility: Administrator
For all users, access to a Windows system (Windows NT and higher) must be protected by a password, and the automatic login function should not be activated. No user account should exist without a password since such an account makes the system more vulnerable. This also applies to disabled accounts. Guest accounts must be disabled in general It is important for the users to know the protective function of passwords since the co-operation of the users contributes to the security of the entire system. The additional recommendations in this safeguard are based on S 2.11 Provisions governing the use of passwords.
New users are configured and passwords for them are defined in Windows NT with the help of the User Manager utility opened using the "New user" command. In Windows 2000 or higher, the Local Users and Groups snap-in of the Microsoft Management Console (MMC) must be used on stand-alone computers for these tasks. On IT systems in Active Directory domains, new users are created using the Active Directory Users and Computers MMC snap-in. Each time a new user is created, an initial password must be entered in the Password and Password Confirmation fields. Note that the password is case-sensitive. When a new user is created, a reasonable and unique initial password that complies with the password rules of the institution must be assigned, and the user must be informed of this password. This also applies when a password is reset by the administrator. Always selecting the same initial password or using the user name as the password opens up a security gap that must be avoided.
The User must change password at next logon option should be set for all new accounts so that the initial login password is not retained. However, the "User cannot change password" option should only be used as an exception, for example for pre-defined accounts used during training sessions. The Password never expires option should only be used for user accounts that were assigned to services using the Services Control Panel option (for example, the MS Exchange service account). This option disables the Maximum Password Age setting in the policy for accounts and prevents passwords from expiring.
Under Windows 7 and Windows Server 2008 R2, two special types of account were introduced - the Managed Service Account and the Virtual Account. Contrary to the accounts used previously for management of services such as Local Service, Network Service or Local System, both accounts can be managed centrally as they are either stored in the organisation unit "Managed Service Accounts" within the Active Directory (Managed Service Accounts) or - like the virtual account - can be controlled as a managed local account via the computer identity in a domain environment. Further information on the virtual accounts are described in S 4.284 Handling of services under Windows Server 2003 and higher.
Password policies
In Windows NT, the User Manager can be used to specify policies for user accounts, user rights, and system monitoring. In Windows 2000 and higher, the policies are specified using the MMC Local Security Settings snap-in or the Group Policies snap-in. The parameters and values can be found in the snap-in under Security Settings | Account Policies.
In this case, the group policy settings for the IT systems connected to a domain should be distributed and enforced using Active Directory (see S 2.231 Planning of group policy under Windows 2000 and S 2.326 Planning the Windows XP, Vista and Windows 7 group policies). In Windows 2000 and higher, a security template must be created for the security policies (see also S 2.366 Use of security templates under Windows Server 2003).
The requirements for passwords and their assignment in Windows systems should be documented in a security policy. The documentation and policies should include the settings listed in the following table. The last column contains minimum recommendations for a normal protection requirement:
Windows NT | Windows 2000/XP/2003 | Windows Vista/7/2008 | |
---|---|---|---|
Maximum Password Age | Maximum Password Age | Maximum Password Age | 90 days |
Minimum Password Age | Minimum Password Age | Minimum Password Age | 1 day |
Minimum password length | Minimum password length | Minimum password length | 8 characters |
Password Uniqueness | Enforce password history | Enforce password history | 6 passwords |
Account lockout | Lockout after | Account lockout threshold | Account lockout threshold | 3 attempts |
Account lockout | Reset count after | Reset account lockout after | Reset account lockout after | 30 minutes |
Lockout duration | Account lockout duration | Account lockout duration | 60 minutes |
User must log in to change password | n/a | n/a | disabled |
n/a | Passwords must meet complexity requirements | Passwords must meet complexity requirements | enabled |
n/a | Store password using reversible encryption for all users in the domain | Store passwords using reversible encryption | disabled |
When specifying the settings, some system-specific security aspects must be taken into account. These aspects are explained in the following.
The minimum password length for accounts requiring special protection (e.g. for service accounts) should be greater than 14 characters. However, this does not work in Windows NT. In this case, passwords for such accounts should be required to be changed more frequently. Considering the increasing availability of computing power, long passwords are the most effective protection against brute force attacks.
The password history should always be enabled and maintain a history of at least 6 passwords. This prevents users from always using the same password over and over. The validity period for passwords should be limited to a maximum of 6 months. By specifying a value for the Minimum password age, it is possible to prevent users from changing their passwords several times in a row in order to bypass the password history function. A minimum password age of 1 day or less should be selected, though, so that the user can change his or her password at any time.
Note: In Windows NT, the Allow Changes Immediately option must not be selected under Minimum password age because this disables the check for the password in the password history.
User accounts should be locked after repeated unsuccessful attempts to enter a password to make it more difficult to guess the passwords of the users (e.g. as is done in brute force attacks). According to the values in the table, an account will be locked after three unsuccessful login attempts within a 29-minute time span. If a user only attempts to log in twice unsuccessfully, he will be granted three new login attempts 30 minutes after the last attempt.
In general, only an administrator should be able to unlock a locked account. With the Account lockout duration setting, the account can be unlocked automatically after a certain time has expired. The time period specified may not be shorter than the Reset account lockout after period and should in no case be set to less than 30 minutes. In principle, automatic unlocking significantly reduces the level of security. If the time and effort required to manage the users and the possibility of production downtimes due to locked user accounts makes it necessary to use automatic unlocking, then a suitable compromise encompassing the highest level of security possible must be found. Note, though, that this function should always be deactivated for accounts requiring special protection.
It must be ensured that the automatic lockout option is disabled for the pre-defined administrator account (built-in administrator) to prevent you from completely locking yourself out of the system.
In Windows Vista and Windows 7, the built-in administrator account is deactivated by default. The password policies configured apply equally to the group of administrators and to the group of standard users. If the password policies are configured so that user accounts are locked after several incorrect password entries, then it is not impossible to completely lock yourself out of the system when the built-in administrator account is deactivated.
If the built-in administrator account should remain deactivated, then this problem should be counteracted by selecting a suitable time frame for the Account lockout duration setting. The time frame must be selected carefully as the account can be broken more easily if it is automatically reactivated after a certain time period.
In Windows NT, the User must log in to change password option should not be used. When used in combination with the User must change password at next logon, this setting will prevent any new users from gaining access to the computer.
If password policies are implemented at the domain level, then it becomes impossible for domains up to Windows Server 2003 to specify additional password requirements for domain accounts. Only the local accounts on the servers that are members of the domain can be assigned policies. If it is absolutely necessary to have operating areas with different password requirements, then this can only be accomplished using several Active Directory forests. The time and effort needed to implement such forests is rarely justifiable. That is why a compromise must be made when specifying the password requirements for all operating areas (service accounts, administrative accounts, general user accounts, user accounts of managers, user account for the personnel representative etc.).
Since the introduction of Windows Server 2008 and the corresponding Active Directory it is possible to use various password policies (granular password and account lockout policies, i.e. Fine-Grained Password Policy) within a domain. This offers the possibility to provide to critical accounts or accounts requiring protection, e.g. domain administrators, longer passwords than with the other accounts of the domain. Strictly speaking, these are not policies, but so-called Active Directory objects. These objects are denominated Password Setting Objects (PSO). Within a PSO, various attributes such as "Enforce password history" or "Minimum password length" are available. These attributes correspond to the known attributes of a previous password policy. The following prerequisites must be met for use of granular password and account lockout policies within a domain:
- The function mode of the domain must correspond to Windows Server 2008.
- PSOs cannot be applied directly on organisational units (OU). They only apply to user objects, global security groups and inetOrgPerson objects.
- Only one PSO can be used per user.
- PSOs can only be used for users or groups within the same domain.
Microsoft Windows and other software automatically creates various accounts and assigns random passwords to them. Here too, the policies must be enforced. If the manufacturer's documentation does not include any information an this, enforcement and compatibility with the software must be tested in each case.
Review questions:
- Is every NT-based Windows system and every user account protected by a password?
- Is there a security policy available for password requirements and password assignments?
- Has the automatic login function been disabled?
- Is the User must change password at next logon option enabled for all new accounts?
- Will the group policy settings for systems that are connected to a domain be distributed and enforced using the Active Directory?
- Is there a security template for the Account Policies (for Windows 2000 and higher versions)?
- Are the specifications for the user account policy documented?