Table USR02 and its Critical Role in SAP Security

Posted by Savitha Doddangadi at 10. February 2025
General

When it comes to SAP security, few tables are as crucial – and as sensitive – as USR02. Found in both SAP ERP and S/4HANA systems, this table is the backbone of user authentication, storing hashed passwords, managing login attempts, and tracking account statuses and password expiration dates. As a core component of SAP’s security architecture, USR02 plays a vital role in safeguarding user credentials and preventing unauthorized access. Therefore, ensuring the protection of this data is essential for maintaining system integrity and compliance. Let’s dive into why USR02 matters and how to keep it secure.

Content

What are the most critical fields in table USR02?

The table USR02 is a critical SAP system table that stores essential user logon information, including authentication details, password hashes, account statuses, and password expiration data.

The most important and critical fields in the USR02 table are:

1. BNAME (User Name)

  • Description: The unique identifier for a user in the SAP system. It is the user ID that is used during the login process.
  • Why it’s sensitive: Since BNAME represents the specific user, it ties directly to all the permissions, roles, and access levels assigned to that user in the system. Unauthorized access to this field can lead to identity spoofing or privilege escalation.
    Depending on the naming convention of the user provisioning you can link the username to real person, making this PII (Personally Identifiable Information)

2. CODVN (Password Hashing Mechanism Indicator)

  • Description: Historically, there have been different hash mechanisms for passwords used in SAP systems. The CODVN field controls which password hashing mechanism is used for storing passwords in the system. It helps determine the encryption or hashing algorithm used to securely store the user’s password.
  • Why it’s sensitive: The CODVN field is sensitive because it determines the strength and security of the password hashing mechanism in use. A weak or outdated hashing algorithm (such as MD5 or SHA-1) can make the stored password more vulnerable to attacks (like brute force or rainbow table attacks). If this field is compromised or exposed, attackers may gain insight into which algorithm is being used, which can potentially lead to the discovery of vulnerabilities in older or insecure hashing mechanisms.

3. BCODE, PASSCODE, PWDSALTEDHASH

  • Description: These fields contain the user’s password in a hashed format. The actual password is never stored in plain text for security reasons.
  • Why it’s sensitive: Although the password is stored as a hash, it is still highly sensitive. If the hash is exposed, attackers can attempt to crack it and gain access to user accounts. This field is a prime target for security breaches because it directly impacts user authentication.

Key Features of BCODE, PASSCODE and PWDSALTEDHASH:

Comparison BCODE, PASSCODE, PWDSALTEDHASH

*Definition Salt (cryptography): Value added to passwords before hashing to make each hash unique. Ensures that even if two users have the same password, their hashes will differ, making it harder for attackers to guess passwords using precomputed hashes.

Both, BCODE and PASSCODE rely on outdated hashing functions and salting mechanisms, making them extremely vulnerable to modern hacking methods. As a result, they are no longer considered secure and should not be used.

PWDSALTEDHASH uses the latest and most secure method of storing passwords in SAP. It is difficult (or even impossible) to reverse-engineer the password without knowledge of the salt and the exact hashing method used.

4. LOCKIND (Lock Indicator)

  • Description: Indicates whether the user’s account is locked or unlocked. If the user is locked, the user’s account cannot be used for logon. This typically happens due to exceeding login attempts or security policies.
  • Why it’s sensitive: This field is crucial for maintaining system security. Exposing or manipulating this field can lead to unauthorized access by unlocking accounts or bypassing security measures.

For a complete overview of all the fields listed in table USR02, please refer to the screenshot below:

USR02 fields with description

Common Use Cases for USR02 Table

SAP administrators and security specialists are responsible for managing user access in SAP systems. They perform actions to read or update the USR02 table, which contains crucial user login data such as passwords and account statuses, ensuring proper user authentication and system security.

  • User Account Management: Administrators can query USR02 to check the validity of user accounts, lock status, or password-related details.
  • Password Audits: Checking if there are no values (hashes) stored in the BCODE and PASSCODE columns, as they can be easily cracked.
  • User Lock and Unlock Management: Using the LOCKED field to determine if a user’s account is locked, and when it was last locked.
  • Access Control and Security Audits: The table helps administrators ensure that only authorized users have access, and it can be used to verify expired accounts or enforce access controls.
  • Inactive User Detection: Identify expired user (GLTGB, valid-to) or inactive users (TRDAT, last logon) that need to be deactivated or removed.

How to access table USR02?

There are several ways to access the USR02 table in SAP:

SE11 (ABAP Dictionary):

  1. Enter transaction SE11
  2. Type USR02 in the “Database table” field
  3. Click “Display”

SE16 (Data Browser):

  1. Enter transaction SE16
  2. Type USR02 in the “Table Name” field
  3. Execute (F8) to see the records

SE16N (Data Browser – New):

  1. Enter transaction SE16N
  2. Type USR02
  3. Press Enter to display data with filtering options

 S416N (Generic Browser Table):

  1. Enter transaction S416N
  2. Type USR02 in the “Table” field
  3. Execute (F8) to see the records

All these different transactions to access the data will automatically trigger an authorization check against two different authorization objects:

  1. S_TABU_DIS: Check whether the user is assigned to the table’s authorization group
  2. S_TABU_NAM: Check whether the user is assigned to the specific table

To determine which users gain access via the authorization object S_TABU_DIS, first check which authorization group table USR02 belongs to, as this can vary from system to system and can also be configured manually.

How to check which authorization group USR02 belongs to?

Authorization groups are used as part of SAP’s authorization concept to restrict access to specific objects or data within a system. They enable system administrators to manage user permissions by grouping certain objects or transactions together and controlling access to them based on the user’s role and the group they belong to.

To check which authorization group USR02 belongs to,

  1. Go to transaction SE11
  2. Enter the table name “USR02” and click display
  3. Use “Utilities” → “Assign Authorization Group” to view the authorization group

In this view you can see the authorization group (e.g., “SPWD”, “SU” or another group) associated with table USR02.

Note: Before restricting access to a specific authorization group, it is essential to verify which other tables are included in that group. This precautionary measure helps to prevent any unintended availability issues of other tables.

How to list all tables in a particular authorization group?

Once you know the authorization group assigned to a table, you can list all tables that belong to that authorization group by querying the relevant data in SAP:

  1. Go to transaction SE16
  2. Enter table name TDDAT and press F7
  3. In the CCLASS field, enter “XX” (your authorization group)
  4. Execute the query to see all tables assigned to the “XX” authorization group

How to list users with access to table USR02 (SUIM)?

To check which user gains access to table USR02 via authorization object S_TABU_NAM follow these steps:

  1. Enter transaction SUIM (User Information System)
  2. Expand “User” → “User by Complex Selection Criteria” and execute “By Authorization Values”
  3. In the field “Authorization Object” enter “S_TABU_NAM” and click “Input Values”
  4. Under “ACTVT” you can choose between the values 02 (Change) and 03 (Display) (or leave it empty)
  5. Under “TABLE” add the value “USR02” and execute (F8) to view all users to have access to table USR02 via authorization object S_TABU_NAM

To check which user gains access to table USR02 via authorization object S_TABU_DIS follow these steps:

  1. Enter transaction SUIM (User Information System)
  2. Expand “User” → “User by Complex Selection Criteria” and execute “By Authorization Values”
  3. In the field “Authorization Object” enter “S_TABU_DIS” and click “Input Values”
  4. Under “ACTVT” you can choose between the values 02 (Change), 03 (Display) and BD (Maintain obj. in non-OwnerSys.) (or leave it empty)
  5. Under “DICBERCLS” add the authorization group(s) of table USR02 as value and execute (F8) to view all users to have access to table USR02 via authorization object S_TABU_DIS

How to secure USR02?

The table USR02 contains sensitive user authentication data, including password hash values and other crucial details related to user login and password management. Given its critical role in user security, it is essential to implement stringent measures to protect the table from unauthorized read and write access.

1. Protection against accesses from outside (using SQL)

It is 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 custom ABAP programs

Your custom ABAP reports have the capability to access any tables directly. Therefore, it is crucial that you adopt a restrictive approach when assigning development authorizations in production systems (SAP 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.

To view all users with authorization to execute or debug ABAP reports, enter transaction SUIM and follow the steps described in the chapter above. The authorization objects to be checked are S_DEVELOP and S_DBG (as of ABAP Release 7.57).

Note: In the case that both authorization objects are assigned to a specific user, that user will receive the higher from the two authorizations.

3. Protection against accesses using table browser

Users can access the table USR02 using a table browser. In this case, the system will check against authorization objects S_TABU_DIS and/or S_TABU_NAM.

To restrict the access, check which users have these authorization objects assigned (SUIM) and then configure the responsible roles for these users accordingly.

You can also reassign the table USR02 to a different authorization group using transaction SE54 (Generate Table Maintenance Dialog).

4. Protection against exports of table contents using transports

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

5. Protection using Generic Table Browser (GTB).

In the Generic Table Browser (GTB) the standard transactions like SE16N are replaced by S416N, that allows a more detailed approach to control the authorizations for accessing table contents.

To safeguard the USR02 table in SAP and prevent sensitive fields like BCODE, PASSCODE, and PWDSALTEDHASH from being exposed via modern GTB, it is possible to configure data access so that access to critical columns is excluded from the display.

For more information about the configuration of GTB, please refer to the blog of our business partner, scdsoft.

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. By scanning your SAP system with our smarterSec Security Platform (SSP), we identify users with excessive access rights to critical tables like USR02 and verify that your systems use the highest cryptographic standards to secure your passwords.

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

USR02 table is essential for administrators and security professionals within SAP systems. It provides valuable insight into user account management and security practices by storing critical information such as authentication credentials, password hashes, and account status. While this data is critical to ensuring secure access to the system, it also represents a potential vulnerability if not carefully monitored and protected.

By understanding the structure and function of the USR02 table, organizations can improve their security posture and identify potential entry points for attackers. Therefore, proper management and auditing of USR02 is essential to maintaining a secure SAP environment.

SAP documents on USR02

Related Topics: smarterSec Security Platform // SAP Security Risk Assessments

Do you have any questions or comments?

Please contact us directly!

Contact Us