Peter Eisentraut wrote:
Letting createuser.c hash the password would be the biggest win.
Both of these things are now done, and I have sent notices to pgadmin
and phppgadmin asking for equivalent adjustments.
Um, didn't receive a notice.
I'm a little uncomfortable using an arbitrary md5
Marko Kreen wrote:
Maybe we should provide a backslash command in psql for secure
password entry, say, \password [username]. This would then ask for
the password through a somewhat secure, unlogged channel, encrypt
it, and send an ALTER ROLE command to the server.
Letting createuser.c
Dear friends,
I thank you for all replies.
If you permit, I'd like to present my modest view of the problem.
I agree with Tom when he says:
... if the user wishes the password to be secure, he
needs to encrypt it on the client side. Anything else is
just the illusion of security.
and with
On 12/9/05, Peter Eisentraut [EMAIL PROTECTED] wrote:
Tom Lane wrote:
As I said already, if the user wishes the password to be secure, he
needs to encrypt it on the client side.
Maybe we should provide a backslash command in psql for secure password
entry, say, \password [username]. This
On Fri, 2005-12-09 at 19:41 +0100, Peter Eisentraut wrote:
Tom Lane wrote:
As I said already, if the user wishes the password to be secure, he
needs to encrypt it on the client side.
Maybe we should provide a backslash command in psql
That is a good option, but not the only option
Simon Riggs [EMAIL PROTECTED] writes:
On Fri, 2005-12-09 at 19:41 +0100, Peter Eisentraut wrote:
Maybe we should provide a backslash command in psql
That is a good option, but not the only option required.
There are many reasons to need to supply the password as part of a
command, rather
On Sat, 2005-12-10 at 11:15 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Fri, 2005-12-09 at 19:41 +0100, Peter Eisentraut wrote:
Maybe we should provide a backslash command in psql
That is a good option, but not the only option required.
There are many reasons to
Title: Log of CREATE USER statement
Hi,
I need to log any statement in my postgresql server.
However, I would like that the password defined in CREATE USER statement was registered in MD5 format, independent of the form as it was specified in that statement.
For example, if the user
Ricardo Vaz - TCESP [EMAIL PROTECTED] writes:
However, I would like that the password defined in CREATE USER statement
was registered in MD5 format, independent of the form as it was
specified in that statement.
Not going to happen --- we are not going to add that sort of analysis to
the
Tom Lane wrote:
Ricardo Vaz - TCESP [EMAIL PROTECTED] writes:
However, I would like that the password defined in CREATE USER statement
was registered in MD5 format, independent of the form as it was
specified in that statement.
Not going to happen --- we are not going to add that sort of
Tom Lane wrote:
However, I would like that the password defined in CREATE USER
statement was registered in MD5 format, independent of the form as
it was specified in that statement.
Not going to happen --- we are not going to add that sort of analysis
to the statement logging code, as the
Bruce Momjian pgman@candle.pha.pa.us writes:
One issue I have not heard is that CREATE USER, with the visible
password, is sent over the wire in cleartext, and does appear in the
logs, as we discussed, so while we MD5 the password in pg_shadow so
administrators do not see it, we do log the
Peter Eisentraut [EMAIL PROTECTED] writes:
Users who choose a password
should have the assurance that the password cannot be seen in
plain-text by anyone anywhere. In a PostgreSQL system, the password
can be seen in all kinds of places, like the psql history, the server
log, the activity
Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Users who choose a password
should have the assurance that the password cannot be seen in
plain-text by anyone anywhere. In a PostgreSQL system, the password
can be seen in all kinds of places, like the psql history, the
On Fri, 2005-12-09 at 13:03 -0500, Bruce Momjian wrote:
Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Users who choose a password
should have the assurance that the password cannot be seen in
plain-text by anyone anywhere. In a PostgreSQL system, the password
can be
Tom Lane wrote:
To put that more clearly: if the point is to keep the user's
cleartext password out of the hands of the DBA, then the user has
already blown it by sending the password in cleartext in the first
place. An untrustworthy DBA could trivially insert code into CREATE
USER to log
Tom Lane wrote:
As I said already, if the user wishes the password to be secure, he
needs to encrypt it on the client side.
Maybe we should provide a backslash command in psql for secure password
entry, say, \password [username]. This would then ask for the password
through a somewhat
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom Lane wrote:
As I said already, if the user wishes the password to be secure, he
needs to encrypt it on the client side. Anything else is just the
illusion of security.
Thinking some more, does encoding on the client side really improve
Peter Eisentraut wrote:
Tom Lane wrote:
As I said already, if the user wishes the password to be secure, he
needs to encrypt it on the client side.
Maybe we should provide a backslash command in psql for secure password
entry, say, \password [username]. This would then ask for the
Peter Eisentraut [EMAIL PROTECTED] writes:
Maybe we should provide a backslash command in psql for secure password
entry, say, \password [username]. This would then ask for the password
through a somewhat secure, unlogged channel, encrypt it, and send an
ALTER ROLE command to the server.
20 matches
Mail list logo
