¶ Recovered, Resisted, Never Tested
Behind every SAP password hash there are three answers a report can give, and only one of them is good news: the password was recovered, the hash was attacked and the dictionary did not contain the password, or nobody has read the hash yet so nothing was attacked at all.
Those three carry three different actions for the person reading the report, and two of them are not "do nothing". The RedRays Security Platform keeps the third apart from the other two deliberately, because a system nobody looked at is not a system with no weak passwords.
¶ What are the three answers?
| Answer | What it means | What to do next |
|---|---|---|
| Recovered | A candidate reproduced the stored hash. The password is known. | Reset it, in every client, and find out where else the credential is written before you do. |
| Attacked and resisted | Every candidate in the chosen list was computed against the hash and none matched. | Record which list was used. Consider a larger one for accounts that matter. |
| Never read | Nobody has extracted the hashes for this client, so nothing has been compared with anything. | Read them. This is not a result, and nothing about the client's passwords has been established. |
The distinction that gets lost most often is between the second and the third, and it is lost in favour of the reassuring one. A count of zero recovered passwords over a client nobody has read is a true zero and a meaningless one.
¶ Why is "none recovered" not the same as "strong"?
Because it is a statement about a list. A dictionary attack asks whether a password is in the candidate set you chose. If it is not, the account produces no finding, and so does an account with a genuinely strong password. The two are indistinguishable in the result, and the honest way to read a clean result is: no password on this client was in the list that was used.
That is why the list belongs in the record next to the result. A clean result against a short list of documented default passwords and a clean result against a list of a hundred thousand common passwords are different evidence, and a report that does not name the list does not let you tell them apart.
¶ Why does "not read" get its own state?
Because a zero drawn over an empty measurement reads as a pass. A connection whose hashes have never been extracted shows that it has not been read, in place of a count, and the control that starts an attack is switched off with an explanation rather than left live over nothing. The summary figure for hashes read names its own denominator, so a total is never printed without saying how much of the landscape it speaks for.
Where a count would sit, a connection nobody has read says so, and the control that would start an attack stays switched off until there is something to attack.
This is the same rule the platform applies everywhere: see what a finding does and does not claim and, for the parameter equivalent, not found against not set.
¶ How do you tell which answer you are looking at?
Ask four questions of any password strength result, from any tool:
- Were the hashes read for this client? Not for the system, for the client.
USR02is client-dependent. - Did a run actually happen against them? Reading hashes and attacking them are two separate steps, and only the second one tests anything.
- Which candidate list was used, and did the run finish? A run that was stopped early is not a clean run, and a partial pass is not evidence about the accounts it never reached.
- How many accounts were in scope? A count is only as good as the population behind it.
If a report cannot answer all four, treat its clean results as unmeasured rather than as passed. That standard is uncomfortable to apply to your own tooling, and it is the one worth applying.
¶ What this page does not say
It does not say a resisted hash is worthless evidence. It is worth something: it rules out a specific, well-known population of passwords, which is exactly the population an opportunistic attacker starts from. It says only that the sentence "none recovered" carries a qualifier, and that the qualifier is the list.
¶ Frequently asked questions
¶ If nothing was recovered, do we still have to do anything?
Record what was tried and against which client, then decide whether the list you used is the standard you want to hold. For accounts that hold administrative authorisations, a short default-password list is a low bar.
¶ Can a report tell us that an account resisted?
Not as a per-account statement. What is recorded is the accounts that fell. An account that produced no finding was in scope and did not fall to the candidates used, and that is the strongest form the negative takes.
¶ Does a bigger list always give a better answer?
It gives a more expensive one, and a better one only up to a point. Beyond the common-password lists, a dictionary attack stops being the right instrument and the question becomes a policy and hash-generation question. See password policy against a hash test.
¶ Where does this fit in the rest of the review?
What one password test result says is the unit of measurement behind these three answers, what a password test does not prove is the full list of limits, and SAP password strength testing is the capability these pages describe.