"Albe Laurenz" 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 is not made less ina
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 thi
Itagaki Takahiro writes:
> "Albe Laurenz" 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 modifications. Aside from the added valuntil
paramete
Itagaki Takahiro 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 policies
tend to want a lim
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 tim
"Albe Laurenz" 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 accordingly.
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
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
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
"Albe Laurenz" 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 that allo
On Tue, Oct 20, 2009 at 9:42 AM, Tom Lane wrote:
> Magnus Hagander writes:
>> 2009/10/19 Tom Lane :
>>> 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
Magnus Hagander writes:
> 2009/10/19 Tom Lane :
>> 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 change the name
> of a user, but
2009/10/19 Tom Lane :
> 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 fo
Tom Lane wrote:
> "Albe Laurenz" 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
> >> necessa
Andrew Dunstan 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 passwords w
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
CREA
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 adve
Tom Lane escribió:
> Peter Eisentraut 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).
Peter Eisentraut 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 is cur
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
"Albe Laurenz" 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 features.
>
On Mon, Oct 19, 2009 at 7:34 AM, Peter Eisentraut 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 would be f
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 ch
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 requir
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 p
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 pl
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 calcula
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, i
Tom Lane wrote:
> Bruce Momjian 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
On Fri, Oct 16, 2009 at 4:28 PM, Bruce Momjian 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
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 wo
Bruce Momjian 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 our concern.
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
Tom Lane wrote:
> Robert Haas 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* *fl
On Thu, Oct 15, 2009 at 10:40 PM, Ron Mayer
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 can't already check t
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 o
On Thu, Oct 15, 2009 at 7:22 PM, Mark Mielke 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 your company - but
On 10/15/2009 02:02 PM, Dave Page wrote:
On Thu, Oct 15, 2009 at 6:55 PM, Robert Haas 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
Dave Page 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 think that autom
Dave Page writes:
> On Thu, Oct 15, 2009 at 6:43 PM, Tom Lane 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 core system with it.
> I alre
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 stage
On Thu, Oct 15, 2009 at 6:55 PM, Robert Haas 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 actually 'enforcemen
On Thu, Oct 15, 2009 at 1:47 PM, Dave Page wrote:
> On Thu, Oct 15, 2009 at 6:43 PM, Tom Lane wrote:
>> Robert Haas 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.
On Thu, Oct 15, 2009 at 6:43 PM, Tom Lane wrote:
> Robert Haas 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
On Thu, Oct 15, 2009 at 6:17 PM, Josh Berkus 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 can be checked i
Robert Haas 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 force plaintext
> i
On Thu, Oct 15, 2009 at 12:23 PM, Mark Mielke 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.
>
> It's a lot easi
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 thin
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 pass
On Thu, Oct 15, 2009 at 5:28 PM, Mark Mielke 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 sending them in
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 o
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 ar
On 10/15/2009 03:54 AM, Dave Page wrote:
On Wed, Oct 14, 2009 at 11:21 PM, Mark Mielke 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.
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, O
On Thu, Oct 15, 2009 at 2:49 PM, Kevin Grittner
wrote:
> Dave Page 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
Dave Page 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 illusion of a
On Wed, Oct 14, 2009 at 11:44 PM, Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Peter Eisentraut 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 pro
On Wed, Oct 14, 2009 at 11:21 PM, Mark Mielke 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 small for
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Peter Eisentraut 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 ar
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 wit
On 10/14/2009 06:02 PM, Dave Page wrote:
On Wed, Oct 14, 2009 at 10:51 PM, Kevin Grittner
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 user compromising their own pas
Bruce Momjian 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 hypothetical eaves
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
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 cle
Peter Eisentraut 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. We should pro
On 10/14/2009 05:33 PM, Dave Page wrote:
On Wed, Oct 14, 2009 at 9:50 PM, Kevin Grittner
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 goal.
No. Any checks
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 in
Tom Lane wrote:
> "Kevin Grittner" 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 10:51 PM, Kevin Grittner
wrote:
> 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.
>
> Well, sure, but we're talking about a client going out of their w
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.
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
Tom Lane wrote:
> "Kevin Grittner" 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 command, then yeah
So anyone in a
On Wed, Oct 14, 2009 at 9:50 PM, Kevin Grittner
wrote:
> Dave Page 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 th
"Kevin Grittner" 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 password is doubly
encrypte
Dave Page 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 view of usefulne
Dave Page 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 and do the be
On Wed, Oct 14, 2009 at 9:00 PM, Tom Lane 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 fine. We do not n
Dave Page writes:
> On Wed, Oct 14, 2009 at 7:42 PM, Greg Stark 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 systems
>> (assuming their not
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 bac
On Wed, Oct 14, 2009 at 1:48 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Oct 14, 2009 at 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 protect
On Wed, Oct 14, 2009 at 6:08 PM, Tom Lane wrote:
> Magnus Hagander writes:
>> On Wed, Oct 14, 2009 at 18:25, 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 protec
On Wed, Oct 14, 2009 at 7:42 PM, Greg Stark wrote:
> On Wed, Oct 14, 2009 at 10:28 AM, Bruce Momjian 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) A
On Wed, Oct 14, 2009 at 10:28 AM, Bruce Momjian 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 whole discu
Robert Haas writes:
> On Wed, Oct 14, 2009 at 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).
> It seems to me incredibly rare for anyone to iss
On Wed, Oct 14, 2009 at 12:25 PM, Tom Lane wrote:
> Dave Page writes:
>> On Wed, Oct 14, 2009 at 5:08 PM, Tom Lane 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: "CR
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.
Magnus Hagander writes:
> On Wed, Oct 14, 2009 at 18:25, 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).
> I'm unsure if it's our responsibility to think
Dave Page writes:
> On Wed, Oct 14, 2009 at 5:25 PM, Tom Lane 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 client to
> know when to not hash t
On Wed, Oct 14, 2009 at 18:25, Tom Lane wrote:
> Dave Page writes:
>> On Wed, Oct 14, 2009 at 5:08 PM, Tom Lane 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: "CREAT
On Wed, Oct 14, 2009 at 5:25 PM, Tom Lane wrote:
> Dave Page writes:
>> On Wed, Oct 14, 2009 at 5:08 PM, Tom Lane 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: "CRE
Dave Page writes:
> On Wed, Oct 14, 2009 at 5:08 PM, Tom Lane 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 going to
throw a syntax error be
On Wed, Oct 14, 2009 at 5:08 PM, Tom Lane wrote:
> Dave Page 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 pr
Dave Page 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 there might be ot
On Wed, Oct 14, 2009 at 11:44 AM, Dave Page wrote:
> On Wed, Oct 14, 2009 at 4:30 PM, Tom Lane wrote:
>> Dave Page writes:
>>> On Wed, Oct 14, 2009 at 4:11 PM, Tom Lane wrote:
If you're really intent on making that happen, you can have your
password checker plugin reject crypted passw
On Wed, Oct 14, 2009 at 4:30 PM, Tom Lane wrote:
> Dave Page writes:
>> On Wed, Oct 14, 2009 at 4:11 PM, Tom Lane 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.
Dave Page writes:
> On Wed, Oct 14, 2009 at 4:11 PM, Tom Lane 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 need to have a standard way to
On 10/14/09, Dave Page wrote:
> On Mon, Sep 28, 2009 at 7:37 PM, Tom Lane 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 a
On Wed, Oct 14, 2009 at 4:11 PM, Tom Lane wrote:
> Dave Page 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 c
Tom Lane wrote:
Dave Page 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
Dave Page 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 us from being
On Mon, Sep 28, 2009 at 7:37 PM, Tom Lane 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 ENCRYPTED
> pr
1 - 100 of 155 matches
Mail list logo
