A recovered SAP password proves one thing: a candidate string, hashed the way SAP hashes it for that account's generation, reproduced the value stored in the user master table. Everything else a reader adds to that sentence is an assumption.
This page is the list of assumptions, written for people evaluating password strength testing in the RedRays Security Platform who would rather know the limits before the first result than after. A capability that says what it does not do is easier to act on than one that does not.
| Not done | Why it matters |
|---|---|
| No keyspace or mask attack | This is a dictionary attack. A long random password is out of reach of it by design, which is the correct outcome and not a measurement of strength. |
| No second hash field per account | One field is attacked, chosen by the account's generation. An older hash left on the same row is not attacked. |
| No logon attempt | Nothing is tested against SAP itself, so no account can be locked out and no recovery is confirmed against a live logon. |
| No policy evaluation | Parameter values are the subject of SAP profile parameter checks. |
| No authorisation analysis | No role, profile or authorisation object is read here. |
| No offline import | The hashes have to be read from a reachable system, per client. |
| No workflow state | No acknowledgement, waiver or closure is recorded against a recovery. |
Because the failure mode of this kind of testing is a clean report that nobody re-opens. A false positive corrects itself within a day, when somebody types the password and is refused. A false negative is permanent, because nothing revisits a system that came back clean. The only defence is a reader who knows what the clean result was a statement about, and that requires the vendor to say so. The rule the platform is built on is what a finding does and does not claim: a number nobody measured must never be shown as if it were measured.
As evidence of what was tried, yes, if you record the client, the date and the candidate list beside it. As evidence that the passwords are strong, no.
Yes. The field is present in the system and can be attacked offline by anybody who obtains it. It is a real exposure with a narrower claim attached, and the narrower claim is in what one password test result says.
Because an automated logon attempt against a production account is a different and more dangerous act than a table read, and it can lock accounts out. Verification belongs to a person, deliberately, on an account they have checked first.
SAP password strength testing is the overview, and how the test reads SAP password hashes is what the read needs and what it leaves behind.
A larger candidate list, every client covered rather than the busy ones, and a record of which list ran when. Those three turn a silence into an argument.