Report ZCLEANUP_PASSWORD_HASH_VALUESX - Remove weak password hash values

[Frank_Buchholz]

Risk zone !

The password hash algorithm used by ABAP based systems had evolved over time. Older hash algorithms are seen as weak nowadays and you should get rid of any such weak password hashes.

References:

• Blog SAP password hashes security from Dmitry Gutsko, 2020


• Blog Securing SAP NetWeaver AS ABAP Systems against password attacks from Kai Bauer, 2018


• Cracking series SAP password hacking Part I: SAP BCODE hash hacking on Saptechnicalguru.com, 2018


• Blog Why you should really get rid of old password hashes *NOW* from Joris van de Vis, 2014


• Analysis report SAP password hash algorithms from Daniel Berlin, 2012

Safe zone !

You might know report CLEANUP_PASSWORD_HASH_VALUES described in note 1458262 which removes redundant password hash values from the user tables.

It's important to use this report in a system which has seen many upgrades. Even if you have adjusted the password policy in the meantime you might still have weak password hash values in the system. Such weak hash values in the fields BCODE and PASSCODE are critical because a modern password cracker shows the password of BCODE in the twinkling of an eye and does not need too much time for unveiling the password of PASSCODE either.

Here is a typical result of the report for an old system which was installed many years ago:

The report will happily remove all redundant password hash values (7.671 + 19.731 + 482 entries in this example) but will not touch any of the weak 7.00/7.01 and legacy hash values (47.508 entries).

You observe that there still exit tons of weak password hash values in some tables after you have run the report. Cracking this old data still would give strong clues for any attacker even if users might use modern hash values in the meantime.

There exist several reasons why the reports does not touch this data. Here are some samples:

• An old technical remote user which never got a new password is still in use
  Obviously it would be a very bad idea to remove the password hash value which would break any remote interface calling this user.


• An old locked or invalid user might get reactivated and wants to logon with the old password.


• Auditors might want so analyze very old change documents in detail.


• You want to prevent that a very old password from the history gets reused again.

These are valid points, but what if you want to get rid of weak password hash values anyway?

• You can set new passwords (and repeat it several times to clean the history, too)


• You can delete outdated users (which deletes the master data and the history)


• You can archive change documents


• You can remove data from the database fields

Danger zone !

Well, the last option is highly critical and doing it manually or using a badly written report is even more dangerous.

Therefore I like to present the custom report ZCLEANUP_PASSWORD_HASH_VALUESX which I've developed to clean some demo and sandbox systems. You find the source code of the report on  GitHub.

Here is the selection screen:

The report operates across all clients.

You can select data by users and by the code version of the password hash:

A  Code Version A (Obsolete)
B  BCODE Code Version B (MD5-Based, 8 Characters, Upper-Case, ASCII)
D  Code Version D (MD5-Based, 8 Characters, Upper-Case, UTF-8)
E  Code Version E (Corrected Code Version D)
F  Code Version F (SHA1, 40 Characters, Case-Sensitive, UTF-8)
G  Code Version G = Code Vers. F + Code Vers. B (2 Hash Values)
H  PWDSALTEDHASH Code Version H (Generic Hash Procedure)
I  Code Version I = Code Versions H + F + B (Three Hash Values)
X  Password Deactivated 

You can choose the database tables which you want to clean:

USR02 Logon data
USH02 Change documents
USRPWDHISTORY  Password history

If you choose the logon data, you have some more select options for the user group, the user type and the lock status of the user.

The radio-buttons offer three levels of risk:

1. Show and process redundant data only (safe)
   You will see only entries having redundant data and later on you only delete redundant hash values.


2. Show and process weak data of inactive users, too (critical!)
   In addition you will see data of locked or invalid users. You might decide for individual users to remove the password hash values. If you ever decide to reactivate such users later on you have to set a new password.


3. Show and process weak data of active users, too (danger!)
   In addition you will see data of active users. You might decide for individual users to remove the password hash values anyway. If these users want to logon using a password you have to set a new password.
   

For the other two tables, change documents and password history, you do not see similar radio-buttons. The report will offer to remove the data in any case.

In the lower box of the selection screen you see some of the profile parameters describing the password policy. Ensure that the profile parameter login/password_downwards_compatibility has value 0! For more details about this parameter see note 1237762.

Result:

Following fields are available:

• Table (USR02, USH02 or USRPWDHISTORY)


• Client


• User


• Date and time of last modification of the user


• User group


• User type A: Dialog, B: System, C:Communication, S: Service, and L: Reference (no logon possible)


• Lock (=0: unlocked, >0: locked)


• Valid from, to


• CUA template user (if set, than you cannot use this user for logon)


• Last logon date


• Last logon time


• User status ("inactive" if locked or not valid, "deleted" for uses which do not exist anymore)


• Password hash code version (see above)


• Indicator for BCODE - This is the broken legacy hash value


• Indicator for PASSCODE - This is the hash value used in 7.00 and 7.01


• Indicator for PWDSALTEDHASH - This is the modern hash value


• Comment (The color yellow, orange, red shows the potential risk level for removing the data)

If you see all three indicators you simply can remove redundant data.

If you see BCODE or PASSCODE but no PWDSALTEDHASH you are in trouble: You want to remove this data, but then the password of the user is gone. Check carefully how to proceed!

Now you can optimize the list, filter for specific entries, sort and save the layout for later use.

Finally you select some or all entries and hit "Remove":

The report will remove the data and update the list accordingly.

Hint

The Z-report reads and clears the fields BCODE and PASSCODE but does not touch field CODVN.

The original report uses field CODVN for selection but during selection does not bother with the content of fields BCODE and PASSCODE. The original report will still show high counts even after you have removed the weak hash values using the Z-report.