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/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
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 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 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 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, 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: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 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 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 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 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 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 5/3/20 1:16 AM, Bill Cole wrote:
> On 30 Apr 2020, at 14:59, Tom Williams wrote:
>
>> Hi! I'm new to this mailing list, but not new to SpamAssassin. I've
>> used it on and off for a number years. :) Recently, (within the
>> past 6 months or so) I enabled it for email in a shared web hosting
14 matches
Mail list logo