Show TOC

Background documentationLogon and Password Security in the ABAP-System Locate this document in the navigation structure

 

Logon with User ID and Password

With this logon method, also known as standard authentication, the user enters his or her user ID and password to log on to the system. The system then checks the following:

  • Does the user have a password?

  • Is the user permitted to log on with password logon?

  • Has the administrator locked the user?

  • Has the system locked the user due to too many failed logon attempts?

  • Is the user's logon data - the password, the user name and the client - correct?

  • Does the user need to define a new password, because his or her password is initial, has expired, or has been reset by the administrator?

After logon, the system shows the date and time of the last logon under   System   Status  . In this way, the user can ensure that no other user has logged on using his or her name. In the standard production system, you cannot change the logon date and time. The system does not record the date and time of the logoff.

Password Hash

To increase the security of passwords, the system encrypts the plain text passwords and stores them only as hash values. The system also uses these hash values when transferring passwords.

To increase the security of the password hash values, as of SAP NetWeaver 6.40, the system uses the password hash algorithm SHA1 instead of the MD5 algorithm. This means that the system can generate hash values that are more secure, but which are not backward-compatible, and which make reverse engineering attacks more difficult. To nevertheless be able to use backward compatible passwords, the system now generates two hash values by default: a backward compatible hash value and a new one. You can use profile parameter login/password_downwards_compatibility to set the degree of backward compatibility, depending on your security requirements. You can set, for example, that the system only generates the new, non-backward-compatible hash value. This affects the following elements.

  • Communication frameworks (RFC, ICF) that transfer or store the passwords

  • Central User Administration, which distributes the password hash values

    If you use non-backward-compatible passwords, older systems can no longer call newer systems. This also means, as a matter of principle, that older and newer systems cannot use the same Central User Administration (more information: SAP Note 792850).

However, in principle the new hash functions do not initially have an impact after an upgrade. The operation of the system and the password queries continue to run as previously. The passwords of the new type gradually replace the passwords of the old type.

The system can determine at any time whether the current user password is of the new hash type or the old hash type. This information is stored in the user master record. During logon, the system calculates the password hash from the entered data and takes into account the information from the user master record. The system uses the details in the user master record to determine which part of the entered password it evaluates:

  • With passwords encrypted using the old password hash algorithm, the system evaluates only the first 8 characters, and converts these to upper-case.

  • With passwords encrypted using the new password hash algorithm, the system evaluates up to 40 characters, as the user entered them, that is, without converting them to upper-case.

To further increase the security of your system landscape, as of SAP NetWeaver 7.0 EhP 2, the system supports a new procedure for storing passwords. At least three values are now incorporated in the representation of the password hash information: the password hash value, the algorithm, and a random value (salt). This means that the storage is independent of the hash algorithm used and will also support completely new algorithms in the future. In addition to the existing hash algorithms, which work with a deterministic salt, the current release also provides new hash algorithms for user passwords, which use a randomly generated salt when calculating the password hash value. The hash value calculation can be performed a number of times, successively (that is, iterated), to make dictionary and brute force attacks more difficult. You can administer this password function using the profile parameter login/password_hash_algorithm.

Initial Password

When you create a user master record, you must assign a password to the user. The password must meet the internal requirements set by the System and your regulations (more information: Password Rules). As the administrator you do not need to observe the following rules:

  • List of invalid passwords or password templates in table USR40

  • Password history; that is, the password can also be one of the last five passwords used by the user

  • Minimum number of different characters between the old and the new password

At the first logon, the system prompts the user to change this initial password. The new password specified by the user is the productive password.

Password Checks

If a user enters incorrect or invalid data when logging on with a password, the system increases the incorrect logon counter for that user in his or her user master record. When the user changes his or her password, the system also checks the currect password, and increases the incorrect logon counter if appropriate. You can define the upper limit for incorrect logon attempts in profile parameter login/fails_to_user_lock. If a user exceeds this upper limit, the system locks him or her and records this event in the Security Audit Log and in the system log.

If a user is locked, the system immediately terminates subsequent password checks without providing information about whether or not the password is correct. You can use the profile parameter login/failed_user_auto_unlock to determine when the system lifts the lock. By default, this is the case at midnight. As soon as the user logs on correctly, the system resets the incorrect logon counter and logs this in the Security Audit Log. The incorrect logon counter only applies for password logon. However, the system also takes active logon locks, that is, those set by the administrator, into account for logons using Single Sign-On (SSO).

If you use SAP GUI logon without a password, the system checks whether the user needs to change his or her password when SSO logon variants are used (such as Secure Network Communication, X.509 certificates, Pluggable Authentication Service, logon tickets). You can use profile parameter login/password_change_for_SSO to determine which of the different possible dialog boxes are displayed in this case.

More Information