A weak SAP password is invisible to the system that stores it, because SAP keeps only a one-way hash of it: no transaction, no report and no remote function call can turn that hash back into a password or judge its strength.
This is the reason SAP password strength testing in the RedRays Security Platform works the way it does, by hashing candidates and comparing, rather than by asking SAP. It is also the reason the job is rarely done properly by hand. Four obstacles get in the way, and each of them is also a constraint on what any product can honestly claim afterwards.
Because the system does not know the password either. The stored value is the output of a one-way function over the password and the user name. SAP checks a logon by computing the same function over what was typed and comparing the result, and that is the only operation available to anybody. There is no call that answers "is this password weak", and there never will be. The work splits in two: reading the table, which needs an authorised logon, and computing the comparison, which needs a correct implementation of each hash generation SAP has ever used.
Because the evidence is one table per client, not one per system. USR02 is client-dependent. Two clients of one instance hold two separate populations of users and two separate sets of password hashes. A default SAP* still open in client 000 is invisible to anybody who reads client 100, and a system copied from another system carries the source system's passwords into the copy.
So the unit of work is a client, not a host. A single production instance with three clients is three logons, three extractions and three sets of results, which is where a manual exercise starts to collapse: nobody reconciles three spreadsheets a second time.
Because SAP has not stored a password the same way for twenty years, and the user master carries the sediment. BCODE, PASSCODE and PWDSALTEDHASH are three separate fields on the same row, and CODVN names which generation that account currently belongs to. They are different constructions with different properties, and a candidate that matches one of them proves a different thing in each case.
The question is therefore not "is this password weak" but "is this password weak in the field this account is actually checked against". A spreadsheet of user names does not survive contact with that. SAP password hashes and CODVN is the table that sorts it out.
Because a subtly wrong implementation fails exactly the way a strong password fails: silently, for every account, with no error. A user name compared with the trailing blanks still on it. A hash field taken at its full field width instead of as the hexadecimal string the comparison expects. A case fold applied on one side and not the other. Every one of those produces no match, for every candidate, for every account of that generation, with no exception raised, no log line and no visible difference from a landscape where every password is strong.
That is why an in-house attempt usually ends in a clean report that nobody can distinguish from a broken one, and why any product doing this work should be asked what it does when a field arrives in a shape its comparison cannot handle.
| Error | What it costs |
|---|---|
| An account reported weak that is not | Somebody resets a password that was fine. On a dialog user that is an interruption. On a service or communication account it is an outage, because the same password is written into whatever calls that account. |
| An account reported fine that nobody actually tested | A default administrator stays open and the report says so in green. Nothing revisits it, because a clean result is not the kind of thing anybody re-opens. |
The two are not symmetric in how long they last. A false positive corrects itself the same afternoon, when somebody types the password and is refused. A false negative is never revisited. That asymmetry is why recovered, resisted, never tested matters more here than in most security tooling, and why what a password test does not prove is written as plainly as it is.
A policy binds the next password change. It does nothing to a password that was set years ago and never changed since, which is exactly the population this test is about. Password policy against a hash test is the comparison.
Yes. The user master travels with the copy unless the copy profile excludes it, so a test system created from production inherits production's passwords, usually with weaker network controls around it.
It is credential material and should be handled as such. The read needs an authorised account, the hashes stay on the installation you run, and how the test reads SAP password hashes sets out what the account needs and what is done with the result.
The ones nobody logs on to. Old clients, sandbox and training systems, and anything created by a copy are where documented default accounts survive, because they are the systems nobody re-secured. See SAP default accounts and passwords.