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
smime.p7s
Description: S/MIME Cryptographic Signature
