SAP Note 1237762 - ABAP systems: Protection against password hash attacks

Note 1237762 - ABAP systems: Protection against password hash attacks

Symptom
You want to protect an ABAP system against password hash attacks.
In an attack of this type, the hash value of a password is calculated outside the SAP kernel and then compared to the hash value that is stored in the database of the SAP system.

Unlike other attacks, password hash attacks cannot be prevented by limiting the permitted number of failed password logon attempts (profile parameter login/fails_to_user_lock).


Other terms
USR02, SHA-1, MD5, hash, brute force, dictionary attack, rainbow table, TMTO, time-memory trade-off


Reason and Prerequisites
A password hash attack can occur under the following circumstances:

1. (Read) access to ABAP password hash values

2. Implementation of an identical password hash algorithm

Solution
The focus of the protection measures should be on point 1 (protection of password hash values against read access) because algorithms can generally not be protected against disclosure.

The (currently valid) password hash values are stored in the table USR02 in ABAP systems. At this point, the system also provides information about the password hash procedure used for the calculation of these values (also see   Notes 1023437 and 991968).

This means that you have to protect this table against read accesses:

1. Protection against accesses from outside (using SQL)

              We generally recommend that you prevent direct accesses to the database tables (for example, by using firewalls). Otherwise, the ABAP system cannot control accesses efficiently.

2. Protection against accesses using own ABAP programs

              You can use your own ABAP programs to access any tables directly. We therefore strongly recommend that adopt a restrictive approach when assigning development authorizations in production systems (see Note 13202).
              In this context, debugging authorization (including the authorization to change variable contents or influence the program flow) is regarded as the same as having the authorization to create and execute your own ABAP source code.

3. Protection against accesses using existing generic tools

              You can access the table USR02 using the table browser (transaction SE16 or SE17 or by navigating from transaction SE11). In this case, the system only performs a check for the table authorization group (authorization object S_TABU_DIS, see Note 26909).
              See Note 1133739 for more information.
              The table USR02 is assigned to the table authorization group 'SC'. (You can use transaction SE54 to manage this authorization.)

4. Protection against exports of table contents using transports

              Due to corrections and transports, table contents can be exported using transport requests. Therefore, you should adopt a restrictive approach when assigning authorizations for managing transport requests (authorization object S_TRANSPRT, activity 01, and so on).



General remarks:

• The security level for test systems and development systems differs from the security level for production systems. You should use different passwords in production systems than those used in test systems or development systems. If possible, you should log on to the production system using SSO (Single-Sign-On); when you do this, you can also use hardware-based procedures (smart card) or biometric procedures. These procedures provide a higher security level than password-based authentication.

• If it is not mandatory to create downward-compatible password hash values, you should prevent this by setting the profile parameter login/password_downwards_compatibility to 0 (see Note 811414 - for ABAP systems based on SAP NetWeaver 7.0).
  In older systems (lower than SAP_BASIS 7.00), you should ensure that code version E (see Note 874738) can be used by setting the profile parameter login/password_charset to 2. If you use a Central User Administration (CUA), all of the CUA systems have to support this new code version. This can be ensured by using a new kernel.

• By using restrictive password rules (see Note 2467), you can reduce the risk of dictionary attacks.  As of SAP NetWeaver 7.0, ABAP systems support the use of long passwords and can differentiate between lowercase and uppercase (see Note 862989); you can ensure the use of lowercase characters by setting the profile parameter login/min_password_lowercase to a value higher than zero.

• It may also be useful to protect the access to the passord history (table USRPWDHISTORY) or to the change documents (table USH02); otherwise, an attacker may be able to use former passwords to make conclusions about the current password.

• Usually, the users SAP* and DDIC have extensive authorizations. Since this is openly known, theses users are often the target of password attacks. The user DDIC is required in exceptional situations only (upgrades, and so on). In the productive use of an ABAP system, we therefore recommend that you delete the password of the user DDIC and reassign it shortly before it is required. You should create and then lock the user SAP* (see Note 2383).