On 5/4/20 2:51 PM, John Hardin wrote:
*if* they are being actively used for authentication, either by the security system (which is a glaring flaw in the design of the security system) or as a reference for accessing the secured resource (e.g. a plaintext passwords file on your desktop, which is user error).
Nope. There is no qualification for if it's okay to store passwords unencrypted or not.
I would also suggest it's a bad idea if the user generates passwords using a pattern. A compromised password that is no longer in use anywhere could still potentially expose the pattern used to generate passwords that *are* currently in use.
This is one of the many reasons why any and all passwords should be stored in a secure manner. You have no way of knowing / guessing if the passwords use such a pattern or not. Ergo, default to storing them in a safe manner; encrypted / hashed.
...thus, the answer to your question is "no, there is not".
Fair enough.
You could potentially obfuscate the RE by doing something like:header LEAKED_PASSWORD Subject ~= /\x50\x40\x73\x73\x77\x30\x72\x7c\x29/
That is encoded, not encrypted. It is trivially reversible. So much so that SpamAssassin, et al., don't even need to reverse it.
"P@ssw0r|)" is better stored as base64 encoding UEBzc3cwcnwp in that at least binary bit manipulation is required. It's trivial for scripts to do, but more difficult for humans to do.
Ideally, "P@ssw0r|)" would be stored as a hash from a one way trap function, c8fc4bce46291fd606914d8dcee45465. It's neigh impossible reverse contemporary hashes.
...which would at least not have the password trivially visible in plain text for anyone who can read the config file. (You'd of course, not use a rule name that indicated it was about a password.)
Real security doesn't depend on the secrecy of the algorithm used. You can have the rule named "LEAKED_PASSWORD" without any problem.
-- Grant. . . . unix || die
smime.p7s
Description: S/MIME Cryptographic Signature
