On 1 Apr 2010, at 11:21, Christophe Dore wrote:
> Thanks for answering
>
> Yes, you are right. This is a client-side file. However, our concern is
> that we have to consider this practice as a security issue. We'd like to
> ban this practice for our product which is, thus, wrapping PostgresQL
> engine. Thus my questions
>
> - is there any configuration that can be done on server side to prevent
> the client side to use such file to read passwords ?
> - is there any options that can be set in postgres libpq C library to
> prevent the connection functions to search for password in files ?
Nothing prevents a user from creating such files, regardless whether the server accepts the information in it or not. I
getthe impression you want to prevent passwords being stored in files on user systems - probably thinking that if such
afile were 'stolen' then someone could access your database and possibly modify things.
Although this is basically true, there is no way you can prevent users from storing passwords on their computers. If
they'renot put in .pgpass files there will be users who store them unencrypted in text files conveniently named
'passwords'in their home directories. They'll probably do that anyway.
From the server side there's nothing you can do about that, so not accepting data from .pgpass files will hardly help
you.
I have to say I was a bit surprised to find that .pgpass files store those passwords as plain text though. Some method
likessh uses with public and private keys would be an improvement IMO. Especially since we can choose to use password
encryptionover the wire.
Storing those passwords encrypted on the client side seems the proper way to deal with this issue. IMHO, time working
onthat is better spent than time trying to prevent .pgpass files from working.
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,4bb47e3510419564511622!