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
19 matches
Mail list logo
