Albe Laurenz laurenz.a...@wien.gv.at writes:
I did not know that contrib modules get translated too, else I would
have thrown the error messages there.
I'm not sure whether contrib is currently covered by the translation
teams, but it could someday be. In any case, an inadequate error
message
Itagaki Takahiro wrote:
Looks good. I change status of the patch to Ready for Committer.
Thanks for the help!
BTW, it might not be a work for this patch, we also need to
reject too long VALID UNTIL setting. If the password is
complex, we should not use the same password for a long time.
Itagaki Takahiro itagaki.takah...@oss.ntt.co.jp writes:
BTW, it might not be a work for this patch, we also need to
reject too long VALID UNTIL setting. If the password is
complex, we should not use the same password for a long time.
This is a good point --- people who have password strength
Itagaki Takahiro itagaki.takah...@oss.ntt.co.jp writes:
Albe Laurenz laurenz.a...@wien.gv.at wrote:
I agree on the second point, and I changed the patch accordingly.
Here's the latest version.
Looks good. I change status of the patch to Ready for Committer.
Applied with some minor
Tom Lane wrote:
Applied with some minor modifications. Aside from the added valuntil
parameter, I changed the isencrypted parameter to an int with some
#define'd values. It seems easily foreseeable that we'll replace the
MD5 encryption scheme someday, and it'd be good to ensure that this
Itagaki Takahiro wrote:
I've reviewed your patch. The rough approach looks fine,
but I have some comments about function declarations and coding style.
Thank you for taking the time!
I think I addressed all the shortcomings you mentioned with
the attached patches. I fixed the { alignment; I am
I think it would better to add an explicit isencrypted parameter to
the check_password_hook function, rather than require the module to do
isMD5 on the password. Any imaginable check hook will need to know if
the password is in MD5 format, and the backend already knows it (because
it already did
Heikki Linnakangas wrote:
I think it would better to add an explicit isencrypted parameter to
the check_password_hook function, rather than require the module to do
isMD5 on the password. Any imaginable check hook will need to know if
the password is in MD5 format, and the backend already
Albe Laurenz laurenz.a...@wien.gv.at wrote:
Heikki Linnakangas wrote:
I think it would better to add an explicit isencrypted parameter to
the check_password_hook function, rather than require the module to do
isMD5 on the password.
I agree on the second point, and I changed the patch
Albe Laurenz laurenz.a...@wien.gv.at wrote:
I wrote:
Following the discussions in
http://archives.postgresql.org/pgsql-hackers/2009-09/msg01766.php
and
http://archives.postgresql.org/pgsql-hackers/2009-10/msg00025.php ,
here are patches for
a) a hook in backend/commands/user.c
2009/10/19 Tom Lane t...@sss.pgh.pa.us:
I wrote:
A server-side plugin can provide a guarantee that there are no bad
passwords (for some value of bad, and with some possible adverse
consequences). We don't have that today.
BTW, it strikes me that ALTER USER RENAME introduces an interesting
Magnus Hagander mag...@hagander.net writes:
2009/10/19 Tom Lane t...@sss.pgh.pa.us:
Now we have a user with name equal to password, which no sane security
policy will think is a good thing, but the plugin had no chance to
prevent it.
The big difference is that you need to be superuser to
On Tue, Oct 20, 2009 at 9:42 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
2009/10/19 Tom Lane t...@sss.pgh.pa.us:
Now we have a user with name equal to password, which no sane security
policy will think is a good thing, but the plugin had no chance to
Bruce Momjian wrote:
Great, added to TODO:
Allow server-side enforcement of password policies
Password checks might include password complexity or non-reuse of
passwords. This facility will require the client to send the password to
the server in
On Thu, 2009-10-15 at 13:19 -0400, Robert Haas wrote:
But I don't understand why everyone is
so worked up about having an *optional* *flag* to force plaintext
instead of MD5.
It would be pretty bad usability. Users would be faced with the choice:
you can have secure authentication or good
On Mon, 2009-10-19 at 09:14 +0200, Albe Laurenz wrote:
Bruce Momjian wrote:
Great, added to TODO:
Allow server-side enforcement of password policies
Password checks might include password complexity or non-reuse of
passwords. This facility will require the client
Peter Eisentraut wrote:
I don't get why you need 'password' authentication for that.
The point where the password should be checked is not when
the user uses it to logon, but when he or she changes it.
So in my opinion that should be:
This facility will require to send new and changed
On Mon, Oct 19, 2009 at 7:34 AM, Peter Eisentraut pete...@gmx.net wrote:
On Thu, 2009-10-15 at 13:19 -0400, Robert Haas wrote:
But I don't understand why everyone is
so worked up about having an *optional* *flag* to force plaintext
instead of MD5.
It would be pretty bad usability. Users
Albe Laurenz laurenz.a...@wien.gv.at writes:
Bruce Momjian wrote:
Password checks might include password complexity or non-reuse of
passwords. This facility will require the client to send the password to
the server in plain-text, so SSL and 'password' authentication is
necessary to use this
On Mon, 2009-10-19 at 14:54 +0200, Albe Laurenz wrote:
Peter Eisentraut wrote:
Note that this solution will still not satisfy the original checkbox
requirement.
I guess I misunderstood something there, but I had assumed that the
checkbox item read something like: Does the product offer
Peter Eisentraut pete...@gmx.net writes:
On Mon, 2009-10-19 at 14:54 +0200, Albe Laurenz wrote:
I guess I misunderstood something there, but I had assumed that the
checkbox item read something like: Does the product offer password
policy enforcement? (to quote Dave Page).
The answer to that
Tom Lane escribió:
Peter Eisentraut pete...@gmx.net writes:
On Mon, 2009-10-19 at 14:54 +0200, Albe Laurenz wrote:
I guess I misunderstood something there, but I had assumed that the
checkbox item read something like: Does the product offer password
policy enforcement? (to quote Dave
Alvaro Herrera wrote:
Except that your first statement is false. It is not possible currently
for any tool to prevent someone from doing ALTER USER joe PASSWORD joe.
A server-side plugin can provide a guarantee that there are no bad
passwords (for some value of bad, and with some possible
I wrote:
A server-side plugin can provide a guarantee that there are no bad
passwords (for some value of bad, and with some possible adverse
consequences). We don't have that today.
BTW, it strikes me that ALTER USER RENAME introduces an interesting
hazard for such a plugin. Consider
CREATE
Andrew Dunstan and...@dunslane.net writes:
Alvaro Herrera wrote:
We do, if you have you server grabbing passwords from LDAP or whatever
external auth service you use. That would be more secure than anything
mentioned in this thread, because the password enforcement could work on
unencrypted
Tom Lane wrote:
Albe Laurenz laurenz.a...@wien.gv.at writes:
Bruce Momjian wrote:
Password checks might include password complexity or non-reuse of
passwords. This facility will require the client to send the password to
the server in plain-text, so SSL and 'password' authentication is
Bruce Momjian wrote:
Yep, this is illustrating something that is pretty basic to open source
--- that is open source often provides the tools for a solution, rather
than a complete solution. I often think of open source as providing a
calculator with wires sticking out, rather than calculator
Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
If we were using some kind of real public key system and someone
suggested breaking it to add password complexity checking, I would
understand the outrage here. But I don't understand why everyone is
so worked up about having an
Dave Page wrote:
Too many of those caveats, and it's easy to see how we can be
discounted early in the evaluation phase. It's not helped that often
these lists will be drawn up by people used to working with the
commercial DBMSs, so we probably wouldn't get extra points for having
a dozen
Bruce Momjian br...@momjian.us writes:
So, are we agreed to provide a hook on the server side, but to use it
you have to configure your system with SSL and 'password'? I can add
that to the TODO list.
I think we're agreed to provide the hook. What restrictions the hook
might enforce are not
On 10/16/2009 11:28 AM, Bruce Momjian wrote:
Dave Page wrote:
Too many of those caveats, and it's easy to see how we can be
discounted early in the evaluation phase. It's not helped that often
these lists will be drawn up by people used to working with the
commercial DBMSs, so we probably
On Fri, Oct 16, 2009 at 4:28 PM, Bruce Momjian br...@momjian.us wrote:
Personally I think the calculator/wires approach is better from an
engineering perspective, but it can be a handicap in the user experience
and checkbox categories --- ease of use is perhaps not our strong point.
Much of
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
So, are we agreed to provide a hook on the server side, but to use it
you have to configure your system with SSL and 'password'? I can add
that to the TODO list.
I think we're agreed to provide the hook. What restrictions the hook
Mark Mielke wrote:
Personally I think the calculator/wires approach is better from an
engineering perspective, but it can be a handicap in the user experience
and checkbox categories --- ease of use is perhaps not our strong point.
Much of our open source value is being different, in both
On Wed, Oct 14, 2009 at 11:21 PM, Mark Mielke m...@mark.mielke.cc wrote:
On 10/14/2009 05:33 PM, Dave Page wrote:
No. Any checks at the client are worthless, as they can be bypassed by
10 minutes worth of simple coding in any of a dozen or more languages.
Why care?
Because many large (and
On Wed, Oct 14, 2009 at 11:44 PM, Stephen Frost sfr...@snowman.net wrote:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Peter Eisentraut pete...@gmx.net writes:
Well, you would lose anyway if the DBA switches the pg_hba.conf setting
from md5 to password without telling you.
True :-(. Anybody for
Dave Page dp...@pgadmin.org wrote:
On Wed, Oct 14, 2009 at 10:51 PM, Kevin Grittner
bigger problems, like that slip of paper in their desk drawer with
the password written on it.
See my previous comment about dates. Check-box items aside, I have
absolutely no desire to try to give the
On Thu, Oct 15, 2009 at 2:49 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Dave Page dp...@pgadmin.org wrote:
On Wed, Oct 14, 2009 at 10:51 PM, Kevin Grittner
bigger problems, like that slip of paper in their desk drawer with
the password written on it.
See my previous comment about
Mark Mielke wrote:
Does Oracle really do password checks on the base SQL commands used to
change an Oracle password? That sounds silly.
In Oracle you can write a stored procedure to check passwords;
it is invoked whenever a user is created or altered.
No matter how you change the password,
On 10/15/2009 03:54 AM, Dave Page wrote:
On Wed, Oct 14, 2009 at 11:21 PM, Mark Mielkem...@mark.mielke.cc wrote:
On 10/14/2009 05:33 PM, Dave Page wrote:
No. Any checks at the client are worthless, as they can be bypassed by
10 minutes worth of simple coding in any of a dozen or
On 10/15/2009 10:08 AM, Dave Page wrote:
It's certainly true that there are other ways for users to compromise
their passwords if they want. The fact remains though, that most other
DBMSs (and all major operating systems I can think of) offer password
policy features as non-client checks which
On 10/15/2009 10:38 AM, Albe Laurenz wrote:
Mark Mielke wrote:
Does Oracle really do password checks on the base SQL commands used to
change an Oracle password? That sounds silly.
In Oracle you can write a stored procedure to check passwords;
it is invoked whenever a user is created
On Thu, Oct 15, 2009 at 5:28 PM, Mark Mielke m...@mark.mielke.cc wrote:
Not so clear to me. If they're doing strong checks, this means they're
sending passwords in the clear or only barely encoded, or using some OTHER
method than 'alter role ... password ...' to change the password.
Some are
Mark Mielke wrote:
On 10/15/2009 10:08 AM, Dave Page wrote:
...other
DBMSs (and all major operating systems I can think of) offer password
policy features as non-client checks...we are compared ...
Not so clear to me. If they're doing strong checks, this means they're
sending passwords in
On 10/15/09 9:41 AM, Dave Page wrote:
Sometimes that can be for huge projects, where it is
necessary to justify every difference in check-box items against other
products to get past the early eval stages. Like it or not, that is a
fact, and this hampers our adoption.
Precisely, and I think
On Thu, Oct 15, 2009 at 12:23 PM, Mark Mielke m...@mark.mielke.cc wrote:
You miss my point (and conveniently cut it out). For users who accidentally
break policy vs users who purposefully circumvent policy - the approaches
must be different, and the risk management decision may be different.
Robert Haas robertmh...@gmail.com writes:
If we were using some kind of real public key system and someone
suggested breaking it to add password complexity checking, I would
understand the outrage here. But I don't understand why everyone is
so worked up about having an *optional* *flag* to
On Thu, Oct 15, 2009 at 6:17 PM, Josh Berkus j...@agliodbs.com wrote:
Enabling the inclusion of a password checker in the client *would*
improve things by preventing stupid users from setting their password
the same as their username, or to a 3-letter word, or anything equally
stupid which
On Thu, Oct 15, 2009 at 6:43 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
If we were using some kind of real public key system and someone
suggested breaking it to add password complexity checking, I would
understand the outrage here. But I don't understand
On Thu, Oct 15, 2009 at 1:47 PM, Dave Page dp...@pgadmin.org wrote:
On Thu, Oct 15, 2009 at 6:43 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
If we were using some kind of real public key system and someone
suggested breaking it to add password complexity
On Thu, Oct 15, 2009 at 6:55 PM, Robert Haas robertmh...@gmail.com wrote:
OK, so we're in violent agreement here?
From a technical perspective I think we have been for a while. Though
clearly some people disagree with my assertion that putting any form
of policy enforcement in the client is not
On 10/15/2009 01:44 PM, Dave Page wrote:
I don't deal with prospective clients, which is where this comes from.
I do deal with a team of (pre)sales engineers who complain about this,
and maybe half-a-dozen other issues on a very regular basis. They tell
me that PostgreSQL loses out in early
Dave Page dp...@pgadmin.org writes:
On Thu, Oct 15, 2009 at 6:43 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Yes, and it's an optional flag that could perfectly well be implemented
in the plugin that I think we do have consensus to add a hook for.
The argument is over why do we need to litter the
Dave Page dp...@pgadmin.org writes:
I suppose in the worst case, I could just have pgAdmin throw the
error, and then add a per-server option to disable password hashing in
the relevant places, but I'd far rather have that automated so it
can't be set unnecessarily.
As I commented before, I
On 10/15/2009 02:02 PM, Dave Page wrote:
On Thu, Oct 15, 2009 at 6:55 PM, Robert Haasrobertmh...@gmail.com wrote:
OK, so we're in violent agreement here?
From a technical perspective I think we have been for a while. Though
clearly some people disagree with my assertion that
On Thu, Oct 15, 2009 at 7:22 PM, Mark Mielke m...@mark.mielke.cc wrote:
It depends on what your goal is. If your goal is to treat users as monkeys
that you do not trust, even with their own password, and the DBA as God, who
you absolutely do trust, than you are correct.
I don't know about
Dave Page wrote:
I never said it wasn't - in fact I said from the outset it was about
box-checking, and that anyone doing things properly will use
LDAP/SSPI/Kerberos etc.
I don't understand why the box-checkers can't already check that
box; with the explanation stating Yes - by using LDAP or
On Thu, Oct 15, 2009 at 10:40 PM, Ron Mayer
rm...@cheapcomplexdevices.com wrote:
Dave Page wrote:
I never said it wasn't - in fact I said from the outset it was about
box-checking, and that anyone doing things properly will use
LDAP/SSPI/Kerberos etc.
I don't understand why the box-checkers
On Mon, Sep 28, 2009 at 7:37 PM, Tom Lane t...@sss.pgh.pa.us wrote:
IOW, having plaintext password in CREATE/ALTER time which can
then checked for weaknesses is better that MD5 password, which
actually does not increase security.
This is not acceptable and will not happen. The case that
Dave Page dp...@pgadmin.org writes:
I would suggest that in addition to the proposed plugin, we add an
suset GUC (defaulting to OFF) which rejects any use of WITH ENCRYPTED
PASSWORD to ensure that the password complexity can be checked when
roles are created or modified.
That's going to stop
Tom Lane wrote:
Dave Page dp...@pgadmin.org writes:
I would suggest that in addition to the proposed plugin, we add an
suset GUC (defaulting to OFF) which rejects any use of WITH ENCRYPTED
PASSWORD to ensure that the password complexity can be checked when
roles are created or modified.
On Wed, Oct 14, 2009 at 4:11 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Dave Page dp...@pgadmin.org writes:
I would suggest that in addition to the proposed plugin, we add an
suset GUC (defaulting to OFF) which rejects any use of WITH ENCRYPTED
PASSWORD to ensure that the password complexity can
Dave Page dp...@pgadmin.org writes:
On Wed, Oct 14, 2009 at 4:11 PM, Tom Lane t...@sss.pgh.pa.us wrote:
If you're really intent on making that happen, you can have your
password checker plugin reject crypted passwords; we don't need
such a questionable rule in core.
Client software would
On 10/14/09, Dave Page dp...@pgadmin.org wrote:
On Mon, Sep 28, 2009 at 7:37 PM, Tom Lane t...@sss.pgh.pa.us wrote:
IOW, having plaintext password in CREATE/ALTER time which can
then checked for weaknesses is better that MD5 password, which
actually does not increase security.
On Wed, Oct 14, 2009 at 4:30 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Dave Page dp...@pgadmin.org writes:
On Wed, Oct 14, 2009 at 4:11 PM, Tom Lane t...@sss.pgh.pa.us wrote:
If you're really intent on making that happen, you can have your
password checker plugin reject crypted passwords; we
On Wed, Oct 14, 2009 at 11:44 AM, Dave Page dp...@pgadmin.org wrote:
On Wed, Oct 14, 2009 at 4:30 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Dave Page dp...@pgadmin.org writes:
On Wed, Oct 14, 2009 at 4:11 PM, Tom Lane t...@sss.pgh.pa.us wrote:
If you're really intent on making that happen, you
Dave Page dp...@pgadmin.org writes:
You've twice asserted it's a reduction without providing any arguments
to back that up.
You quoted two good arguments why it's insecure in your original
message, neither of which your proposed GUC does anything to protect
against; and you also admitted that
On Wed, Oct 14, 2009 at 5:08 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Dave Page dp...@pgadmin.org writes:
You've twice asserted it's a reduction without providing any arguments
to back that up.
You quoted two good arguments why it's insecure in your original
message, neither of which your
Dave Page dp...@pgadmin.org writes:
On Wed, Oct 14, 2009 at 5:08 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I see one, and I proposed masking passwords in any relevant queries
before they were written to the stats or logs to mitigate that.
Let's see you do that (hint: CREATD USER ... PASSWORD is
On Wed, Oct 14, 2009 at 5:25 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Dave Page dp...@pgadmin.org writes:
On Wed, Oct 14, 2009 at 5:08 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I see one, and I proposed masking passwords in any relevant queries
before they were written to the stats or logs to
On Wed, Oct 14, 2009 at 18:25, Tom Lane t...@sss.pgh.pa.us wrote:
Dave Page dp...@pgadmin.org writes:
On Wed, Oct 14, 2009 at 5:08 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I see one, and I proposed masking passwords in any relevant queries
before they were written to the stats or logs to
Dave Page dp...@pgadmin.org writes:
On Wed, Oct 14, 2009 at 5:25 PM, Tom Lane t...@sss.pgh.pa.us wrote:
So you can use a plugin that does it that way, or if you want you
can use a plugin that throws error on a pre-md5'd password.
My only concern with that idea is having some way for the
Magnus Hagander mag...@hagander.net writes:
On Wed, Oct 14, 2009 at 18:25, Tom Lane t...@sss.pgh.pa.us 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).
I'm unsure if it's
nMagnus Hagander wrote:
Marko has pointed out repeatedly that a plugin can catch the worst
cases of insecure passwords even when given a pre-md5'd password.
So you can use a plugin that does it that way, or if you want you
can use a plugin that throws error on a pre-md5'd password. ?I do
On Wed, Oct 14, 2009 at 12:25 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Dave Page dp...@pgadmin.org writes:
On Wed, Oct 14, 2009 at 5:08 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I see one, and I proposed masking passwords in any relevant queries
before they were written to the stats or logs to
Robert Haas robertmh...@gmail.com writes:
On Wed, Oct 14, 2009 at 12:25 PM, Tom Lane t...@sss.pgh.pa.us 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).
It seems to me
On Wed, Oct 14, 2009 at 10:28 AM, Bruce Momjian br...@momjian.us wrote:
I see three checks we are trying to do on passwords:
1) Password complexity enforcement/policies
2) Password history - you can't reuse a password
3) Account disable after X incorrect attempts
This
On Wed, Oct 14, 2009 at 7:42 PM, Greg Stark gsst...@mit.edu wrote:
On Wed, Oct 14, 2009 at 10:28 AM, Bruce Momjian br...@momjian.us wrote:
I see three checks we are trying to do on passwords:
1) Password complexity enforcement/policies
2) Password history - you can't reuse a
On Wed, Oct 14, 2009 at 6:08 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
On Wed, Oct 14, 2009 at 18:25, Tom Lane t...@sss.pgh.pa.us wrote:
Let's see you do that (hint: CREATD USER ... PASSWORD is going to
throw a syntax error before you realize there's
On Wed, Oct 14, 2009 at 1:48 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Oct 14, 2009 at 12:25 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Let's see you do that (hint: CREATD USER ... PASSWORD is going to
throw a syntax error before you realize there's
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
Dave Page dp...@pgadmin.org writes:
On Wed, Oct 14, 2009 at 7:42 PM, Greg Stark gsst...@mit.edu wrote:
This whole discussion seems very strange to me. Surely any
organization with rules like this will want them to be system-wide and
will have already implemented them in their PAM and LDAP
On Wed, Oct 14, 2009 at 9:00 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Okay, fine, so we're not looking for actual high-grade security,
we're looking to tick off a checkbox in the minds of not terribly
well-informed people. Then the plugin mechanism as currently proposed
will do the job just
Dave Page dp...@pgadmin.org writes:
I said up front this was a box-ticking exercise for these folks,
however, rather than just tick the box and move on (meh - who cares if
we can store 2009-02-31 - it stores all the valid dates which are the
ones that matter :-p ) I prefer to discuss the issue
Dave Page dp...@pgadmin.org wrote:
I said up front this was a box-ticking exercise for these folks,
Can they check the box if the provided clients include password
strength checking? I'm just wondering if we're going at this the hard
way, if that really is the main goal.
From the point of
Kevin Grittner kevin.gritt...@wicourts.gov writes:
And, perhaps slightly off topic: if the login password is sent over a
non-encrypted stream, md5sum or not, can't someone use it to log in if
they're generating their own stream to connect?
Not if they only capture a login exchange --- the
On Wed, Oct 14, 2009 at 9:50 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Dave Page dp...@pgadmin.org wrote:
I said up front this was a box-ticking exercise for these folks,
Can they check the box if the provided clients include password
strength checking? I'm just wondering if
Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
if the login password is sent over a non-encrypted stream, md5sum
or not, can't someone use it to log in if they're generating their
own stream to connect?
If they see the md5'd password in a CREATE USER
Dave Page dp...@pgadmin.org wrote:
No. Any checks at the client are worthless, as they can be bypassed
by 10 minutes worth of simple coding in any of a dozen or more
languages.
Well, sure, but we're talking about a client going out of their way to
wrestle the point of the gun toward their
On Wed, Oct 14, 2009 at 10:51 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Dave Page dp...@pgadmin.org wrote:
No. Any checks at the client are worthless, as they can be bypassed
by 10 minutes worth of simple coding in any of a dozen or more
languages.
Well, sure, but we're talking
Tom Lane wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
And, perhaps slightly off topic: if the login password is sent over a
non-encrypted stream, md5sum or not, can't someone use it to log in if
they're generating their own stream to connect?
Not if they only capture a login
On Wed, 2009-10-14 at 12:59 -0400, Tom Lane wrote:
If psql or pgAdmin takes a password and
then sends it in the clear without telling me, that's a breach of
trust
with potentially serious consequences. I might not trust the DBA, for
example, or I might be less confident of the network
On 10/14/2009 05:33 PM, Dave Page wrote:
On Wed, Oct 14, 2009 at 9:50 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Can they check the box if the provided clients include password
strength checking? I'm just wondering if we're going at this the hard
way, if that really is the main
Peter Eisentraut pete...@gmx.net writes:
Well, you would lose anyway if the DBA switches the pg_hba.conf setting
from md5 to password without telling you.
True :-(. Anybody for a zero-knowledge protocol?
(Realistically, non-password-based auth methods are the only real
solution here, I fear.
On Wed, 2009-10-14 at 13:08 -0400, Tom Lane wrote:
The reason to not want cleartext passwords in the logs is that the
user doesn't trust the DBA.
I originally implemented the encrypt-on-the-client logic because the
previous way of using ALTER USER ... PASSWORD would promiscuously leave
the
On Wed, 2009-10-14 at 18:38 +0200, Magnus Hagander wrote:
So throwing out a wild idea that's probably just wild enough to even
consider, but one way to deal with the logging side of things would be
to deprecate/remove ALTER USER/CREATE USER with password, and add a
separate API call. With a
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
But the main point is to hide the cleartext password, in any case.
What if we added a GUC that only allowed password changes via an SSL
connection.
How's that help? The user has already exposed their new choice of
password to any
On 10/14/2009 06:02 PM, Dave Page wrote:
On Wed, Oct 14, 2009 at 10:51 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Well, sure, but we're talking about a client going out of their way to
wrestle the point of the gun toward their own foot, aren't we? If
we're worried about the
On 10/14/2009 06:25 PM, Peter Eisentraut wrote:
On Wed, 2009-10-14 at 18:38 +0200, Magnus Hagander wrote:
So throwing out a wild idea that's probably just wild enough to even
consider, but one way to deal with the logging side of things would be
to deprecate/remove ALTER USER/CREATE USER
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Peter Eisentraut pete...@gmx.net writes:
Well, you would lose anyway if the DBA switches the pg_hba.conf setting
from md5 to password without telling you.
True :-(. Anybody for a zero-knowledge protocol?
(Realistically, non-password-based auth
1 - 100 of 156 matches
Mail list logo
