Thread

1. Re: Client-side password encryption

   Dave Page <dpage@vale-housing.co.uk> — 2005-12-18T15:53:53Z

   
   
   -----Original Message-----
   From: pgadmin-hackers-owner@postgresql.org on behalf of Peter Eisentraut
   Sent: Sun 12/18/2005 2:25 AM
   To: pgadmin-hackers@postgresql.org
   Subject: [pgadmin-hackers] Client-side password encryption
    
   > Commands like CREATE USER foo PASSWORD 'bar' transmit the password in 
   > cleartext and possibly save the password in various client or server 
   > log files.  I have just fixed this for psql and createuser to encrypt 
   > the password on the client side.  A quick check of the pgadmin3 source 
   > code shows that you are also affected by this issue.  I ask you to 
   > check where you paste cleartext passwords into SQL commands and change 
   > those to encrypt the password before sending or storing it anywhere.  
   > The required function pg_md5_encrypt() is contained in libpq.
   
   So did you just rip it from there into psql? I don't see it in the list of libpq exports so if thats not the case, on Windows at least we'll need to change the api, and possibly the dll name as well to avoid any compatibility issues.
   
   Regards, Dave.
   
   

2. Re: Client-side password encryption

   Andreas Pflug <pgadmin@pse-consulting.de> — 2005-12-18T16:07:04Z

   Dave Page wrote:
   > 
   > 
   > -----Original Message----- From: pgadmin-hackers-owner@postgresql.org
   > on behalf of Peter Eisentraut Sent: Sun 12/18/2005 2:25 AM To:
   > pgadmin-hackers@postgresql.org Subject: [pgadmin-hackers] Client-side
   > password encryption
   > 
   > 
   >> Commands like CREATE USER foo PASSWORD 'bar' transmit the password
   >> in cleartext and possibly save the password in various client or
   >> server log files.  I have just fixed this for psql and createuser
   >> to encrypt the password on the client side.  A quick check of the
   >> pgadmin3 source code shows that you are also affected by this
   >> issue.  I ask you to check where you paste cleartext passwords into
   >> SQL commands and change those to encrypt the password before
   >> sending or storing it anywhere. The required function
   >> pg_md5_encrypt() is contained in libpq.
   > 
   > 
   > So did you just rip it from there into psql? I don't see it in the
   > list of libpq exports so if thats not the case, on Windows at least
   > we'll need to change the api, and possibly the dll name as well to
   > avoid any compatibility issues.
   
   And a prototype in libpq-fe.h wouldn't hurt either... And a macro, to 
   enable distinguishing md5-enabled libpq versions from older versions.
   
   
   Regards,
   Andreas
   
   

3. Re: [pgadmin-hackers] Client-side password encryption

   Peter Eisentraut <peter_e@gmx.net> — 2005-12-19T01:32:39Z

   Andreas Pflug wrote:
   > Dave Page wrote:
   > > So did you just rip it from there into psql? I don't see it in the
   > > list of libpq exports so if thats not the case, on Windows at least
   > > we'll need to change the api, and possibly the dll name as well to
   > > avoid any compatibility issues.
   > 
   > And a prototype in libpq-fe.h wouldn't hurt either... And a macro, to 
   > enable distinguishing md5-enabled libpq versions from older versions.
   
   So it appears that pg_md5_encrypt is not officially exported from libpq.  
   Does anyone see a problem with adding it to the export list and the 
   header file?
   
   -- 
   Peter Eisentraut
   http://developer.postgresql.org/~petere/
   
   

4. Re: [pgadmin-hackers] Client-side password encryption

   Christopher Kings-Lynne <chriskl@familyhealth.com.au> — 2005-12-19T05:20:40Z

   > So it appears that pg_md5_encrypt is not officially exported from libpq.  
   > Does anyone see a problem with adding it to the export list and the 
   > header file?
   
   Is it different to normal md5?  How is this helpful to the phpPgAdmin 
   project?
   
   Chris
   
   
   

5. Re: [pgadmin-hackers] Client-side password encryption

   Tom Lane <tgl@sss.pgh.pa.us> — 2005-12-19T05:37:22Z

   Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes:
   >> So it appears that pg_md5_encrypt is not officially exported from libpq.  
   >> Does anyone see a problem with adding it to the export list and the 
   >> header file?
   
   > Is it different to normal md5?  How is this helpful to the phpPgAdmin 
   > project?
   
   It would be better to export an API that is (a) less random (why one
   input null-terminated and the other not?) and (b) less tightly tied
   to MD5 --- the fact that the caller knows how long the result must be
   is the main problem here.
   
   Something like
   	char *pg_gen_encrypted_passwd(const char *passwd, const char *user)
   with malloc'd result (or NULL on failure) seems more future-proof.
   
   			regards, tom lane
   
   

6. Re: [pgadmin-hackers] Client-side password encryption

   Andrew Dunstan <andrew@dunslane.net> — 2005-12-19T18:00:10Z

   Peter Eisentraut said:
   
   >
   > So it appears that pg_md5_encrypt is not officially exported from
   > libpq.   Does anyone see a problem with adding it to the export list
   > and the  header file?
   >
   
   
   Well, these changes have broken the windows build, so something needs to
   change.I don't see a reason in principle not to expose our routine, given
   that its name means it is unlikely to conflict with anything else.
   
   cheers
   
   andrew
   
   
   
   

7. Re: [pgadmin-hackers] Client-side password encryption

   Andrew Dunstan <andrew@dunslane.net> — 2005-12-22T23:49:17Z

   
   Tom Lane wrote:
   
   >Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes:
   >  
   >
   >>>So it appears that pg_md5_encrypt is not officially exported from libpq.  
   >>>Does anyone see a problem with adding it to the export list and the 
   >>>header file?
   >>>      
   >>>
   >
   >  
   >
   >>Is it different to normal md5?  How is this helpful to the phpPgAdmin 
   >>project?
   >>    
   >>
   >
   >It would be better to export an API that is (a) less random (why one
   >input null-terminated and the other not?) and (b) less tightly tied
   >to MD5 --- the fact that the caller knows how long the result must be
   >is the main problem here.
   >
   >Something like
   >	char *pg_gen_encrypted_passwd(const char *passwd, const char *user)
   >with malloc'd result (or NULL on failure) seems more future-proof.
   >
   >
   >  
   >
   
   Where are we on this? In general I agree with Tom, but I have no time to 
   do the work. Unless someone has an immediate implementation, I suggest 
   that pro tem we add pg_md5_encrypt to src/interfaces/libpq/exports.txt, 
   which is the minimum needed to unbreak Windows builds, while this gets 
   sorted out properly.
   
   cheers
   
   andrew
   
   

8. Re: [pgadmin-hackers] Client-side password encryption

   Tom Lane <tgl@sss.pgh.pa.us> — 2005-12-22T23:53:12Z

   Andrew Dunstan <andrew@dunslane.net> writes:
   > Where are we on this? In general I agree with Tom, but I have no time to 
   > do the work. Unless someone has an immediate implementation, I suggest 
   > that pro tem we add pg_md5_encrypt to src/interfaces/libpq/exports.txt, 
   > which is the minimum needed to unbreak Windows builds, while this gets 
   > sorted out properly.
   
   I had forgotten that the Windows build is broken.  I'll see what I can
   do with throwing together the cleaner-API function.
   
   			regards, tom lane
   
   

9. Re: [pgadmin-hackers] Client-side password encryption

   Tom Lane <tgl@sss.pgh.pa.us> — 2005-12-23T01:21:54Z

   I wrote:
   > I had forgotten that the Windows build is broken.  I'll see what I can
   > do with throwing together the cleaner-API function.
   
   Done, but I noticed that the change to createuser has arguably broken
   it; at least we need to change the docs.  To wit, the docs say
   
   -E
   --encrypted
        Encrypts the user's password stored in the database. If not
        specified, the default password behavior is used.
   
   -N
   --unencrypted
        Does not encrypt the user's password stored in the database. If not
        specified, the default password behavior is used.
   
   As currently coded, however, the behavior when neither switch is given
   is to force the password to be encrypted --- the database's
   password_encryption setting is overridden.
   
   I'm not sure we can do much about this --- certainly we don't want the
   default behavior of createuser to still be to send an unencrypted
   password.  But if we leave the code as-is the docs need a change.
   
   			regards, tom lane
   
   

10. Re: [pgadmin-hackers] Client-side password encryption

    Christopher Kings-Lynne <chriskl@familyhealth.com.au> — 2005-12-23T02:06:24Z

    >>Where are we on this? In general I agree with Tom, but I have no time to 
    >>do the work. Unless someone has an immediate implementation, I suggest 
    >>that pro tem we add pg_md5_encrypt to src/interfaces/libpq/exports.txt, 
    >>which is the minimum needed to unbreak Windows builds, while this gets 
    >>sorted out properly.
    > 
    > 
    > I had forgotten that the Windows build is broken.  I'll see what I can
    > do with throwing together the cleaner-API function.
    
    Another question about these encrypted passwords.  phpPgAdmin needs to 
    connect to databases that are sometimes on other servers.
    
    I use the pg_connect() function to do this.  This is passed down to 
    PQconenct() I presume.
    
    So, can I specify the password to pg_connect() as 
    'md5127349123742342344234'?
    
    ie. Can I CONNECT using an md5'd password?
    
    Also, does this work for non-md5 host lines on the server, and how can I 
    avoid doing it on older (pre-7.2) PostgreSQL??
    
    Chris
    
    
    

11. Re: [pgadmin-hackers] Client-side password encryption

    Tom Lane <tgl@sss.pgh.pa.us> — 2005-12-23T04:13:07Z

    Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes:
    > So, can I specify the password to pg_connect() as 
    > 'md5127349123742342344234'?
    
    Certainly not.  We'd hardly be worrying about obscuring the original
    password if the encrypted version were enough to get in with.
    
    			regards, tom lane
    
    

12. Re: [pgadmin-hackers] Client-side password encryption

    Christopher Kings-Lynne <chriskl@familyhealth.com.au> — 2005-12-23T05:19:31Z

    >>So, can I specify the password to pg_connect() as 
    >>'md5127349123742342344234'?
    > 
    > Certainly not.  We'd hardly be worrying about obscuring the original
    > password if the encrypted version were enough to get in with.
    
    AndrewSN can't post at the moment, but asked me to post this for him:
    
    "Knowing the md5 hash is enough to authenticate via the 'md5' method in 
    pg_hba.conf, even if you don't know the original password. Admittedly 
    you have to modify libpq to do this, but this isn't going to stop an 
    attacker for more than 5 seconds."
    
    I'll add my own note that never sending the cleartext password does not 
    necessarily improve PostgreSQL security, but certainly stops someone who 
    sniffs the password from then using that cleartext password to get into 
    other applications.  If all they can get is the md5 hash, then all they 
    can get into is PostgreSQL.
    
    Chris
    
    
    

13. Re: [pgadmin-hackers] Client-side password encryption

    Tom Lane <tgl@sss.pgh.pa.us> — 2005-12-23T05:39:51Z

    Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes:
    > AndrewSN can't post at the moment, but asked me to post this for him:
    > "Knowing the md5 hash is enough to authenticate via the 'md5' method in 
    > pg_hba.conf, even if you don't know the original password.
    
    If you know the md5 hash, you know everything the postmaster does, so
    it's hard to see where such an attacker is going to be stopped.  The
    entire point here is not to expose the cleartext password, and that
    really has nothing to do with whether you're going to break into the
    PG database.  It's about protecting users who are foolish enough to
    use the same cleartext password for multiple services.
    
    			regards, tom lane
    
    

14. Re: [pgadmin-hackers] Client-side password encryption

    Greg Stark <gsstark@mit.edu> — 2005-12-23T14:12:52Z

    Tom Lane <tgl@sss.pgh.pa.us> writes:
    
    > Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes:
    > > AndrewSN can't post at the moment, but asked me to post this for him:
    > > "Knowing the md5 hash is enough to authenticate via the 'md5' method in 
    > > pg_hba.conf, even if you don't know the original password.
    > 
    > If you know the md5 hash, you know everything the postmaster does, so
    > it's hard to see where such an attacker is going to be stopped.  
    
    Eh? Just because you know everything the postmaster does doesn't mean you
    can't be stopped. In the traditional unix password file scheme the crypt
    string is public knowledge but it's not enough to log in. You need the
    original password that crypts to that value.
    
    > The entire point here is not to expose the cleartext password, and that
    > really has nothing to do with whether you're going to break into the PG
    > database. It's about protecting users who are foolish enough to use the same
    > cleartext password for multiple services.
    
    Well that's a fine goal but it's not as good as an authentication scheme that
    doesn't store a password equivalent in the database.
    
    
    -- 
    greg
    
    
    

15. Re: [pgadmin-hackers] Client-side password encryption

    Martijn van Oosterhout <kleptog@svana.org> — 2005-12-23T14:27:58Z

    On Fri, Dec 23, 2005 at 09:12:52AM -0500, Greg Stark wrote:
    > Eh? Just because you know everything the postmaster does doesn't mean you
    > can't be stopped. In the traditional unix password file scheme the crypt
    > string is public knowledge but it's not enough to log in. You need the
    > original password that crypts to that value.
    
    This isn't the first time this has been explained, but:
    
    With password encryption you essentially have two options:
    
    - Server knows password, use challenge-response authentication so
    password is not visible on wire.
    - Server only knows hash of password, password must be sent in clear
    over wire.
    
    These exist in the real world as PAP or CHAP, but there are many other
    examples. The reason it works in UNIX login is that the "in-the-clear"
    transit of the password is from the keyboard, via the kernel to a
    single process, not over a network, so it is considered secure. The
    login protocol for SMB has a similar flaw. If you can read the password
    file on an SMB server, you can login as any user. You may have to hack
    a client to make it work, but it is possible.
    
    PostgreSQL uses a variation where the cleartext password sent is just
    the md5 hash of the real password. It just stops the admin guessing it
    to see if the user is using it elsewhere. You really don't need the
    original password to login, just the hash.
    
    The solution is obvious, public-key authentication which doesn't have
    these problems. eg SSH, SSL, etc... Or a trusted third party (ident).
    
    Have a nice day,
    
    -- 
    Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
    > Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
    > tool for doing 5% of the work and then sitting around waiting for someone
    > else to do the other 95% so you can sue them.
    

16. Re: [pgadmin-hackers] Client-side password encryption

    Stephen Frost <sfrost@snowman.net> — 2005-12-23T14:42:44Z

    * Martijn van Oosterhout (kleptog@svana.org) wrote:
    > On Fri, Dec 23, 2005 at 09:12:52AM -0500, Greg Stark wrote:
    > > Eh? Just because you know everything the postmaster does doesn't mean you
    > > can't be stopped. In the traditional unix password file scheme the crypt
    > > string is public knowledge but it's not enough to log in. You need the
    > > original password that crypts to that value.
    > 
    > This isn't the first time this has been explained, but:
    > 
    > With password encryption you essentially have two options:
    > 
    > - Server knows password, use challenge-response authentication so
    > password is not visible on wire.
    > - Server only knows hash of password, password must be sent in clear
    > over wire.
    
    Erm, Postgres isn't doing either of these...?  You even talk about what
    Postgres does below so I'm kind of bemused that you don't mention it in
    your list... :)
    
    > These exist in the real world as PAP or CHAP, but there are many other
    > examples. The reason it works in UNIX login is that the "in-the-clear"
    > transit of the password is from the keyboard, via the kernel to a
    > single process, not over a network, so it is considered secure. The
    > login protocol for SMB has a similar flaw. If you can read the password
    > file on an SMB server, you can login as any user. You may have to hack
    > a client to make it work, but it is possible.
    
    Well, and these days quite often the network connection is encrypted.
    
    > PostgreSQL uses a variation where the cleartext password sent is just
    > the md5 hash of the real password. It just stops the admin guessing it
    > to see if the user is using it elsewhere. You really don't need the
    > original password to login, just the hash.
    
    Stops the admin from guessing the password, but makes the text on the
    disk *the* authentication token, meaning someone who manages to get a 
    copy of the password file gets full access to the system.
    
    > The solution is obvious, public-key authentication which doesn't have
    > these problems. eg SSH, SSL, etc... Or a trusted third party (ident).
    
    There's also Kerberos, which I'm happy to say seems to be getting more
    and more use.  I'd really like to get ODBC Kerberos working, at least
    with MIT kerberos and then maybe someday (if I can manage to get it
    working...) setup some cross-realm stuff with the Windows AD and SSPI
    (iirc) things and have ODBC use that to authenticate against my
    Linux-based PostgreSQL server.
    
    I guess to do that we'd have to make libpq under Windows have the option
    of using the Windows SSPI layer.  Anyone looked into this at all?
    Anyone know if it'd have a chance of getting accepted?
    
    	Thanks,
    
    		Stephen
    

17. Re: [pgadmin-hackers] Client-side password encryption

    Marko Kreen <markokr@gmail.com> — 2005-12-23T15:08:12Z

    On 23 Dec 2005 09:12:52 -0500, Greg Stark <gsstark@mit.edu> wrote:
    >
    > Tom Lane <tgl@sss.pgh.pa.us> writes:
    >
    > > Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes:
    > > > AndrewSN can't post at the moment, but asked me to post this for him:
    > > > "Knowing the md5 hash is enough to authenticate via the 'md5' method in
    > > > pg_hba.conf, even if you don't know the original password.
    > >
    > > If you know the md5 hash, you know everything the postmaster does, so
    > > it's hard to see where such an attacker is going to be stopped.
    >
    > Eh? Just because you know everything the postmaster does doesn't mean you
    > can't be stopped. In the traditional unix password file scheme the crypt
    > string is public knowledge but it's not enough to log in. You need the
    > original password that crypts to that value.
    
    In unix scheme the cleartext password is send over wire and server
    stores hash.  So indeed even if you know the hash, it wont get you in.
    
    But current postgres case the md5 is sent over wire and also stored
    in server.  So knowing md5 is enough to get in.  The md5 is only used
    to obfuscate the cleartext password from administrators, in case
    the user uses it somewhere else too.
    
    (And the reason for current md5 hacking is to avoid the cleartext
    password from appearing from logs, thus overall rounding the goal.)
    
    > > The entire point here is not to expose the cleartext password, and that
    > > really has nothing to do with whether you're going to break into the PG
    > > database. It's about protecting users who are foolish enough to use the same
    > > cleartext password for multiple services.
    >
    > Well that's a fine goal but it's not as good as an authentication scheme that
    > doesn't store a password equivalent in the database.
    
    http://srp.stanford.edu/whatisit.html
    
    --
    marko
    

18. Re: [pgadmin-hackers] Client-side password encryption

    Martijn van Oosterhout <kleptog@svana.org> — 2005-12-23T15:24:11Z

    On Fri, Dec 23, 2005 at 09:42:44AM -0500, Stephen Frost wrote:
    > * Martijn van Oosterhout (kleptog@svana.org) wrote:
    > > This isn't the first time this has been explained, but:
    > > 
    > > With password encryption you essentially have two options:
    > > 
    > > - Server knows password, use challenge-response authentication so
    > > password is not visible on wire.
    > > - Server only knows hash of password, password must be sent in clear
    > > over wire.
    > 
    > Erm, Postgres isn't doing either of these...?  You even talk about what
    > Postgres does below so I'm kind of bemused that you don't mention it in
    > your list... :)
    
    Postgres *is* using one of these, the first one, where the server knows
    the authentication token (the md5 hash of the password). UNIX login
    uses the latter. Perhaps if you substitute "authentication token" for
    "password" above it makes it clearer?
    
    > Well, and these days quite often the network connection is encrypted.
    
    If you use SSL or SSH? Sure. I think in that case you can setup
    pg_hba.conf to require "password" in which case the server will only
    accept an unhashed password.
    
    > Stops the admin from guessing the password, but makes the text on the
    > disk *the* authentication token, meaning someone who manages to get a 
    > copy of the password file gets full access to the system.
    
    If md5 auth is setup, yes.
    
    > There's also Kerberos, which I'm happy to say seems to be getting more
    > and more use.  I'd really like to get ODBC Kerberos working, at least
    > with MIT kerberos and then maybe someday (if I can manage to get it
    > working...) setup some cross-realm stuff with the Windows AD and SSPI
    > (iirc) things and have ODBC use that to authenticate against my
    > Linux-based PostgreSQL server.
    
    Yeah, I was counting kerberos under "trust a third party". It shouldn't
    be too hard to add other such systems, like PAM has been...
    
    Have a nice day,
    -- 
    Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
    > Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
    > tool for doing 5% of the work and then sitting around waiting for someone
    > else to do the other 95% so you can sue them.
    

19. Re: [pgadmin-hackers] Client-side password encryption

    Stephen Frost <sfrost@snowman.net> — 2005-12-23T15:55:00Z

    * Martijn van Oosterhout (kleptog@svana.org) wrote:
    > On Fri, Dec 23, 2005 at 09:42:44AM -0500, Stephen Frost wrote:
    > > * Martijn van Oosterhout (kleptog@svana.org) wrote:
    > > > This isn't the first time this has been explained, but:
    > > > 
    > > > With password encryption you essentially have two options:
    > > > 
    > > > - Server knows password, use challenge-response authentication so
    > > > password is not visible on wire.
    > > > - Server only knows hash of password, password must be sent in clear
    > > > over wire.
    > > 
    > > Erm, Postgres isn't doing either of these...?  You even talk about what
    > > Postgres does below so I'm kind of bemused that you don't mention it in
    > > your list... :)
    > 
    > Postgres *is* using one of these, the first one, where the server knows
    > the authentication token (the md5 hash of the password). UNIX login
    > uses the latter. Perhaps if you substitute "authentication token" for
    > "password" above it makes it clearer?
    
    Is it actually doing challenge-response where the challenge is different
    each time?  I thought it just used the user's username or some such.
    Point being- can an attacker use what's passed around on the network to
    authenticate to the system directly?  If it's a random
    challenge/response setup then they shouldn't be able to unless they
    manage to convince the server to give it the same challenge (which
    should be very difficult).
    
    > > Well, and these days quite often the network connection is encrypted.
    > 
    > If you use SSL or SSH? Sure. I think in that case you can setup
    > pg_hba.conf to require "password" in which case the server will only
    > accept an unhashed password.
    
    Yeah, but you can't do both, which is the real annoyence.  You can't get
    it to do the same as unix-based auth.
    
    > > Stops the admin from guessing the password, but makes the text on the
    > > disk *the* authentication token, meaning someone who manages to get a 
    > > copy of the password file gets full access to the system.
    > 
    > If md5 auth is setup, yes.
    
    Yeah, but the other alternative is clear-text passwords on the disk, not
    something I really care for either, honestly.
    
    > > There's also Kerberos, which I'm happy to say seems to be getting more
    > > and more use.  I'd really like to get ODBC Kerberos working, at least
    > > with MIT kerberos and then maybe someday (if I can manage to get it
    > > working...) setup some cross-realm stuff with the Windows AD and SSPI
    > > (iirc) things and have ODBC use that to authenticate against my
    > > Linux-based PostgreSQL server.
    > 
    > Yeah, I was counting kerberos under "trust a third party". It shouldn't
    > be too hard to add other such systems, like PAM has been...
    
    I don't know that I'd consider PAM under Postgres as really being PAM.
    It's *only* password-checking, and there's the issue that Postgres
    doesn't have a root process to do the PAM work under so the postgres
    user has to be in shadow (which means all the Postgres processes can
    read /etc/shadow, not exactly a nice setup) to have PAM work.  Perhaps
    SASL and saslauthd could be an option for Postgres.  I'm not sure though
    as I don't think the Postgres protocol currently supports the kind of
    back-and-forth that both PAM and SASL want to be able to do for things
    like password-expring, forced-password-changes, etc.
    
    	Thanks,
    
    		Stephen
    

20. Re: [pgadmin-hackers] Client-side password encryption

    Andrew Dunstan <andrew@dunslane.net> — 2005-12-23T16:16:31Z

    
    Stephen Frost wrote:
    
    >Is it actually doing challenge-response where the challenge is different
    >each time?  
    >
    
    
    The docs say:
    
    AuthenticationMD5Password
    
        The frontend must now send a PasswordMessage containing the password
        encrypted via MD5, using the 4-character salt specified in the
        AuthenticationMD5Password message. If this is the correct password,
        the server responds with an AuthenticationOk, otherwise it responds
        with an ErrorResponse.
    
    
    
    A little investigation reveals that this is port->md5salt which is 4 
    random bytes set up fresh per connection (see src/backend/libpq/auth.c 
    and src/backend/postmaster/postmaster.c). So it seems indeed to be a 
    true (small) one time challenge token, unless I've missed something.
    
    cheers
    
    andrew