On 10/14/2009 12:25 PM, Tom Lane wrote:
Let's see you do that (hint: "CREATD USER ... PASSWORD" is going to
throw a syntax error before you realize there's anything there that
might need to be protected).
And you ignored the question of insecure transmission pathways, anyway.
By the time the backend has figured out that it's got a CREATE USER
... PASSWORD command, it's already way too late if the client sent it
over a non-SSL connection.
It seems like the architectural problem here is that people think of SQL
as being a valid way to change one's password.
I never thought it was valid?
What if, like "createdb", or "createuser", there was a "pgpasswd" that
did all of the appropriate checks and provided the proper security (MD5
today?) during transit and when storing to a log file? "createuser"
already does password prompting - maybe it should allow checking the
password from the "createuser" client side?
I think if we looked at the SQL commands as being a 'base operation not
intended for everyday users', this entire debate would seem frivolous? :-)
Does Oracle really do password checks on the base SQL commands used to
change an Oracle password? That sounds silly.
I'm totally on Tom's side. Having the server check passwords is the
wrong solution to the problem. It makes things worse - not better. That
they're approving a plugin capability on the server at all is generous,
as it does lead to a sense of protection that may not be justifiable.
Cheers,
mark
--
Mark Mielke<m...@mielke.cc>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
