A password strength result in the RedRays Security Platform is presented as counts, never as a password: the console shows how many hashes were read for a client and how many were recovered, and the recovered values leave only through an explicit export.
That split is deliberate, and it changes how the result should be handled. What is on screen can be shown in a meeting. What is in the export is credential material for accounts on a production system, and everything in this page follows from that distinction.
Per connection, which is one client on one host: whether the hashes have been read, how many were read, and how many accounts were recovered. Above the connections, a summary for the landscape names its own denominator, so a total is never printed without saying how many connections it speaks for.
No password value is rendered anywhere in the interface, in any state, cell, dialog or tooltip. There is no masked form and no click-to-reveal, because the value is not sent to the browser to begin with. A screenshot of this capability cannot leak a password, and neither can somebody standing behind the analyst.
Recovered passwords in the clear, one row per recovery, with the account name and the hash material for the same account beside it. It is not a report. It is a file of working credentials for a live SAP client, and it should be handled the way you would handle a password vault export:
A second export exists that carries hash material without recovered passwords, for teams that want the raw evidence. It is the same class of file with a slightly lower temperature: hashes for accounts that were not broken are exactly what an attacker would want in order to continue offline.
Both exports reach as far as the person who requests them. Restrict who holds an application account in the first place, and treat the ability to run this capability as an administrative permission rather than a reporting one.
In this order, because the reverse order causes outages.
No. Give an auditor the counts, the scope and the dates. Handing over working credentials for a production client creates a worse finding than the one being reported.
Because there is no reading of a password on a screen that is worth the risk of it being on that screen. A count answers the question a reviewer has; the value is only needed by the person doing the reset, and they get it from an export they had to ask for.
Keep the counts and the scope for as long as you need the history. Delete recovered values as soon as the resets are done. A recovered password is a liability that grows with time, because the account it belongs to may be reset and the file forgotten.
SAP password strength testing is the overview, and how the test reads SAP password hashes is what happens before a result exists.
Then the interface configuration is part of the fix, not an argument against it. A password that fell to a dictionary is known to an attacker in the same way it is known to you, and the interface is exactly what an attacker would use it against.