Securing SAP NetWeaver AS ABAP Systems against password attacks

Huge collections of leaked logon credentials (see Identity Leak Checker) make it necessary to harden SAP-Systems against password attacks.

There is a lot of information on this topic. This blogpost aims to give a summarized overview of the most important activities required to secure AS ABAP Systems.

At the end you will find a condensed checklist that you can use for documentation.

Summary

Hardening AS ABAP Systems against password attacks is split into three main topics:

Secure password hashes against password cracking (see SAP Note 1458262)
Check logon rules and password complexity requirements (see SAP Documentation AS ABAP)
Define patterns of “illegal passwords” in table “USR40” (see SAP Note 2467)

1.) Secure password hashes against password cracking

Password hash values are stored in the following database tables:

Table / View	Function	Release
USH02	Change history for logon data	In all Releases
USH02_ARC_TMP	Change history for logon data, last entries from archive information	From Release 6.20
USR02	Logon data table	In all Releases
USRPWDHISTORY	Password history table	From Release 7.00
VUSER001	View of general userdata	From Release 4.5B
VUSR02_PWD	View of password hashes	From Release 7.10

It is advisable to restrict read access to tables containing password hash values using Authorization Objects S_TABU_DIS and S_TABU_NAM:

https://launchpad.support.sap.com/#/notes/1484692 1484692 – Protect read access to password hash value tables
https://launchpad.support.sap.com/#/notes/1237762 1237762 – ABAP systems: Protection against password hash attacks

It is also important to use strong hash algorithms (at least SAP Release 7.02):

Release	Hash Algorithm	Based on	Classification
< SAP-Release 7.00	BCODE-Hash	MD5	Unsecure
SAP-Release 7.00	PASSCODE-Hash	SHA-1	Unsecure
Since SAP Release 7.02	PWDSALTEDHASH login/password_hash_algorithm	SHA-n (multiple SHA-Variants)	Secure

As mentioned in SAP Note 1458262, be careful:

After upgrading from Releases < 7.02 to PWDSALTEDHASH, old hash values still exist in the database. Additional hashing with PWDSALTEDHASH is only effective once users change their passwords. From then, both values (old & new, unsecure & secure) exist.

To complete the change to the PWDSALTEDHASH-Algorithm it is important to follow these steps:

Force users to change passwords (login/password_expiration_time).
Manually change passwords for usertypes “SERVICE” and “SYSTEM” (there is no password expiration).
Deactivate using “old” hash-values by setting profile parameter login/password_downwards_compatibility = 0
Remove “old” hash values from the database by using report CLEANUP_PASSWORD_HASH_VALUES

2.) Check logon rules and password complexity requirements

The behavior of the login procedure can be configured using the following profile parameters. For hardening, the values recommended by SAP can be used as a guideline (see SAP Documentation: Profile Parameters for Logon and Password (Login Parameters)):

Setting	Profile Parameter	Recommendation
Period after which a password has expired and needs to be changed.	login/password_expiration_time	90 days
Number of old passwords that can not be re-selected.	login/password_history_size	≥10
Number of characters that must differ for a new password (aggravation of permutation rules).	login/min_password_diff	3
Days to wait for a password Change (so history_size can not be bypassed).	login/password_change_waittime	1
Number of days that an initial password remains valid (initial passwords are often known to several people and should be changed in a timely manner).	login/password_max_idle_initial	≤7
The number of days that a password can be left unused before it becomes invalid.	login/password_max_idle_productive	180
Number of allowed login attempts before the SAP GUI session is aborted (brute force protection).	login/fails_to_session_end	3
Number of allowed login attempts before the account is locked (brute force protection).	login/fails_to_user_lock	5
Number of days until an account locked by unsuccessful attempts is automatically unlocked.	login/failed_user_auto_unlock	0

In the next step it is important to ensure choosing secure passwords. This can be done by increasing password complexity. The following profile parameters set password minimum requirements:

Setting	Profile Parameter	Recommendation
Minimum password length	login/min_password_lng	8
Number of lowercase letters	login/min_password_lowercase	1
Number of uppercase letters	login/min_password_uppercase	1
Number of digits	login/min_password_digits	1
Number of letters	login/min_password_letters	1
Number of special characters	login/min_password_specials	1

3.) Define patterns of “illegal passwords” in table “USR40”

SAP provides a password exception table (USR40) for unauthorized password combinations. When a user chooses a password, the system checks if it is included in the exception table and (in case of “Yes”) rejects it.

The following rules apply by default regardless of profile parameters and values in USR40 (see SAP Note 2467):

The password cannot be “PASS” or “SAP*”.
The first three characters cannot be identical.
“?” or “!” cannot be the first character of a password.

USR40 is very good at eliminating the issue of using leaked passwords and can protect systems against attacks with known dictionaries.

However, it should be noted:

“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.”

Therefore, only values that are not already excluded by profile parameters for password complexity should be used. It is recommended to use the following “wildcards” (placeholders for other characters) to exclude entire strings:

character “?” for a single character
character “*” for a character string

Examples (as shown in SAP Note 2467):

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).

Sample values for USR40

Possible values for the password exception table USR40 could be:

Most common passwords from leaks that are not excluded by profile parameters for password complexitiy.
Simple “Keyboard Walks” (e.g. QWER*, 1234* … ).
Company name, product names, customer names …

Final checklist for securing SAP NetWeaver AS ABAP Systems against password attacks

The following table is a final condensed checklist of all necessary steps to secure SAP NetWeaver AS ABAP Systems against password attacks.

All recommended values come from the SAP Notes and SAP Documentation listed above.

You may use it as guideline and for documentation.

Step

Recommendation

Comment

Secure Password Hashes
Restrict read access to tables containing password hash values:			Using authorization objects S_TABU_DIS and S_TABU_NAM.
Table USR02		☐
Table USH02		☐
Table USH02_ARC_TMP		☐
Table USRPWDHISTORY		☐
Table VUSER001		☐
Table VUSR02_PWD		☐
Use strong hash algorithms:
Use SAP-Releases ≥ 7.02		☐	From 7.02, the “PWDSALTED-HASH” algorithm, classified as safe, can be used.
Check profile parameter login/password_expiration_time	90	☐	A changed password is additionally hashed by the „PWDSALTEDHASH“-Algorithm.
Manually change passwords of SERVICE- and SYSTEM-Users that never expire		☐	A changed password is additionally hashed by the „PWDSALTEDHASH“-Algorithm.
Disable old hash algorithms by setting Profile parameter login/password_downwards_compatibility = 0	0	☐	Final deactivation of old hash algorithms. From then users without changed passwords (= without PWDSALTEDHASH) are no longer allowed to log on.
Cleanup and delete old, unused hashvalues by executing report CLEANUP_PASSWORD_HASH_VALUES		☐

Check Logon Rules
General password expiration:
Profile parameter login/password_expiration_time	90	☐	Period after which a password change becomes necessary.
Password history Settings:
Profile parameter login/password_history_size	≥10	☐	Number of old passwords that cannot be reused.
Profile parameter login/min_password_diff	3	☐	Number of characters that must differ for a new password (aggravation of Permutation rules).
Profile parameter login/password_change_waittime	1	☐	Days to wait for the next password Change (that history_size can not be bypassed).
Validity of unused passwords:
Profile parameter login/password_max_idle_initial	≤7	☐	Number of days that an initial password remains valid.
Profile parameter login/password_max_idle_productive	180	☐	Number of days that a productive password can be left idle before it becomes invalid.
Brute-Force Protection:
Profile parameter login/fails_to_session_end	3	☐	Number of permitted login attempts before the SAP GUI session is closed.
Profile parameter login/fails_to_user_lock	5	☐	Number of allowed login attempts before the account is locked.
Profile parameter login/failed_user_auto_unlock	0	☐	Number of days until an account that has been blocked by unsuccessful attempts is automatically unlocked.

Ensure Password Complexity
Profile Parameter login/min_password_lng	8	☐	Minimum password length
Profile Parameter login/min_password_lowercase	1	☐	Number of lowercase letters
Profile Parameter login/min_password_uppercase	1	☐	Number of uppercase letters
Profile parameter login/min_password_digits	1	☐	Number of digits
Profile parameter login/min_password_letters	1	☐	Number of letters
Profile parameter login/min_password_specials	1	☐	Number of special characters

Define Patterns of „Illegal Passwords“
Password exception table USR40:
Use values that are not excluded by profile parameters for password complexitiy (don’t create a dictionary!)		☐
Use wildcards ‘*’ and ‘?’		☐