Thread

  1. Re: Encrypting pg_shadow passwords

    Jim Mercer <jim@reptiles.org> — 2001-06-26T04:12:46Z

    On Tue, Jun 26, 2001 at 12:00:35AM -0400, Bruce Momjian wrote:
    > One good point you have is what do we do with 'password' authentication
    > once we encrypt pg_shadow.  My guess is that we just disallow it.  It is
    > insecure and was only there for clients that couldn't do crypt.  They
    > all have that now.  It should just go away.  We kept it around for the
    > secondary password file but those secondary password files are the same
    > once pg_shadow is encrypted.
    
    i would be content if the API allowed me to pass it a plain-text password,
    and that was compared against pg_shadow, where the password is stored
    encrypted.
    
    at this point in time, i do not see a method of doing that without my mods
    or using external password files.
    
    if the API as above existed, then i would be happy to see "password" go away
    (although it should be depreciated to a --enable option, otherwise you are
    going to ruin a bunch of existing code).
    
    > One item of my plan is that you can encrypt individual users.  You don't
    > have to do them all at once in case you have older clients for some
    > users but not others.
    
    it would be nice (in my opinion) if you could have multiple (cascade) entries
    in pg_hba.conf.
    
    and a flag in pg_shadow to "appoint" a blessed scheme.
    
    ie. if a user identd's ok, and the identd flag is set in pg_shadow, then
    it is ok.  otherwise, move on to the next pg_hba.conf entry.
    
    the reasoning for this is that i (and i assume others) have two classes of
    access.  some type of authenticated client/user and scripts.
    
    hardcoding passwords in scripts is just wrong.
    
    i sometimes have "localhost" set up on ident, and non-localhost on some
    type of passord/crypt type thing.  but i don't want to allow all local users
    access via ident.
    
    i recognize that some of this can be done with the ident mapping facility,
    but again, that is an external file, and thus presents management issues.
    
    -- 
    [ Jim Mercer        jim@reptiles.org         +1 416 410-5633 ]
    [ Now with more and longer words for your reading enjoyment. ]