Safeguarding sensitive data isn’t just a best practice – it’s a necessity. One essential SAP component in this process is the table USR02, which stores key login details, including password hashes, making it a critical target for attackers. Understanding how SAP protects passwords can help prevent breaches and unauthorized access.
Table of Content
- What is Password Hashing?
- What are the key differences between Password Hashing, Encryption and Encoding?
- Why is Password Hashing Necessary?
- How does password hashing work in SAP?
- How is sensitive data stored in table USR02?
- How to configure the URS02 hash algorithm?
- Further measures to enhance password security
- How can smarterSec provide support?
- Conclusion
What is Password Hashing?
In the world of cybersecurity, safeguarding user passwords is one of the most important aspects of maintaining privacy and data security. It is a process that converts a plaintext password into a fixed-length string of characters, called a hash, using a hashing algorithm. This ensures that even if someone gains unauthorized access to the hashed password, they are impossible to revert to the original password. This guarantees the confidentiality of user data even in the event of a security breach.
Common password hashing algorithms include bcrypt, Argon2, and the SHA-2 family (e.g. SHA-256). These algorithms are designed to handle input of any size while producing a hash value of consistent length. It is designed to be computationally demanding to crack a hash, making it resistant to various types of attacks.
The system uses a hash algorithm to convert the plaintext password into a hash when a user creates an account and sets a password. Instead of the actual password, this hash is then stored in the database. During login, the system hashes the password entered by the user and compares it to the stored hash. If they match, the user is granted access.
What are the key differences between Password Hashing, Encryption and Encoding?
Securing sensitive information, particularly passwords, requires a clear understanding of the differences between hashing, encryption and encoding. Despite their similarities, these three methods are fundamentally different in how they work and in their use cases. Developers, system administrators, and security professionals must grasp these differences to effectively protect data.
Why is Password Hashing Necessary?
Password hashing is crucial for the following reasons:
1. Reducing the Impact of Data Leaks:
In the event of a leak, attackers will only see hashed versions of the passwords and not the plaintext password, preventing them from directly exploiting stolen credentials.
2. Prevention of Password Cracking
Hashing algorithms are designed to be a one-way function. This means it is easy to calculate the hashed password, but impossible to reverse engineer the hash to the plaintext password.
3. Comply with GDPR regulations
Companies are obligated to encrypt or hash the passwords when storing them (see article 49 and 83 in the GDPR Regulations).
How does password hashing work in SAP?
The process of creating and storing a hash, as well as the SAP Login process, follows these steps:
1. User sets a password:
When a user creates an account or updates their existing password, they begin by entering a plaintext password. This initial password serves as the starting point for the hashing process, where it will be securely transformed into a unique, irreversible hash.
2. Salting the password:
Prior to hashing the password, a salt (a random string of characters) is generated and added to the password. Salting is a security measure that ensures that even if two users have the same password, their hashed passwords will be different.
Example:
- Plaintext Password: mypassword123
- Generated Salt: X9f#3s5hT (a randomly generated string)
- Salted Password: mypassword123X9f#3s5hT
3. Hashing the password
Once the salt is added, the combined password and salt are passed through a hashing algorithm (e.g. bcrypt, Argon2, SHA-256).
This hashing process can be iterated to further increase the complexity and thus the computational effort of a successful brute-force attack.
Example:
- Hash-Algorithm: SHA-256
- Salted Password: mypassword123X9f#3s5hT
- Calculated Hash: 4b42b54b36c2a58f63b3c9930a8b497684059784c438850f4dc59e7cb138b004
4. Storing the hash and salt
The SAP system stores the username, hash and the salt in the USR02 table. The actual password is not stored.
5. User Login
When a user logs into the SAP system, they enter their password. The system retrieves the stored salt and combines it with the entered password to calculate the hash value.
The generated hash is then compared with the hash value which is stored in table USR02. If they match, the user is authenticated and can enter the SAP system. If the values don’t match, the login attempt is denied.
This process ensures that even though the system doesn’t store the original password, it can still verify the user’s identity .
How is sensitive data stored in table USR02?
Over various SAP releases, the password hashing has evolved. In earlier versions, hashed passwords were stored in the BCODE and PASSCODE fields, while in more recent releases, they are stored in the PWDSALTEDHASH field.
The CODVN (Code Version of Password Hash Algorithm) field in the USR02 table specifies the active hash algorithm for a given entry. Below are the possible values and their associated hash methods:
Below you can see a screenshot from table USR02. In this case code version (CODVN) “H” is used, this means the generated hash value is stored in column “Password Hash Value” (PWDSALTEDHASH).
Column PWDSALTEDHASH contains:
- The hash value
- The used hashing algorithm (e.g. isSHA-512)
- The number of iteration (e.g. 15.000)
- The salt
How to configure the URS02 hash algorithm?
There are two parameters that must be observed and configured:
- login/password_downwards_compatibility
- login/password_hash_algorithm
The profile parameter login/password_downwards_compatibility is responsible for generating, storing, and validating password hashes during user login (specifies the CODVN value).
Meanwhile, the profile parameter login/password_hash_algorithm determines the format and hash algorithm to be used for new passwords stored in column PWDSALTEDHASH.
login/password_downwards_compatibility
SAP introduced support for longer, case-sensitive passwords (up to 40 characters) starting with SAP NetWeaver 7.0. These changes are not downward-compatible, meaning that the newer password hashes are not understood by older systems. If you’re using a central system that needs to interact with older systems, you need to configure this parameter to handle downward compatibility appropriately.
This parameter controls whether the system should:
- Generate only the latest password hashes (not compatible with older systems),
- Generate both new and downward-compatible password hashes for compatibility with older systems.
The value of this profile parameter specify the desired behavior (default = 1):
- 0 (recommended): The system only generates new password hashes (no downward compatibility).
- 1 : The system also generates downward-compatible hashes, but does not evaluate them for logons (to the local system) with passwords. This setting is necessary if the SAP system is used as the central system for user administration, and the connected systems support only older password hashes.
- 2: The system also generates downward-compatible hashes, and evaluates them when a logon with a nondownward-compatible password fails to check whether the logon would have been accepted with the downward-compatible password (truncated after 8 characters and converted to uppercase). This is logged in the system log and the logon still fails. (This setting is used to detect downward incompatibility problems.)
- 3 : Same as 2, but the logon is considered successful (avoids downward-compatibility problems).
- 4 : Same as 3, but no system log entry is written.
- 5 : Only old hash values are created.
login/password_hash_algorithm
The profile parameter login/password_hash_algorithm determines the format and hash algorithm to be used for new passwords. The generated hash is then stored in table USR02 in column PWDSALTEDHASH.
The default values for this parameter are as follows:
- Encoding = RFC2307
- Algorithm = iSSHA-1
- Iterations = 1024
- Saltsize = 96
As the following example shows, the default values of the parameter do not meet the current security standard and are considered outdated. Therefore, it is necessary to change the values manually to match the recommendations.
Current recommendation for the parameter login/password_hash_algorithm:
- Encoding = RFC2307
- Algorithm = iSSHA-512
- Iterations = 15000
- Saltsize = 256
Configuration of the profile parameters in transaction RZ10/RZ11
To permanently apply your changes follow these steps:
- Call transaction RZ10 (Edit Profiles)
- Select the profile for which the change shall be made
- Under “Edit Profile” select “Extended maintenance” and click “Change”
- Check if the parameters login/password_downwards_compatibility and login/password_hash_algorithm are already listed
- If so, then change the values to our recommendations
- login/password_downwards_compatibility: 0 or 1 (for central systems)
- login/password_hash_algorithm: encoding=RFC2307, algorithm=iSSHA-512, iterations=15000, saltsize=256
- If not, press “F5” to create a new parameter with said values
- To save your changes, go back until you get to the report “Edit Profiles”, then click “Save”
Further measures to enhance password security
In addition to configuring the profile parameters login/password_downwards_compatibility and login/password_hash_algorithm, there are other measures that should be considered to further enhance password security:
How can smarterSec provide support?
As a specialized SAP security and compliance company, smarterSec plays a pivotal role in safeguarding sensitive data stored in the USR02 table. To protect these sensitive user authentication credentials, our smarterSec Security Platform (SSP) performs vital checks to ensure that access to critical tables, such as USR02, is restricted and that the system’s password parameters remain compliant and up to date.
Additionally we offer SAP Security Risk Assessments which is a quick and easy way to efficiently analyze the current security and compliance level of one of your SAP systems and have it assessed by our experienced SAP Security & Compliance experts.
Conclusion
Password hashing is a vital component of user credential security. By using secure hashing algorithms, adding salts, and implementing best practices, you can guarantee that even in the event of a compromised password database, user passwords remain secure and protected. Modern hashing algorithms, such as bcrypt, Argon2 and iSSHA-512, are designed to withstand the challenges posed by ever-increasing computing power, making them ideal choices for safeguarding user data.
To ensure optimal security, it is crucial to configure the relevant profile parameters of your SAP system. Automated tools, such as the smarterSec Security Platform (SSP), provide a valuable insight into potential vulnerabilities and allow for seamless adjustment to current security standards.
For additional information regarding SAP security and password security, check out our webinar below:
Reference links
- ABAP systems: Protection against password hash attacks (SAP Note 1237762)
- Protect read access to password hash value tables (SAP Note 1484692)
- List of values for “login/password_hash_algorithm” (SAP Note 991968)
- ABAP: recommended settings for password hash algorithms (SAP Note 1458262)
- SAP Documentation: Password Hash
- SAP Documentation: Logon and Password Security in the ABAP-System
- SAP Help Portal: Defining the Default Hashing and Encryption Algorithms
- PDF: GDPR Regulations