SAP stores password hashes in three fields of the user master table, BCODE, PASSCODE and PWDSALTEDHASH, and the CODVN field on each row names which generation that account's password was last written under and therefore which field a logon is checked against.
Password strength testing in the RedRays Security Platform dispatches on that one character, because the three constructions have different properties and a hit against each proves a different amount. This page is the table a reader needs before interpreting any password finding.
It is the code version: a single character on each user master row recording the hash generation in force for that account's current password. It changes when the password is next set, not when the kernel is upgraded, so a system running a current release can hold accounts that have not had a password change in a decade and still carry the oldest generation.
| Generation | Field | Construction family | Properties that matter |
|---|---|---|---|
Oldest (B) |
BCODE |
MD5-based, over password and user name | Folds case on both password and user name, and truncates the password to eight bytes before hashing. Unsalted. |
Middle (F, G, I) |
PASSCODE |
Two-pass SHA-1, over password and user name, truncated | Case-exact on the password, no length limit. Unsalted, so it is exposed to precomputation. |
Current (H) |
PWDSALTEDHASH |
Salted, iterated SHA-1 or SHA-512 | Per-account salt and an iteration count, both carried in the stored value. The only one of the three that resists precomputed tables. |
Because of what it cannot record. BCODE folds case and cuts the password at eight bytes, which means the stored evidence cannot record the two things a password policy most commonly demands. Length past eight is not in it, and case is not in it. A policy requiring a twelve-character mixed-case password can be perfectly enforced and perfectly reported, and the artefact sitting in the user master for an old account is still an eight-byte, case-folded fingerprint of whatever was set.
Two consequences follow for anybody reading a finding:
BCODE proves the first eight characters, case ignored. It is a real exposure, because the field is still there and still attackable offline. It is not necessarily a string that will log on.BCODE can survive beside a modern hash. An account written under the current generation can still carry a redundant older hash on the same row if the system was ever configured to keep downwards-compatible hashes. The weakest artefact on the row is then the one nobody looks at.By stopping the system from writing them and by clearing what is already there. The relevant instance parameter controls whether downwards-compatible password hashes are maintained alongside the current one; with it set so that old hashes are no longer written, the redundant fields can be cleared for accounts whose password has since been reset. Which parameters are set to what on a given system is the subject of SAP profile parameter checks, and the two capabilities answer adjacent halves of the same problem: the parameter says what will be written next, the hash says what is written now.
Clearing the old hash does not improve a weak password. It removes one cheap way of attacking it, which is worth doing and is not the same thing.
Yes, and the difference is large. An unsalted hash of either older generation can be attacked with a precomputed table, so the work is done once and reused against every system in the world. The current, salted and iterated construction forces the work to be repeated per account, at whatever iteration count the stored value names. Under the current generation, a weak password is a statement about the password. Under the oldest, it is partly a statement about the hash.
These are properties of the SAP constructions, not of any product's implementation. What a specific system does at logon depends on its kernel release and its parameter settings, and a hash present in a field is not proof that the field is the one checked. Where a finding depends on that distinction, it is called out in what a password test does not prove.
The salted, iterated one, when the account has been written under the current generation. Accounts that have not had a password change since an older kernel are checked against the field their CODVN names.
It is a weakness worth removing, and this capability reports the outcome of an attack rather than the presence of a field. The presence of downwards-compatible hashes is best addressed at the parameter and the reset, together.
Yes. The salted field carries a prefix naming the algorithm and the iteration count, followed by the salt and the digest. That is why the construction resists precomputation but not a dictionary attack against a weak password.
What one password test result says explains which field is attacked for which account, and SAP password strength testing is the capability overview.