¶ What One Password Test Result Says
A password strength result in the RedRays Security Platform is a statement about one row of the SAP user master table, in one client, on one host, as that row stood at the moment of the read, and about exactly one of the three hash fields on it.
That is narrower than "the passwords on this system are strong", and the difference matters when the result is read out loud in a meeting. This page sets out the unit, the fields behind it, what a recovery proves under each hash generation, and what a non-recovery proves, which is less.
¶ What is the unit of measurement?
One user master row, reduced to five fields, in one client. Every figure the capability prints counts those rows. There is no per-user strength score, no policy comparison and no severity ranking: an account is either one whose password was recovered or one whose password was not.
Above the row sits one other unit, the connection: one credentialed service on one host, with one SAP client. Because USR02 is client-dependent, a host serving three clients is three connections, three reads and three sets of results, and nothing about one of them is evidence about the other two.
Each client of a host is a connection of its own, with its own read and its own result, so one card is never evidence about the card beside it.
¶ Which fields are read, and which are not?
| Read | Not read |
|---|---|
BNAME, the user name, which is an input to the hash |
UFLAG, the lock state |
CODVN, the password generation |
USTYP, the user type: dialog, system, service, communication |
BCODE, PASSCODE, PWDSALTEDHASH, the three hash fields |
GLTGB, the validity date |
| roles, profiles, last logon, password change date |
The right-hand column is worth as much as the left, because it is the list of sentences a result cannot support. Four of them:
- It is not a statement that the account can be logged into. A recovered account may be locked, expired, or a system or service user that takes no dialog logon at all. The three fields that would answer it are not requested.
- It is not a statement about the system, only about one client of it.
- It is not a statement about the whole account. One hash field is attacked, chosen by
CODVN. The other two are not. - It is not a statement about what the account could do. No authorisation data is read here at all; that is segregation of duties analysis.
¶ What does a recovery prove?
That a candidate password, hashed the way SAP hashes it for that generation with that account's own user name, produced the same value as the one stored in the user master. How much of the password that pins down depends on the generation, and this is the part most often over-read.
| Generation | Field attacked | What a hit proves |
|---|---|---|
| Current, salted and iterated | PWDSALTEDHASH |
The whole password, against the field a current kernel checks at logon. If the account is open, the string will log on. |
| Middle, unsalted | PASSCODE |
The whole password, case-exact. The qualification is on the other side: this field may no longer be the one the system checks. |
| Oldest | BCODE |
The first eight characters, case ignored. That is all this field records, so a longer or differently-cased password is not fully in evidence. |
The third row is the one to read twice. A hit against the oldest generation is a real exposure, and for a documented default account it is usually the whole password. But the recovered string may differ in case from what a user types, and may be a prefix of it, so a customer who types it into a logon screen and is refused should not conclude the finding was wrong. The hash did fall. SAP password hashes and CODVN explains why that field cannot record more.
¶ What does a non-recovery prove?
That the candidates that were tried did not reproduce the stored hash. It does not prove the password is strong, because the statement is about the list, not about the password. Three different situations produce no finding:
- Every candidate in the chosen list was computed against the hash and none matched.
- The chosen list was small, and a larger one would have found it.
- The hashes for that client were never read, so nothing was attacked at all.
The third is reported as its own state and is never dressed up as a clean result: a connection whose hashes have not been read says so, in place of a zero. Keeping those situations apart is the whole subject of recovered, resisted, never tested, and the platform rule behind it is what a finding does and does not claim.
¶ What is tried against a hash?
A dictionary. Several candidate lists ship with the product, from a short list of documented SAP default passwords up to general lists of the most common passwords, and there is a custom mode in which an operator supplies one seed password and a small fixed set of variations is built from it: year suffixes, one or two digits, a special character. That is the whole mutation vocabulary.
There is no mask attack, no incremental keyspace walk and no rule engine, and the product does not claim any. The practical consequence is on the reader rather than on the run: the size and the choice of list are part of what a clean result means, so record which list was used when you record the result.
¶ Limits of a single result
- It describes one client at one moment. It is not a standing property of the system, and a password changed the next day makes it stale.
- It carries no severity and no score. A recovery on a locked test account and a recovery on a live administrator look the same until somebody checks the account, which needs data this capability does not read.
- It says nothing about how the password got there, when it was last changed, or whether the same password is used elsewhere.
- It cannot see passwords held outside SAP: interface credentials in middleware, secrets in scripts, or logons stored in a client-side connection file.
¶ Frequently asked questions
¶ Why not read the lock flag and user type as well?
They would make a finding easier to triage and they are not part of what this capability reads today. Until they are, treat the account type check as a manual step before remediation, which is set out in password test results and handling.
¶ If an account has an old hash and a new one, which is attacked?
The one its current generation names. An older, weaker hash left behind on the same row is not attacked, which is a reason to remove downwards-compatible hashes at the source. See SAP password hashes and CODVN.
¶ Is a recovered password shown on screen?
No. The console shows counts. The recovered value is not sent to the browser and leaves only through an explicit export.
¶ Where does this sit in the capability?
SAP password strength testing is the overview, and password test results and handling is what to do once a result exists.
¶ Can two results from different dates be compared?
Only as counts. A result records the accounts that fell, not the work that was done, so treat a change in the count as a prompt to look rather than as a measured trend.