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 al
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 creat
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
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 wi
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 re
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, ra
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
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 serv
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 th
Bruce Momjian 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
> things? It hides t
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 secur
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 lo
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 passwo
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,
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 ac
Bruce Momjian 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 query if the administr
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
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
"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
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 submi
20 matches
Mail list logo
