On Mon, 4 May 2020, Grant Taylor wrote:
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.
Note I said "obfuscate".
"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.
Both of those require code changes to SA, best implemented in the form of
a new plugin. I was assuming that the question "can a hash be compared?"
was implying "using existing code", for which the answer is no. Otherwise
the answer is trivially "Yes. Patches welcomed."
The big problem for either approach is: how much of the message do you
include in the operation, and where are the boundaries?
The only *reliable* option I can see is "hash each word separately" -
which is going to be a ton of work for very little gain, unless it is only
applied to small parts of the message, for example, the subject header
(modulo the inevitable cases where the entire email body is in the subject
header either do to incompetence or an attempt to bypass body text
filters). Then we're making assumptions about where the leaked password
would appear, which potentially weakens the detection.
I could see a simple plugin that hashes each word in the subject header
separately into a new internal header like:
X-Spam-Subject-Hashed: c8fc4bce46291fd606914d8dcee45465
635e304de3f24679f41e789a5d0d5059 6e2458faf2b8349b5c3fc2dc8bf6a880
2a462d9a15339fef5d7a54dc8b53ed95
...to which normal header rules could be applied, e.g.:
header LEAKED_PASSWORD X-Spam-Subject-Hashed ~=
/\bc8fc4bce46291fd606914d8dcee45465\b/
There probably would need to be a length limit for this to address the
Incompetent Sender case noted above.
Note that even this is potentially trivially easy for the spammer to
avoid, if they do something like:
Subject: Your password is "P@ssw0r|)"!
...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.
I'm aware of that. I was suggesting something better than plaintext
(granted, not much) that can be implemented *today*.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhar...@impsec.org FALaholic #11174 pgpk -a jhar...@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
Our politicians should bear in mind the fact that
the American Revolution was touched off by the then-current
government attempting to confiscate firearms from the people.
-----------------------------------------------------------------------
4 days until the 75th anniversary of VE day
