-----Original Message-----
From: "Andreas Pflug"<pgadmin@pse-consulting.de>
Sent: 01/05/06 11:46:24
To: "svn@pgadmin.org"<svn@pgadmin.org>
Cc: "pgadmin-hackers@postgresql.org"<pgadmin-hackers@postgresql.org>
Subject: Re: [pgadmin-hackers] SVN Commit by dpage: r5106 - in trunk/pgadmin3:
> Is that a good idea to do this in a private md5 implementation? libpq is
> going to/already exporting a method for this, which will make us less
> sensitive to backend changes.
I considered this carefully and chose that method for a few reasons.
- Any change (say, to sha1) is a major compatibility issue for any libpq client - it wouldn't be taken lightly, we
couldn'tfail to miss the change, and it'll be mainly a cut n paste job to fix.
- Using libpq to do it requires configure time checks for the correct libpq on *nix, and runtime checking on Win32. I
couldn'tfind a sensibly clean way to do the latter.
- Using libpq essentially forces ppl to upgrade to the latest client to benefit from the extra security.
All in all, a private implementation seemed the least painful, and secure option.
/D
-----Unmodified Original Message-----
svn@pgadmin.org wrote:
> Author: dpage
>
> Date: 2006-04-30 21:13:00 +0100 (Sun, 30 Apr 2006)
>
> New Revision: 5106
>
> Revision summary: http://svn.pgadmin.org/cgi-bin/viewcvs.cgi/?rev=5106&view=rev
>
> Log:
> Pre-encrypt passwords before sending them down the wire or displaying them in SQL statements.
Is that a good idea to do this in a private md5 implementation? libpq is
going to/already exporting a method for this, which will make us less
sensitive to backend changes.
Regards,
Andreas
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
