An SAP password policy is prospective, binding every password set from now on, while a password hash test is retrospective, measuring the passwords already sitting in the user master, and a system can pass either one while failing the other.
Both checks exist in the RedRays Security Platform and they are deliberately separate entries, because two checks about passwords need names that say which is which. This page is when to use each and what neither of them answers.
| Password policy check | Password hash test | |
|---|---|---|
| Evidence read | Instance profile parameters: minimum length, character classes, expiry, history depth, downwards-compatible hashes | The user master table in one client: the user name, the generation code and the hash fields |
| Question answered | What will the system demand the next time somebody sets a password | Which stored passwords fall to a dictionary today |
| Scope | The instance, and every client on it | One client at a time |
| Result | A parameter value against a recommended value | An account name, or nothing |
| Fails when | A parameter is weak, missing or overridden | A candidate reproduces a stored hash |
| Where it lives | SAP profile parameter checks | SAP password strength testing |
Because no parameter reaches backwards. A password set years ago, under an older kernel, by an administrator who has since left, is untouched by a minimum length that was tightened last month. Expiry helps only if the account is one that ever logs on interactively; service and technical accounts commonly have expiry disabled precisely so that interfaces keep running, which means their passwords are the oldest in the system.
The clearest instance is the oldest hash generation. Its stored field folds case and truncates the password to eight bytes, so it cannot record the two things a policy most often demands. Length past eight and case are simply not in the evidence. A policy demanding both can be perfectly enforced and perfectly reported while the artefact in the user master remains an eight-byte, case-folded fingerprint. SAP password hashes and CODVN is the detail.
Because a clean hash test is a statement about a candidate list at a moment in time. It says the passwords in this client were not in the list that was used. It says nothing about the next thousand passwords the system will accept, and a system with no minimum length will produce a fresh crop of weak passwords the week after a clean test.
The two are also asymmetric in cost. Fixing a parameter is one change with a defined blast radius. Fixing a stored password means a reset, in every client, on an account whose credential may be embedded in machinery.
Run the parameter check first, because it is cheap, it needs no credential material handling, and it tells you whether the population you are about to measure is going to be replenished. Then run the hash test, per client, starting with the clients nobody logs on to. Then keep both: the parameter check on a schedule, the hash test after every event that creates accounts in bulk or copies a system.
A forced reset moves every account that actually resets. Technical accounts, accounts excluded from expiry, and accounts in clients nobody touched are the ones that do not move, and they are the ones the test finds.
Not directly. It names accounts, not parameters. What it does give you is evidence for the argument: a recovery on a live account is the most persuasive input a policy discussion gets.
No. The parameter check reads instance configuration; the hash test reads a table in each client and needs an account authorised for that read. How the test reads SAP password hashes sets out the second one.
Usually the parameter set, because it is standing evidence. The hash test is what turns a parameter finding from a policy observation into a demonstrated exposure, so the two are strongest presented together.