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:

After logon, the system shows the date and time of the last logon and any failed logon attempts since the previous successful 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.

Implementation of Password and Logon Protection with Security Policies and Profile Parameters

Profile parameter values and security policy attributes control the system behavior for password rules, password changes, and logon restrictions. Security policies replace the behavior definition with profile parameters. As soon as you assign a security policy to a user master record, it defines the desired behavior. Profile parameter values only remain relevant for any user master records to which no security policies have been assigned. A security policy is a collection of security policy attributes and their values. All available security policy attributes are contained, with default values, in every security policy. As an administrator, you can assign your own values that deviate from the default values. The advantage of security policies is that you can assign them on a user- and client-specific basis. However, there are profile parameters that continue to apply system-wide, and which are therefore not replaced by a security policy, such as parameter login/system_client.

Password Hash

The system does not store any plaintext passwords, but rather only password hash values. However, without the use of encryption technologies such as Secure Sockets Layer or Secure Network Communication, the system transfers the passwords in plaintext. The system stores logon data for external systems that is entered in destinations (with transaction SM59) in an encrypted format in the secure storage.

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.

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:

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.

For more information, see Password Rules.

As the administrator, you can ignore the following rules:

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 current 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).

The system also displays the number of failed logon attempts logon under  System Status for logon with SAP GUI. For logon with HTTP, you can configure a popup.

For more information, see Disabling the Display of Last Logon for HTTP Logons.

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.