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
