Password strength testing in the RedRays Security Platform reads five fields of the user master table out of one SAP client over a remote function call, keeps them on the installation you run, and compares candidate passwords against them there, without attempting a logon on the SAP system.
Two properties of that arrangement decide most of the questions a security team asks before approving it: nothing is written to the SAP system, and the hash material never leaves the network the installation sits in.
One table, five fields, one client per read: the user name, the generation code and the three hash fields. The extraction is a table read over a remote function call, using either the SAP system's SOAP-based remote function service or a native RFC connection, with the credentials registered for that connection. No other table is read by this capability at any point.
Because the user master is client-dependent, the client is part of the request. One host serving three clients is three reads and three results, and a read of one client is not evidence about another.
An SAP account that can call a remote-enabled table read and is authorised to read the user master table in that client, plus network reachability to the remote function service. That is a powerful authorisation, and it should be treated as one:
The account does not need change authorisation. The capability performs a read; it does not create, lock, unlock or reset anything in SAP.
No. Candidates are hashed and compared on the installation, and no recovered value is ever presented to the SAP system. That has three practical consequences worth stating plainly, because they are usually the first three questions from a Basis team:
The hashes are read into the installation you run, on your own infrastructure, and the comparison happens there. This capability calls no external service, so nothing about your user master reaches RedRays or anybody else. That is the general arrangement for the platform and it is described in deployment and where data goes; it is worth restating here because password hashes are the most sensitive material any of these capabilities touches.
The hash material that is kept at rest is what the results need. Anything you export is credential material in a file, and password test results and handling is how to treat it.
By connection, which is one credentialed service on one host with one client. The practical scoping decisions are:
No. It performs a table read. Resets, locks and expiry changes are yours to make in SAP after a finding.
The read is one table read and the attack runs elsewhere, so the load on production is small. The decision that matters is not load but authorisation: somebody is being given the ability to read the user master, and that should be scoped and logged.
Hash material is held on your installation for the connections in scope, and it stays inside your network. If a system is out of scope, do not register a connection for it.
SAP password strength testing is the overview, and password test results and handling is what happens once a read has been attacked.
Then the read cannot happen, and the capability reports the client as not read rather than as clean. That distinction is the subject of recovered, resisted, never tested.