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 l
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);
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
plainte
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
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.
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
Id
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 i
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
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. Sho
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 b
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
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 disagre
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
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
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 passwor
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
sp
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 th
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 lon
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 st
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
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 stand
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
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 chec
23 matches
Mail list logo
