Re: SVN Commit by dpage: r5106 - in trunk/pgadmin3:

-----Original Message-----
From: "Andreas Pflug"<pgadmin(at)pse-consulting(dot)de>
Sent: 01/05/06 11:46:24
To: "svn(at)pgadmin(dot)org"<svn(at)pgadmin(dot)org>
Cc: "pgadmin-hackers(at)postgresql(dot)org"<pgadmin-hackers(at)postgresql(dot)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't fail 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't find 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(at)pgadmin(dot)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