Mailing List Archive

On 5/1/2020 10:23 AM, AJ Weber wrote:
> I am seeing a number of extortion emails where the hacker has gotten
> my email address and an old password from "the dark web". (Probably
> one of many lists that are out there from one of the many mega-hacks
> that have occurred.)
>
> Is there a way to check for a specific 1-2 words in the body being
> repeated > n times?  The emails seem to be camouflaging their body
> with random HTML and encoding chars.  But they like to repeat my old
> username and an old password a large number of times pretty clearly (I
> guess to get our attention).
>
> If I can check for these terms (individually would be fine), I think I
> could setup some meta rules that would score the number of hits in
> ranges.  Once or twice would probably be no score.  3-5 times would be
> a reasonable score. >5 hits would be an almost automatic spam score.
>
> Please help, apparently this person "knows everything about me" :)

Hi AJ, in KAM.cf, see my CRIM ruleset.  It's what I use for these type
of scam emails.

For your specific question, look at maxhits / multiple and the
__KAM_COUNT_URIS might get you a hint.

Regards,
KAM

> Please help, apparently this person "knows everything about me" :)

I got a rash of these a year or two ago, and have started getting a few more
reciently. I haven't looked at the body of the recient ones, so don't know
if they are still using the standard text. However, the identiying feature
is that the subject is a single word, which is the stolen password.

You should be able to catch these with a single custom rule along the lines
of

header STOLEN_PASSWORD Subject =~ /old_password/
score STOLEN_PASSWORD 10


Loren

On Fri, 1 May 2020, Loren Wilton wrote:

>> Please help, apparently this person "knows everything about me" :)
>
> I got a rash of these a year or two ago, and have started getting a few more
> reciently. I haven't looked at the body of the recient ones, so don't know if
> they are still using the standard text. However, the identiying feature is
> that the subject is a single word, which is the stolen password.
>
> You should be able to catch these with a single custom rule along the lines
> of
>
> header STOLEN_PASSWORD Subject =~ /old_password/
> score STOLEN_PASSWORD 10

That's what I do.

--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
Once you’ve convinced yourself that your job is to
protect the proles from themselves, any foul action you take
becomes excusable, or even noble. That’s progressivism
in a nutshell. -- Stephen Green @ instapundit
-----------------------------------------------------------------------
Today: May Day - Remember 110 million people murdered by Communism

Yes, noticed that as well and considered making it simple with that
rule.  Probably best thing to do anyway.

Thank you both.

-AJ

On 5/1/2020 5:08 PM, John Hardin wrote:
> On Fri, 1 May 2020, Loren Wilton wrote:
>
>>> Please help, apparently this person "knows everything about me" :)
>>
>> I got a rash of these a year or two ago, and have started getting a
>> few more reciently. I haven't looked at the body of the recient ones,
>> so don't know if they are still using the standard text. However, the
>> identiying feature is that the subject is a single word, which is the
>> stolen password.
>>
>> You should be able to catch these with a single custom rule along the
>> lines of
>>
>> header    STOLEN_PASSWORD    Subject    =~ /old_password/
>> score    STOLEN_PASSWORD    10
>
> That's what I do.
>

On 5/1/20 1:55 PM, Loren Wilton wrote:
> You should be able to catch these with a single custom rule along the
> lines of
>
> header    STOLEN_PASSWORD    Subject    =~ /old_password/
> score    STOLEN_PASSWORD    10

I'd pondered doing such.

But I dislike the fact that the (compromised) password is stored in
clear text and wonder about collision with other people using the same
password (or strings of characters).

Is there any way to compare hashed strings of text? E.g. take each word
from a message (header or body), hash it and look for a match of the
hashed password?

I feel like storing any password in clear text, previously compromised
or not, is a Bad Idea™.

I would also want to have some way to associate the (hashed) password
with a specific account to avoid collisions for other accounts that
might not have been compromised.

I don't know if it would be able to create the granularity that I want
with a meta-rule. Something that matches the account name (or some
other similar identifier) and then check the hashed password.

I also don't know that I would want the overhead of hashing every word
in messages unless they were otherwise suspicious enough to warrant such
in depth scrutiny.

Note: Everywhere I say "hash", I would really like to see salted and
hashed.



--
Grant. . . .
unix || die

Well, if you want to do it the hard way there may be a way.

I notice that three recient examples I have all failed DKIM check.
They also all have a very long header line that appears to have been
inserted either by outlook.com or the originating spamware:
X-VadeSecure-Cause. This has a very long hashed or possiby base-64 string.
While this seems to be part of the outlook.com spam checking info, for all
three messages I looked at, the first line (at least) of this cryptic blob
was identical. That likely means the message bodies are identical. You could
do a match for that and a meta to check that and dkim fail.

In my case I could maybe do something like:

header _UNSECURE_CAUSE X-VadeSecure-Cause =~
/gggruggvucftvghtrhhoucdtuddrgeduhedrieehgdefkecutefuodetggdotefrodftvfcurfhroh/

header _AUTH_FAIL X-Authentication-Results =~ /dkim=\"fail\"/

header _SUB_ONE Subject =~ /\s/

meta PASSWORD_SCAM _UNSECURE_CAUSE && _AUTH_FAIL && _SUB_ONE
score PASSWORD_SCAM 10

This strikes me as a lot of work and probably pretty fragile, and
unnecesary. The compromised password is already in plain text in the subject
of the message; there isn't much point in hiding it other than embarassment.

Loren

On Sat, 2 May 2020 12:47:12 -0700
Loren Wilton wrote:

> Well, if you want to do it the hard way there may be a way.
>
> I notice that three recient examples I have all failed DKIM check.
> They also all have a very long header line that appears to have been
> inserted either by outlook.com or the originating spamware:
> X-VadeSecure-Cause. This has a very long hashed or possiby base-64
> string. While this seems to be part of the outlook.com spam checking
> info, for all three messages I looked at, the first line (at least)
> of this cryptic blob was identical. That likely means the message
> bodies are identical. You could do a match for that and a meta to
> check that and dkim fail.
>
> In my case I could maybe do something like:
>
> header _UNSECURE_CAUSE X-VadeSecure-Cause =~
> /gggruggvucftvghtrhhoucdtuddrgeduhedrieehgdefkecutefuodetggdotefrodftvfcurfhroh/

That exact string occurs in a Vade Security header, X-ME-VSCause, added
by Fastmail on a completely unrelated legitimate email I received.

I think it's more like an obfuscated information header for Vade's own
use.

> That exact string occurs in a Vade Security header, X-ME-VSCause, added
> by Fastmail on a completely unrelated legitimate email I received.
>
> I think it's more like an obfuscated information header for Vade's own
> use.

I guess I'm not surprised. I would say then that it is a useless header as a
spam or scam marker.
Personally I'll stick with the easy method of a subject rule looking for the
offending password, or hopefully ex-password.

Loren

On 5/2/20 1:47 PM, Loren Wilton wrote:
> The compromised password is already in plain text in the subject of the
> message; there isn't much point in hiding it other than embarassment.

What if the email server with the list of plain text passwords is
compromised and said list of plain text passwords is released to a wide
audience? The list of previous compromised passwords could have been
very private (known corporate hack or something like that) and not
released to a wide audience.

Now, your list of plain text passwords on the email server is the source
of a larger and more public release.

Why have that list of plain text passwords /anywhere/ if you don't have to?



--
Grant. . . .
unix || die

Le 03/05/2020 ? 05:27, Grant Taylor a ?crit?:
> On 5/2/20 1:47 PM, Loren Wilton wrote:
>> The compromised password is already in plain text in the subject of
>> the message; there isn't much point in hiding it other than
>> embarassment.
>
> What if the email server with the list of plain text passwords is
> compromised and said list of plain text passwords is released to a
> wide audience?? The list of previous compromised passwords could have
> been very private (known corporate hack or something like that) and
> not released to a wide audience.
>
> Now, your list of plain text passwords on the email server is the
> source of a larger and more public release.
>
> Why have that list of plain text passwords /anywhere/ if you don't
> have to?
>
In the context of a list of passwords known to be compromised, it is
hopefully fair to assume that they are no longer in current use, and
thus no longer of any importance. If it isn't fair to assume that, then
the organisation has bigger issues in any case!

--
John

On 5/4/20 6:16 AM, John Wilcock wrote:
> In the context of a list of passwords known to be compromised, it is
> hopefully fair to assume that they are no longer in current use, and
> thus no longer of any importance. If it isn't fair to assume that, then
> the organisation has bigger issues in any case!

None of that changes the fact that storing a list of clear text
passwords is against current industry best practice.

Would you want to explain tot he board of directors / CEO that systems
you administer were the source of passwords being compromised because
you didn't encrypt / hash the passwords?

It does not matter where or how the passwords you put in the list came
from or were previously exposed. The fact remains that you are
describing maintaining a list of clear text passwords. This is plain
and simply against current industry best practice. Further, it would
fail security audits at many companies I have worked for.



--
Grant. . . .
unix || die

On 5/4/20 10:09 AM, Jeff Mincy wrote:
> The best practice is to not use common or continue to use exposed
> passwords. Scripts are probably trying to log into your ssh using
> those passwords.
I completely agree on both accounts.

> I think you are worrying about the wrong thing.

I obviously disagree. I'm already worrying about not using exposed
passwords. I'm also worried about creating a list of plain text passwords.

I think you're only worrying about the former and not giving any
consideration to the latter.

> The exposed passwords being used in the extortion emails are already
> widely known and have already been exposed.
Yes, the example you cited, and many others, are quite well known. But
those aren't the only exposed passwords.

> If you are still using the exposed password then you've got bigger
> problems.

I completely agree that (re)using exposed passwords is a problem.
Bigger or not is a different debate.

> If you are no longer using the exposed password then disclosing the
> previously used password further is not going to make any
> difference.

I disagree.

Storing any plain text passwords is a bad practice and should be avoided.

As such, storing plain text passwords /does/ make a difference.

> But, if you are really worried about it, don't write a spamassassin
> rule looking for your exposed passwords in the subject.

Which is why I have not. It's also why I asked if there was a way to
compare hashed text. To quote:

"Is there any way to compare hashed strings of text?"

I'll note that my question hasn't been answered. Instead, people have
focused on something not germane to my question.



--
Grant. . . .
unix || die

On Mon, 2020-05-04 at 13:03 -0600, Grant Taylor wrote:

> Which is why I have not. It's also why I asked if there was a way to
> compare hashed text. To quote:
>
> "Is there any way to compare hashed strings of text?"
>
> I'll note that my question hasn't been answered. Instead, people
> have
> focused on something not germane to my question.
>
Encrypt them and put them in a single column database table that's also
the prime key for the table?

Lookup by encrypting the item being checked before looking for an SQL
hit count:

select count(*) where log.key = key;

0=miss, 1=hit, 2+ = error. Should run fast. Of course, that would need
an SA plugin, but Perl SQL interface code isn't hard and is fairly
compact. For added protection, keep the database on an encrypted
partition. Any database should do: MariaDB, SQLite, PostgreSQL,...

You get points for added security by obscurity it you can stick it in a
corner of an existing, unrelated database.


Martin

On Mon, 4 May 2020, Grant Taylor wrote:

> On 5/4/20 10:09 AM, Jeff Mincy wrote:
>
>> If you are no longer using the exposed password then disclosing the
>> previously used password further is not going to make any
>> difference.
>
> I disagree.
>
> Storing any plain text passwords is a bad practice and should be avoided.

*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).

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.

> As such, storing plain text passwords /does/ make a difference.
>
>> But, if you are really worried about it, don't write a spamassassin
>> rule looking for your exposed passwords in the subject.
>
> Which is why I have not. It's also why I asked if there was a way to compare
> hashed text. To quote:
>
> "Is there any way to compare hashed strings of text?"
>
> I'll note that my question hasn't been answered. Instead, people have
> focused on something not germane to my question.

...thus, the answer to your question is "no, there is not".


You could potentially obfuscate the RE by doing something like:

header LEAKED_PASSWORD Subject ~= /\x50\x40\x73\x73\x77\x30\x72\x7c\x29/

...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.)


--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
Where We Want You To Go Today 07/05/2007: Microsoft patents in-OS
adware architecture incorporating spyware, profiling, competitor
suppression and delivery confirmation (U.S. Patent #20070157227)
-----------------------------------------------------------------------
4 days until the 75th anniversary of VE day

On 5/4/20 2:06 PM, Martin Gregorie wrote:
> Encrypt them and put them in a single column database table that's
> also the prime key for the table?
>
> Lookup by encrypting the item being checked before looking for an
> SQL hit count:
>
> select count(*) where log.key = key;
>
> 0=miss, 1=hit, 2+ = error. Should run fast.

Yep. We're describing similar concepts, encrypt / hash the known value
(from the email) and check to see if it's encrypted counterpart is in
the list.

Though, only encrypting the password and not associating the username
could allow for collisions between users with the same password. I
think that the minimum needed is the the password and a username (in the
form of an email address).

> Of course, that would need an SA plugin, but Perl SQL interface code
> isn't hard and is fairly compact. For added protection, keep the
> database on an encrypted partition. Any database should do: MariaDB,
> SQLite, PostgreSQL,...
Yep.

I see little benefit of an SQL database vs rules with the encrypted
(hashed) passwords (possibly salted with the usernames / email address)
in the SpamAssassin config file. Well, save for possible ease of
administration in that SA's config file doesn't need to be updated when
passwords are compromised.

> You get points for added security by obscurity it you can stick it in
> a corner of an existing, unrelated database.

<wince>

I'd be afraid that would be like setting yourself up for failure in the
future. Sure, it's obscure. But it's a ticking time bomb.



--
Grant. . . .
unix || die

On Mon, 2020-05-04 at 15:14 -0600, Grant Taylor wrote:
> I see little benefit of an SQL database vs rules with the encrypted
> (hashed) passwords (possibly salted with the usernames / email
> address)
> in the SpamAssassin config file. Well, save for possible ease of
> administration in that SA's config file doesn't need to be updated
> when
> passwords are compromised.
>
The list of such passwords might get rather long, so using a database
both makes maintenance easier, as you spotted, and also keeps a lot of
junk out of the rule sets. One Perl module and one or two rules
triggering it seem a lot easier to maintain than a whole heap of rules
containing unreadable junk but of course ymmv unless, of course you
write code to autogenerate the rules, but it still sounds like a good
way to inflate the ruleset to no good purpose.

However, I've long realised that not everybody is as keen on databases
as I am.

> > You get points for added security by obscurity it you can stick it
> > in a corner of an existing, unrelated database.
>
> <wince>
>
Yep, not really a serious suggestion.

Martin

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

On 5/4/20 3:09 PM, Jeff Mincy wrote:
> You will have to write a perl plugin for SpamAssassin that finds
> passwords in an email message and MD5 hashes those passwords and
> compares against a list of previously saved hashed passwords. The
> list of passwords could be stored in various ways.

ACK

Identifying what is and is not a password might be error prone. I
suspect it might be more efficient (for the programmer) to simply (salt
and) hash every word (possibly over a specific length) in the message
and compare that to the list of (salted) hashes. Sure, it's somewhat
brute force. But if it's only applied to messages with the proper
criteria, it might be acceptable.



--
Grant. . . .
unix || die

On 5/4/20 3:59 PM, Martin Gregorie wrote:
> The list of such passwords might get rather long, so using a
> database both makes maintenance easier, as you spotted, and also
> keeps a lot of junk out of the rule sets.

I absolutely agree.

I like the idea of keeping data outside of configuration files.

> One Perl module and one or two rules triggering it seem a lot easier
> to maintain than a whole heap of rules containing unreadable junk but
> of course ymmv unless, of course you write code to autogenerate the
> rules, but it still sounds like a good way to inflate the ruleset to
> no good purpose.
Agreed.

I think $DatabaseTechnology's main benefit is keeping the password data
outside of the configuration files.

As I write this, I may have thought of another idea.


> However, I've long realised that not everybody is as keen on
> databases as I am.

I have absolutely nothing wrong with a database per say. I just want to
make sure that it's the proper thing and that the proper type of
database is used for a given need.

select count(*) where log.key = md5(key);

You can move the md5 generation into the SQL server. Of course, you'd
want to be mindful of the communications channel between SpamAssassin
and the SQL server.

I'm not sure how to have SpamAssassin iterate all the words in the
message through this routine.

If it requires a custom SpamAssassin module, then it might be better to
do calculate the MD5 hash in SpamAssassin and avoid the security
implications between SpamAssassin and SQL server.

> Yep, not really a serious suggestion.

;-)



--
Grant. . . .
unix || die

On Mon, 2020-05-04 at 16:25 -0600, Grant Taylor wrote:
> I think $DatabaseTechnology's main benefit is keeping the password
> data outside of the configuration files.
>
Agreed, in this sort of corner case.

> select count(*) where log.key = md5(key);
>
Neat.

> You can move the md5 generation into the SQL server. Of course,
> you'd want to be mindful of the communications channel between
> SpamAssassin and the SQL server.
>
I was thinking that the database/whatever would be populated by feeding
in lists of dsto=len passwords, since they seem to be more or less
freely and at least semi-legally available, but now I'm wondering if it
would be possible to use some sort of generic pattern matching to
trigger a rule associated with a more complex Perl module which would
extract the password string from a message, encrypt it and check it
against the database. It it hits, score the message as spam. If not,
either:

(a) lob its encrypted form into the DB and return a zero score

or

(b) write its plaintext form to a file for somebody to look at and
decide whether its a false positive or to load it into the database.
Either way the nonmatch should score zero.

Note: this depends on whether SA modules can adjust their triggering
rule's score -I don't know if this is possible.

The sort of recognition rule I'm thinking of could be something as
simple as if its a Subject header with no spaces in the title and either
a known length or a prefix such as "password:"

> I'm not sure how to have SpamAssassin iterate all the words in the
> message through this routine.
>
Presumably passwords in body text have some surrounding text you could
match on along the lines of money with menaces:

"I know your bank password, which is xxxxxxxxx so pay me now".

However, since I've not seen any of these messages, this is probably the
point where somebody who is getting them will speak up and say that I'm
talking garbage.

> If it requires a custom SpamAssassin module, then it might be better
> to do calculate the MD5 hash in SpamAssassin and avoid the security
> implications between SpamAssassin and SQL server.
>
That makes sense because the closer to source you can encrypt the
password the more secure the whole system becomes. Doing it at the
database end would require a fairly gung-ho database - one that supports
a built-in (usually proprietary) procedural language.

PostgreSQL, SQLServer, Sybase, DB2 and other heavyweights have provide
procedural languages / stored procedures, but the likes of SQLite,
Derby, MariaDB probably do not.

Martin

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/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@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

On Tue, 5 May 2020, Martin Gregorie wrote:

> On Mon, 2020-05-04 at 16:25 -0600, Grant Taylor wrote:
>> I think $DatabaseTechnology's main benefit is keeping the password
>> data outside of the configuration files.
>>
> Agreed, in this sort of corner case.
>
>> select count(*) where log.key = md5(key);
>>
> Neat.

Agreed, but we still have the boundary problem.

In the hopes of leveraging existing facilities: Is there a way to mark
individual bayes tokens as poison pills?

The message is already being tokenized and scanned for Bayes (presuming
you have that enabled). If there's a way to mark a token in Bayes as
causing an automatic 1.000 then that might be a usable approach.

(Granted, it's not encrypted.)

--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
I'm seriously considering getting one of those bright-orange prison
overalls and stencilling PASSENGER on the back. Along with the paper
slippers, I ought to be able to walk right through security.
-- Brian Kantor in a.s.r
-----------------------------------------------------------------------
4 days until the 75th anniversary of VE day

>> You can move the md5 generation into the SQL server. Of course,
>> you'd want to be mindful of the communications channel between
>> SpamAssassin and the SQL server.
>>
> I was thinking that the database/whatever would be populated by feeding
> in lists of dsto=len passwords, since they seem to be more or less
> freely and at least semi-legally available,

How about modifying the interface to bayse to MD5 all of the words in the
email and match against that?

There seems to be a basic conceptual flaw here with the current thinking.

It is bad to store an unencrypted password.

*How do you KNOW that any random word in any random email is NOT a
password?*

You don't. Any word or phrase can be a password.

Putting ANY word or phrase in a rule or database is potentially storing an
unencrypted password,
even if the database used is named "shopping list" or the rule is
KNOWN_SPAMMER_NAMES.

Just because the extortion email claims to know a password does not mean
that it IS (or ever was) a password. The email address it is sent to might
be the acual password, and the putative password might be a mcguffin. Or
some phrase in the extortion mail might be the acutal password.

What if some major account is compromised because the password of "I knOw
YOur passwOrd" is discovered and you had a rule that contained =~ /i know
your password/i ? That woulnd't look very good for you, would it?

Clearly you are best off modifying the input stream to SA to MD5 all of the
input text, and rewrite all local rules to use MD5 rule names and have MD5
lookup text. You can probably write a simple preprocessor for the existing
SA rule base, so you don't have to take chances there.

Loren