Dear All,

I think Jesse and me had a discussion about an year ago about md5 and
encryption.
First, encryption in the database is crucial, regardless of the DB
being in an internal segment, public server etc. A person wouldn't want
his password being seen in any situation, like overlooking when
browsing the DB or by support staff when checking for problems. So the
best solution is to encrypt all passwords and just reset one if there
is a problem.
From my first implementation of DBMail I had to make it compatible
with the current user/password list - shadow. You all should know that
shadow works with md5 hash. And not md5sum. So if the guys that
contribute to UNIX/Linux etc. development chose md5 hash it should
have been for a reason. And one is that md5sum is tailored and used
for file checking, and not passwords.

So please encrypt passwords for both MySQL and PGSQL by default and
use md5 hash as it doesn't even store the password - only a hash :)

Hope that you will consider my humble opinion.

Best regards,
Bobby


Friday, August 20, 2004, 7:03:29 AM, you wrote:

S> Jesse Norell wrote:
>> Hello,
>> 
>>> DBMA 2.0.2 uses MD5-Digest (md5sum) by default for MySQL which is a
>>> built-in since around v4.0 but I am in a quandary with PostgreSQL
>>> which seems to rely on contribs to handle md5 selects. There also
>>> seems to be quite a range of options. I wonder what seasoned
>>> PostgreSQL folks would favour? (Is anyone using PSQL 8-beta?)
>> 
>>   What we do is have the application do all the md5 functions (which
>> are quite easy in perl) and just pass the actual hash back and forth
>> between the database.  That way you plaintext passwords never cross
>> the network (assuming your db server is on another computer), so it's
>> more secure, and it doesn't need any of the pgsql contrib md5
>> functions. 

S> We don't bother encrypting the passwords at all.. Granted our db is on a
S> non routable subnet, but we are talking pop and imap after all which
S> transmit the passwords in cleartext over the net anyways, so what's the
S> point?  That said, anyone wrapping ssl over imap/pop or anything like
S> that?

S> It's definetely an advantage of a dbmail type setup tho, if an account
S> gets compromised at worst only a users email is affected.

S> -----
S> "Any sufficiently advanced bug is indistinguishable
S> from a feature." -- Rich Kulawiec
S> [EMAIL PROTECTED]

S> _______________________________________________
S> Dbmail mailing list
S> Dbmail@dbmail.org
S> https://mailman.fastxs.nl/mailman/listinfo/dbmail


Reply via email to