Thanks for reply. But it's not suitable to trust the people who have access to the logs.
Think, I changed my DB password and other DBA colleague who has access to the PostgreSQL logs has seen my DB password. He started to use my DB password instead of his password. He executed all DDL and DML statements with my DB account. In fact, I did nothing but because of this gap I did all things. Is it a trustable situation ? How will we identify who is guilty he or me? Best Regards Murat KOC 2011/12/19 Guillaume Lelarge <guilla...@lelarge.info> > On Mon, 2011-12-19 at 15:01 +0200, MURAT KOÇ wrote: > > Hi List, > > > > When I try to change my db password like below SQL statement from psql or > > pgAdmin tool, it outputs to server logs as like this: > > > > *postgres=# alter user mkoc password 'dummy'; > > ALTER ROLE > > postgres=# alter user mkoc with password 'dummy'; > > ALTER ROLE > > * > > > > ### Server Logs ### > > 2011-12-19 14:35:31 > > EET--postgres--postgres--[local]--psql--idle--00000LOG: statement: alter > > user mkoc password 'dummy'; > > 2011-12-19 14:35:41 > > EET--postgres--postgres--[local]--psql--idle--00000LOG: statement: alter > > user mkoc with password 'dummy'; > > > > So, an OS user who can access to server log files can read DB users' > > clear-text passwords from these logs. In my opinion, this is a big > security > > gap. > > > > I don't want to see these changing password logs in clear-text. These > > logs must be encrypted passwords instead of clear-text like below: > > > > *Server Logs must be; > > *2011-12-19 14:35:31 > > EET--postgres--postgres--[local]--psql--idle--00000LOG: statement: alter > > user mkoc password *values 'XFADIT9248fDSKFD';* > > ** > > Is it possible to see changing passwords as encrypted? > > Nope. > > > How should I change password or what is the correct sql statement to > change user password? > > > > There's only one way to change a password: ALTER USER... PASSWORD... > > You have to trust the people who have access to the PostgreSQL logs. I > you don't trust them, you should deny access to the logs for them. > > > -- > Guillaume > http://blog.guillaume.lelarge.info > http://www.dalibo.com > PostgreSQL Sessions #3: http://www.postgresql-sessions.org > >
