CUA Log - Password hash is rejected; password is deactivated. Securing ABAP systems via iterated salted hash iSSHA-1.

[former_member681190]

Hi All,

In this blog I will illustrate an example on while using a CUA system in our landscape along with certain connected child systems, while changing a password for a user, how I came across & sorted the following error log “Password hash is rejected; password is deactivated” and later secured the landscape via SAP newest hash procedure iSSHA-1.

Now the error “Password hash is rejected; password is deactivated” can be due to a number of situations depending on the SAP kernel release version and parameter login/password_donwards_compatibility (The parameter will be discussed later).  

We will look for a common scenario in which the CUA central system is at a lower release 7.00 or 7.01 whereas the child systems are at a higher release >=7.02.

First we will see a short introduction to hash algorithm.

BASICS

SAP uses a number of (depending upon kernel release) cryptographic algorithms to manage passwords. What these algorithms do is, during user creation new/reset of plain text passwords are converted to a unique signature for that particular text called hash.

Note that a hash itself isn’t an encryption. It is a unique strings of characters (consisting of special characters/ numbers/ alphabets) for a particular text generated via cryptographic function. A unique hash value cannot be converted back to the original text.

In SAP this hash value is stored in table USR02 and classified according to their code version. Code version define how the password hash was calculated.

Whenever a user performs password based authentication the entered hash value is compared with the stored hash value and based on match access is granted/rejected.

As per below table, Code version can range from A-I & X.

Now code versions A-E classify the MD5 (Message Digest algorithm 5) hashing algorithm. The hash value generated are stored in table column BCODE.

MD5 algorithm was supported until SAP kernel version <7.00.

Since MD5 hashes are susceptible to brute force/dictionary attacks, for SAP kernel version 7.00 & 7.01 SHA1 algorithm is used.

Table column PASSCODE stores SHA1 Hash values.

Currently as of SAP NW 7.0 EhP 2, the system supports iSSHA-1. This is the most secure hashing algorithm. (Do note that newer release always supports all hash procedures of preceding releases.)

The generated hash values are stored in table column PWDSALTEDHASH.

Kernel Version Vs Hash procedure

 

Here we can summarize the kernel version and supported hashing algorithm as per below:

Kernel version <7.00 supports MD5 algorithm (outdated)

Kernel version 7.00 & 7.01 supports SHA-1 algorithm. [Backward compatible with MD5] (outdated)

Kernel version >= 7.02 support iSHHA-1 algorithm. [Backward compatible with MD5 + SHA1] (Latest)

The SAP Basis release version and parameter login/password_donwards_compatibility plays a crucial role in managing the passwords.

The profile parameter login/password_donwards_compatibility basically governs password hash creation and validation. It has a value range of 0-5.

0 & 5 has the most impact on creating the most secure and most insecure hash value respectively.

 

For Central system SAP release 7.00 & 7.01

CASE A: Central system has login/password_donwards_compatibility =0

This is the most secure setting for an SAP system. However, in case of CUA configuration this setting must only be used in central system if all connected child systems are having similar kernel release or higher. The child systems with lower kernel release cannot interpret the format and hash is rejected.

E.G. – If a central system is having kernel release 7.00 it will use the latest SHA-1 hash algorithm with table column PASSCODE to store hash value. If any connected child system is having kernel release less than 7.00 the password hash will be rejected and password gets deactivated.

CASE B: Child system has login/password_donwards_compatibility =0

if a child system is having release 7.00/7.01 it will use SHA-1 hash algorithm. However, if a child system is having release >=7.02 the parameter value 0 would require child system to use only the latest supported algorithm which is iSSHA-1 (PWDSALTEDHASH) for release >=7.02.

For release >=7.02 you can check the default value for hash procedure set by kernel using parameter login/password_hash_algorithm. You do not need to change this value.

In this case the hash value from central system will be rejected and password will get deactivated i.e. Code Version sets to X.

CASE C: Child system has login/password_donwards_compatibility =1

To avoid CASE B hash rejection, login/password_donwards_compatibility =1 can be set in the child system. With this the child system transfers all of the hash values from an inbound IDOC and stores them locally.

E.G :

For a password reset of a user below is an outbound IDOC generated from central system with basis release 7.01.

As the child system is at higher release >= 7.02 the parameter value login/password_donwards_compatibility =1 allows it to store the transferred hash value & code version “F” locally.

Using the initial password, once the password is made productive in child system, all supported hash values (BCODE; PASSCODE & PWDSALTEDHASH) are then calculated and stored.



 

However, the older hash values are not evaluated during password logon (in child system), only the newest hash value is evaluated i.e. PWDSALTEDHASH & Code version is set to I.

Had the parameter value been set to 0, the child system (based upon its release 7.31) would have expected PWDSALTEDHASH from the central system and have rejected older hash value PASSCODE with the below error.

Although setting login/password_donwards_compatibility =1 option works but prevents the child system from using the most secure setting i.e. having login/password_donwards_compatibility =0.

To avoid this potential security risk, the central system kernel release must be updated to >=7.02.

Once all the central and child systems are at same release>= 7.02 we can set the parameter value login/password_donwards_compatibility =0 and clear the old hash values by executing report CLEANUP_PASSWORD_HASH_VALUES. The entire landscape will then be using iSSHA-1 algorithm with Code Version H.

Note:

The parameter login/password_hash_algorithm becomes useless if value 5 is set for parameter login/password_donwards_compatibility. Since the system then generates only the maximum downward compatible hash value i.e. BCODE.

Hence, for security reasons the value 5 is not used.

 

Hope you found the information useful.

Thank You !!