Blog - Shortcut IT

Direkt zum Seiteninhalt

About security and passwords

Shortcut IT
Veröffentlicht von 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 are 2 functions that can be used for this.
  1. Via "Insert / modify program" you can execute a program which copies the password of a user in a client to another user either in the same or another client. Have a look into the "ABAPs" folder coming with "Shortcut for SAP systems", the program is in file "CopyPassword.txt".
  2. Beside all other tables the "Update table data" function also enables us to update table USR02.

For the first function there is not so much to explain. Insert the program, execute it, enter user ID's, source and target client and that's it. Afterwards the password of the source user is valid also for the targeted user. Thus, in case you have to assign a new password to an emergency user (here: user EMERGENCY in client 100) and does not have the possibility to do this with the "Set password..." functions you can proceed like this:
1) assign a new initial password to your own user in the source client (let's assume client 000 for this example), or just take it as it is to assign "your" password also to the emergency user.
2) insert the program, then execute it to copy the password of your own user in client 000 to the emergency user in the target client:

3) test it via login using the emergency user and the target client. If you used an initial password in step 1 the system should ask for a new password (that implies that the verification of the given password is already done successfully), then cancel the login for keeping the initial password.
This method does not work with hash algorithms using the user ID (CODVN [A|B|C|D|E|F|G]) except both source and target user ID are identical. It's explained later in this article.

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.

Lets's take a look at the other possibility - using the "Update table data" function. We can use it to do nearly the same as with the program used in method #1, but we get more flexibility. In return, 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. That is why the above mentioned method by copying a password from a user to another user ID using the program in "CopyPassword.txt" would not work for CODVN 'B' or other hash algorithms considering the user ID. 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!'.

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:

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.

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.

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

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
GLTGV = '00000000'              /* } reset validity range
GLTGB = '00000000'              /* }
PWDCHGDATE = '29991231'    /* } bypass 'deactivated' password (see profile parameter
PWDLGNDATE = '29991231'   /* }    login/password_max_idle_productive)

Kein Kommentar
Shortcut IT GmbH
Kreuzberger Straße 8
31226 Peine
Tel.: 0170/9377125
Zurück zum Seiteninhalt