Transaction SE16 is a universally applicable function to display any database contents in ABAP systems.
An authorization check against a table authorization group protects the access to this data using this function (authorization object S_TABU_DIS).
If you use transaction SE16 in a certain way, the system may fail to perform this authorization check. This may allow unauthorized access to any sensitive or critical data.
The correction (Support Package or correction instructions) solves this problem.
Risk mitigation before the correction is effective: Limit the access to transaction SE16 (authorization object S_TCODE).
We strongly recommend that customers limit the access to SE16 and implement the correction instruction as soon as possible.
Other terms Data Browser, SE16
Solution Use transaction SNOTE to implement the corrections.
Symptom Password-based logon attempts (to ABAP systems as of Release 7.00 / NetWeaver 2004s / SAP ERP 2005) fail, although the user has entered a supposedly correct password in a front end component or in a destination (of another system).
However, a (direct) SAPGUI logon with the same password is successful.
Other terms USR02, CODVN, BCODE, PASSCODE, hash password, logon password
Reason and Prerequisites As described in Note 862989, ABAP systems as of NetWeaver 2004s (7.00) support passwords of up to 40 characters, whereby they differentiate between uppercase and lowercase.
In earlier ABAP Releases (prior to 7.00), passwords could only be comprised of a maximum of 8 characters, whereby lowercase letters that were entered were automatically changed to uppercase letters.
If, in a newer ABAP system (as of Release 7.00), a downwardlyincomplatible password is unknowingly granted (see below), and if the front end or middleware components are not able to process such passwords correctly, logon problems inevitably occur. This is usually due to the (invisible) automatic conversion from lowercase to uppercase letters. The problem is due to the fact that the password entered by the user does not arrive at the server in the same form, but is changedeither during input or during the transmission (in which many components are involved).
A (plain text) password is downwardly compatible if it consists of a maximum of 8 characters and contains no lowercase letters.
A (plain text) password is downwardly incompatible if it consists of more than 8 characters or contains at least one lowercase letter.
Older ABAP systems support downwardly compatible passwords only. In newer ABAP systems (as of Release 7.00), downwardly incompatible as well as downwardly compatible passwords may be granted. Since lowercase letters that you enter are now no longer changed to uppercase letters, the passwords granted in newer ABAP systems are normally downwardly incompatible.
Hash password procedure / Code versions
ABAP systems do not save passwords in plain text, but instead calculate a hash value and save this together with the meta information using the hash password procedure ("code version"). This information is stored in the user master record and it is analyzed during the password check: A hash value is determined, using the code version specification (from the user master record), from the plain text password to be checked and it is compared with the reference hash value (from the user master record).
The quantity of the hash password procedure supported is release-dependent, whereby newer releases always support all procedures of preceding releases. This ensures that a password logon is also possible after a release upgrade.
Only the hash password procedures available as of Release 7.00 also support the processing of downwardly incompatible passwords. Older hash password procedures support downwardly compatible passwords only.
Whether downwardly incompatible passwords are supported or expected during a password logon depends primarily on the specifications (code version) saved in the user maser record.
Solution
When using the technical user (in RFC destinations):
We strongly recommend that you use the SYSTEM user type on the server (or also SERVICE, provided a SAPGUI capability is required), since the password has unlimited validity only for these user types (see Note 622464).
If the password should be entered in an RFC destination of an older system (= RFC client), it must be granted as a downwardly compatible password on the server. For users of the SYSTEM or SERVICE type, this is always possible, even if the password rules of the system normally compel the use of downwardly incompatible passwords (for example, by login/min_password_lng > 8 or login/min_password_lowercase > 0).
When using older front end or middleware components and password logon of "normal" user (DIALOG type):
In this case, it is not practical to change the passwords of the (numerous) users affected ( as in the above case with technical users). Instead you must replace the obsolete front end or middleware components.
Note 792850 describes as of which version level certain front end or middleware components support the interaction with downwardly incompatible passwords. In addition, you may need to update other software components (attached to these components), as well as those of external providers. This is particularly the case if these components lead their own password input dialog and are not able to support downwardly incompatible passwords (according to the above definition of the term). For the moment, you can set the profile parameter login/password_downwards_compatibility on the server to the value 2 or 3 for test purposes. In this case, the server checks if the client has sent a matching downwardly compatible password for the expected downwardly incompatible password (that is, a password that is 8 characters long and converted to uppercase). If this is the case, it is logged in the sys log (for error analysis purposes), and the logon is assessed as successful (for value 3). Using transaction RZ11, you can change the profile parameter dynamically, that is, without restarting the system.
Symptom With SAP NetWeaver 7.1 (SAP_BASIS 7.10) or SAP NetWeaver 7.0 Enhancement Pack 2 (SAP_BASIS 7.02), the list of supported hash value password processes was extended: In addition to the processes of previous releases, the NetWeaver Application Server ABAP (NWAS ABAP) now also supports hash value password processes for which a randomly generated value ("random salt") is used to calculate the hash value.
Other terms SSHA1, salted SHA-1, RFC-2307, RFC-3112, USR02-PWDSALTEDHASH
Reason and Prerequisites All the data required for calculating the hash value password process (the used hash algorithm and the salt value determined for the assignment of the password) are saved in a defined coding process in a text string.
During the password check, this text string is split into the parts mentioned above and a hash value is calculated using the plain text password. This hash value is checked for similarity with the reference hash value saved in the user master record.
By using (generic, self-descriptive) text strings you can support further hash value password processes in the future. All you need to do this is a new kernel version. You no longer have to adjust data structures to store password information.
Solution This note provides an overview over which kernel versions support which hash value password processes or which coding processes. Furthermore, the note also provides information about what data is required for the login/password_hash_algorithm profile parameter or which data is analyzed in this parameter.
This note is updated regularly.
At the moment, only one hash value password process is supported:
iterated salted SHA-1
Available as of: Kernel 7.10
(SAP NetWeaver 7.0 Enhancement Pack 2 uses kernel 7.20)
The default values for the login/password_hash_algorithm profile parameter as as follows:
encoding=RFC2307, algorithm=iSSHA-1, iterations=1024, saltsize=96
Value range for "iterations": 1 - 4294967294 (2 ^ 32)
Value range for "saltsize": 32 - 128
Symptom Previous password hash procedures (code versions B and D) may cause the following error scenarios:
Users whose passwords contain certain special characters (for details: see below), may also log on to the system using changed passwords: it seems that the system treats all special characters equally.
(For more information: see Note 735356)
When calculating the password hash values the system under certain circumstances does not take into account all characters of the password (the password is actually truncated). This applies to both the old password hash procedure (code version B) and the new password hash procedure (code version D) that was implemented with Note 735356; with the usage of non-ASCII characters or Unicode characters this problem occurs more often.
Other terms USR02-CODVN, UTF8, hash collisions
Reason and Prerequisites The reason is an incorrect implementation in the kernel (password code versions B and D).
Solution Use a new kernel and a Support Package/a correction instruction:
Systems with SAP_BASIS 4.6x:
Kernel 4.6 as of patch number 2121.
In addition, read Note 318846 (usage of a downward-compatible kernel).In addition you should implement the ABAP corrections from Note 735356.
Systems with SAP_BASIS 6.x:
Kernel 6.40 as of patch number 90.
In addition read Note 664679 (usage of a downward-compatible kernel).In addition you should implement the ABAP corrections from Note 735356.
Systems with SAP_BASIS 7.0:
Kernel 7.0 as of patch number 23.In addition you should implement the ABAP corrections from this note.
For Systems with Basis Release 3.x, 4.0 or 4.5 no solution is available (since UTF8 is not supported prior to kernel Release 4.6).
For systems as of Basis Release 7.0 the password code versions B, D and E are actually only of interest because of the downward compatibility. As of Release 7.0 new (downward compatible) password code versions (F and G) are supported, which allow the usage of longer passwords (of up to 40 characters), where an additional distinction will be made between uppercase and lowercase letters.
For more information , see Note 862989.
Remark when using the Central User Administration (CUA) As already described in Note 735356, the implementation of a new password hash procedure (here: code version E) is a change that may cause problems when using a Central User Administration (CUA). It must be ensured that all participating systems of a Central User Administration support the new password encoding procedure (through the usage of the combined ABAP correction and kernel correction). You may only activate the new procedure by setting profile parameter login/password_charset to value 2 (see Note 735356) if this is true.
General restrictions when using the password hash procedure in non-Unicode systems Some (European) characters exist both as lowercase and as uppercase letters. However, in some code pages in non-Unicode systems only the lowercase letters of some characters exist (for example, Latin-1: characters µ (0xB5) and ÿ (0xFF)); the related uppercase letter character does not exist in the code page. When converting the password to uppercase letters, these characters are not converted (in non-Unicode systems); in Unicode systems, however, the characters are converted. As a result, it can happen that users who have passwords that contain such characters cannot log on to the system with their passwords after an upgrade from a non-Unicode system to a Unicode system.
