About security and passwords

Direkt zum Seiteninhalt

About security and passwords

Veröffentlicht von Shortcut IT in Sc4SAP · 24 September 2019
Tags: Passwords
There are many sources of information available about SAP's password security, therefore why add another one...?

"Shortcut for SAP systems" claims - among other possibilities - to work as a "locksmith" in case you need it, therefore I thought it is worth to spend some time in an article about this. There are some functions related to this topic in the application.
  • The "Unlock users" function can be used for the task of unlocking lots of users. In case you are already a user administrator it is only an alternative to the SU10 transaction, otherwise the function enables you to unlock users using another user (e.g. a system user).
  • The "Unlock user via DB update" is a little bit more special, it offers the possibility to unlock users in another client of the system. In case every user is locked out of the system by mistake (or all user administrators) this could be the rescue.
  • The "Set password" function closes some gaps in the SAP standard functions and makes it easier to assign passwords to lots of users.
With these functions we can unlock users in every client and assign passwords for the same client as in the used SAP connection. This leaves us with the gap of assigning passwords in every client. In other words: how to assign a password in a client to which we don't have access?

You might think that this is not possible. But... it is! As there is no access to the client we can not use any function modules or similar to assign a free chosen password. But we can try it the other way round: update the USR02 table with a hash value for a known password! Of course we need access to another client of the system.

This method needs a little explanation, but from technical and security point of view it is quite interesting!

There is a function are that can be used for this. Beside all other tables the "Update table data" function also enables us to update table USR02.

Some background info about the method how passwords are stored and verified at login:

The hash functions used by SAP for the passwords have a long history. Started with simple hash methods for quite short passwords (up to 8 ASCII characters, automatically converted in upper case letters) the hash methods in the recent releases are meanwhile quite secure, dealing with special characters and a maximum password length of 40 characters. There's some "salt" given, means that something randomly generated is appended to the password and that concatenated value is used to compute the hash value.
The method used by default in the system depends on the SAP kernel version and some profile parameters (login/password_charset and login/password_downwards_compatibility) and can be seen in the USR02 record in field CODVN. They were added and used by SAP evolutionarily. For compatibility reasons the SAP system supports the newer hash methods as well as the older and outdated ones.
The hash algorithm can vary from user to user. When a user logs in into the system, the hash algorithm stored in the field CODVN of the USR02 record belonging to the user ID determines which hash algorithm and which field containing the hash code is to be taken for verifying the password.

When using the "Update table data" function for setting passwords, we need some knowledge about the internals. That's why I would like to make a short excursion into the dry topic of password encryption.

Depending on the hash algorithm specified in field CODVN the hash value is stored in different fields of the USR02 table. 'A' to 'E' uses the BCODE field which is long enough to keep a hash value for a password with up to 8 characters. With 'F' a password length up to 40 characters is supported, the hash value is stored in the field PASSCODE. The complexity of the hash algorithm made a further step with CODVN 'H' which stores the hash value in the field PWDSALTEDHASH.

For our current purpose - assign a password to the emergency user in a client where we don't have access to - the hash algorithm behind CODVN 'H' is quite interesting. What? This is a quite modern hash algorithm, much newer than for example 'B'. So, with respect to the availability of this old hash method 'B' and its lower level of security, why should the modern 'H' algorithm with a higher security level looks more attractive to do some tricks?

There is one aspect that makes the
'H' algorithm useful for our purpose: there is no dependency to the user ID in the hash algorithm - different to the old and outdated 'B'. If we would copy the password information for the 'B' algorithm from user A to user B the password would not work for user B because of the different user ID considered for computing the hash value. Therefore, copying a password for CODVN 'B' or other hash algorithms considering the user ID from a user to another user ID would not work. It has to be the same user ID.
The 'H' algorithm uses a randomly generated "salt" for the hash value. You can see this when you assign a password to a user and have a look afterwards on the field PWDSALTEDHASH where the hash value is stored (I assume that in your system the 'H' algorithm is used as it seems to be the standard algorithm in SAP systems since releases with SAP_BASIS 731). Do it a 2nd time using the same password and the same user and you will see that the value has changed. A 3rd time... again another hash value. That is the effect of the "salt": the field contains a hashed value of the concatenation of the "salt" value and the password, and as the "salt" is randomly generated the value is another one every time. But, and this is the important point: the 'H' algorithm does not use the user ID additionally for encryption.

Therefore, for our purpose (it's still about assigning a password to an emergency user in a client where we don't have access to) this hash algorithm, even that it has a really high level of security, offers an advantage in comparison to the old 'B' algorithm. Because the field PWDSALTEDHASH contains salt + password and the algorithm does not use the user ID we can transfer the hash value to another user without losing its validity.

Seems to be too easy? Let's verify it...

I use my local SAP test system for it. In client 001 I created a user 'EMERGENCY', assigned a randomly generated password and forgot it. In another client I created a user 'TESTUSER' with initial password 'Shortcut!'.
SAP - password in SU01

Now let's copy the value of the field PWDSALTEDHASH of this user to the EMERGENCY user in client 001.
First get the value by using SE16 for table USR02:

SE16 selection screen table USR02

SE16 - USR02 data with hashed password

I copy the value into the clipboard and start the "Update table data" in Sc4SAP to insert the values for updating the USR02 record for the EMERGENCY user in client 001, using an SAP connection for client 000.

Update table data function

The update of CODVN with 'H' is not necessary when in the USR02 record the value is already set. It ensures that the right hash algorithm is used for the verification of the password.

After pressing "OK" of the confirmation dialog the update needs only a second.

Update table data function - result

Now comes the thrilling part. We try to log in with the EMERGENCY user in client 001 with password 'Shortcut!', and... it worked!

SAP - Login with newly assigned password

It works on the same system as well as on other systems!
There is a relation to profile parameter login/password_hash_algorithm which specifies some parameters for the hash algorithm. Default value for this profile parameter is 'encoding=RFC2307, algorithm=iSSHA-1, iterations=1024, saltsize=96'. The SAP documentation of this profile parameter says: "This profile parameter is evaluated when calculating new password hash values (but not, however, when checking password hash values at logon), to determine the hash procedure and the coding format."
Therefore it should work also on systems with another value for this profile parameter.

If you want to try it, this is the used value for PWDSALTEDHASH with CODVN = 'H' that works for password 'Shortcut!'.
'{x-issha, 1024}fMSNQye6C9qWpeEdfyPwCFUkTfcBG3Sae4dthuxjfPA='
Following the given example feel free to try it with other passwords and their hash values. In addition to the update of PWDSALTEDHASH you can of course take the opportunity to update some other fields related to the login, for example:

UFLAG = 0                /* lock flag (0: not locked)
LOCNT = 0                /* counter of invalid login attempts
PWDSTATE = 0             /* password can be changed
PWDINITIAL = 2           /* password is not initial
LTIME = sy-uzeit          /* no need to change password at 1st login
GLTGV = '00000000'              /* } reset validity range
GLTGB = '00000000'              /* }
PWDCHGDATE = '29991231'    /* } bypass 'deactivated' password (see profile parameter
PWDLGNDATE = '29991231'   /* }    login/password_max_idle_productive)

Es gibt noch keine Rezension.
Shortcut IT GmbH
Försterstr. 11A
31275 Lehrte

Zurück zum Seiteninhalt