SAP Note 2467 - Password rules and preventing incorrect logons

Validity: valid since 25.02.2008

Symptom

You have questions about passwords in SAP systems.
This note answers the following questions:

1. Which rules apply to changing the password?

2. What can be configured in the system?

3. How is the password stored?

4. How is the password transferred using the network?

5. Can a user without an authorization profile execute functions in the SAP system?

Other terms
Passwords, security, authentication
Reason and Prerequisites
You require information.
Solution

1. Which rules apply to changing passwords?

• When an administrator creates a user account (of the type DIALOG or COMMUNICATION, see Note 622464), they assign an initial password that must be changed immediately when it is first used.

           The lifetime of initial passwords can be restricted (see Notes 379081 and 450452).

• Passwords that are reset by the administrator must also be changed by the user during the next (interactive) logon.

           The lifetime of reset passwords can be restricted (see Notes 379081 and 450452).

• By default, the password must have at least three characters. You can change this value using the profile parameter login/min_password_lng.

• The password can have a maximum of eight characters (ABAP systems up to Release 7.0). As of NetWeaver 7.0, ABAP systems support longer passwords (up to 40 characters) and also differentiate between lowercase letters and uppercase letters (see Note 862989).

• ? or ! cannot be the first character of a password.

• The first three characters of the password cannot occur in the same order in the user ID.

           Remark: As of Release 6. 10 (Web Application Server), this rule was removed. It applies only in all releases up to Release 4.6D.

• The first three characters cannot be identical.

• The first three characters cannot be blank characters.

           Remark: As of Release 6. 10 (Web Application Server), this rule no longer applies. The system checks this only in releases up to Release 4.6D.

• The password cannot be "PASS" or "SAP*".

• The administrator can define patterns of "illegal passwords" (table USR40).

• You can use all characters from the syntactical character set, that is, all letters, digits, and some special characters.

           Remark: As of Release 6. 10 (Web Application Server), the password rules were enhanced. In these releases, you can define the minimum number of digits, characters, or special characters that must be contained in the new password.
                    login/min_password_digits
                    login/min_password_letters
                    login/min_password_specials

• The system does not differentiate between uppercase and lowercase (ABAP systems up to Release 7.0). As of NetWeaver 7.0, ABAP systems support longer passwords (up to 40 characters) and also differentiate between lowercase letters and uppercase letters (see Note 862989).

• The password can be changed by the user only after the correct old password was entered.

           Remark: Prior to Release 6. 20 (Web Application Server), the password can be changed only during the logon procedure. As of Release 6.20, the password can also be changed by following the menu path "System > User Profile > Own Data" (SU3).

• The new password must differ from the old password by at least one character (that is, they cannot be identical).

           Remark: As of Release 6. 10 (Web Application Server), you can define the minimum number of characters that must be different between the old password and the new password (login/min_password_diff).

• The last five passwords that were chosen by the user are stored in a user-specific password history and cannot be reused.

           Remark: The size of the password history is static (5) and cannot be maintained (ABAP systems up to Release 7.0). As of NetWeaver 7.0, you can define the size of the password history (see Note 862989: login/password_history_size).

• The password can be changed by the user once a day at the most. This rule prevents users from bypassing the password history rule. As of NetWeaver 7.0, you can configure this lock period (see Note 862989: login/password_change_waittime).

           Remark: The administrator can reset user passwords at any time. In this case, during the next logon, the system prompts the user to change the password. The lock period mentioned above applies only to cases in which the user requests a password change. For forced password changes, it is disabled.

• Changed password rules do not affect old passwords. Password rules are evaluated only during the password change itself.
  
  As of NetWeaver 7.0, you can specifically prompt certain users to change their passwords early. These are users whose passwords do not comply with the current password rules (see Note 862989: login/password_compliance_to_current_policy).

As of Release 6.10, you can use the function module PASSWORD_FORMAL_CHECK to determine whether a given string corresponds to the current password rules.

2. What can be configured in the system?

              The following profile parameters are available for setting password rules and preventing unauthorized logons:

• login/min_password_lng
  This parameter defines the minimum length of the password.
  Default value: 3
  Allowed values: 3 - 8 (as of Release 7.0: 1 - 40)

• login/min_password_digits (as of Release 6.10)
  This parameter defines the minimum number of digits (0-9) in passwords.
  Default value: 0
  Allowed values: 0 - 8 (as of Release 7.0: 1 - 40)

• login/min_password_letters (as of Release 6.10)
  This parameter defines the minimum number of letters (A-Z) in passwords.
  Default value: 0
  Allowed values: 0 - 8 (as of Release 7.0: 1 - 40)

• login/min_password_specials (as of Release 6.10)
  This parameter defines the minimum number of special characters in passwords.
  Special characters are:  !"@ $%&/()=?'`*+~#-_.,;:{[]}\<>
  Default value: 0
  Allowed values: 0 - 8 (as of Release 7.0: 1 - 40)

• login/min_password_diff (as of Release 6.10)
  This parameter defines the minimum number of characters that must be different in the new password in comparison to the old password. (The system tries to find the best match by rotating both passwords. More detailed information about this is available in the online documentation (RZ11)).
  Default value: 1
  Allowed values: 1 - 8 (as of Release 7.0: 1 - 40)

• login/password_expiration_time
  This parameter defines the number of days after which the password must be changed.
  Default value: 0 (no limit)
  Allowed values: Any numeric value

• login/fails_to_session_end
  This parameter defines the number of unsuccessful logon attempts before the system closes the session. We recommend that you set this parameter to a lower value than the value of the parameter login/fails_to_user_lock.
  Default value: 3
  Allowed values: 1 - 99

• login/fails_to_user_lock
  This parameter defines the number of unsuccessful logon attempts before the system locks the user.
  By default, users that were locked due to unsuccessful logon attempts are unlocked at midnight.
  Default value: 12 (as of Release 7.0: 5)
  Allowed values: 1 - 99

• login/failed_user_auto_unlock
  This parameter defines whether password locks (that were set due to multiple failed password logon attempts) are automatically to be considered as expired at midnight.
  Default value: 1 (as of Release 7.0: 0)
  Allowed values: 0, 1

• login/no_automatic_user_sapstar
  For information, see Notes 2383 and 68048.
  Remark: The default value was changed as of NetWeaver 7.0.

• rdisp/gui_auto_logout
  This parameter defines the maximum idle time in seconds for a user (valid only for SAP GUI connections).
  Default value: 0 (no limit)
  Allowed values: Any numeric values

In addition, in the table USR40, you can define character combinations or terms that cannot be used as passwords. In this table, you can use the characters "*" and "?" as wildcards. The character "?" represents a single character, and the character "*" represents a character string.
Remark: The table USR40 was not designed to contain thousands of single values for "illegal passwords" (negative dictionary). Instead, the system expects pattern values. Possible new passwords are compared with all the entries in the table USR40. Since this restriction was not entirely clear, and because many customers filled their table USR40 with thousands of single values, we have optimized the search within the table. For more information, see Note 618630.

Examples:

• 123*  prohibits all passwords that begin with "123", such as "123456" or "123123".

• P?SS  prohibits passwords like "PASS", "PBSS", and so on.

• *? ?* prohibits passwords that contain blank characters (between words).

3. How is the password stored?

              The password is stored in the database as a hash value (a reversal is not possible: the relevant plaintext password cannot be determined from the hash value). MD5 and (as of NetWeaver 7.0) SHA-1 with a deterministic "Salt" are used as the hash functions. As of NetWeaver 7.1, password hash procedures with a randomly generated "Salt" are also supported (see Note 991968).

4. How is the password transferred using the network?

              Currently, the data stream between the front end and the application server is only compressed. To encrypt data for the transfer, use our Secure Network Communications (SNC) and an external security product. Using SNC enables a user authentication that is not based on passwords. Therefore, it is not necessary to send any password data using the network.
              There is no option for us to encrypt the data stream between the application server and the database server. Contact your database provider for information about which options are available.

5. Can a user without an authorization profile execute functions in the SAP system?

              Users who do not have an authorization profile can execute only functions for which no authorization checks are carried out. However, there should be very few of these functions.
              If you discover deficiencies in this area, report them to the SAP Development department.
              (In the case of an emergency, you can use a modification to implement checks. In transaction SE93, maintain an authorization object and its values to check the affected transaction).