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 allows one to add
password checking functions
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 allows one to add
password checking functions
b) a contrib
Bruce Momjian wrote:
Tom Lane wrote:
That said, it would still be good to have something actually *useful*
in contrib. A bit more than just comparing userid and password.
Perhaps at least being able to set the min length, and the requirement
on having 1 character class?
+1. There's
Tom Lane wrote:
Magnus Hagander mag...@hagander.net writes:
That said, it would still be good to have something actually *useful*
in contrib. A bit more than just comparing userid and password.
Perhaps at least being able to set the min length, and the requirement
on having 1 character
In the discussion following
http://archives.postgresql.org/pgsql-hackers/2009-09/msg01766.php
the consensus was that a hook that allows you to implement
a password checking routine as a module would not hurt.
So here's the patch.
I don't think there is documentation required;
correct me if I am
On Thu, Oct 1, 2009 at 1:53 PM, Albe Laurenz laurenz.a...@wien.gv.at wrote:
In the discussion following
http://archives.postgresql.org/pgsql-hackers/2009-09/msg01766.php
the consensus was that a hook that allows you to implement
a password checking routine as a module would not hurt.
So
Dave Page wrote:
On Thu, Oct 1, 2009 at 1:53 PM, Albe Laurenz laurenz.a...@wien.gv.at wrote:
In the discussion following
http://archives.postgresql.org/pgsql-hackers/2009-09/msg01766.php
the consensus was that a hook that allows you to implement
a password checking routine as a module
Andrew Dunstan wrote:
So here's the patch.
I don't think there is documentation required;
correct me if I am wrong.
How will people know how to use it, or that it's even there without at
least a note in the docs somewhere?
I'd prefer to have an example as a contrib module, as well as
On Thu, Oct 1, 2009 at 15:26, Albe Laurenz laurenz.a...@wien.gv.at wrote:
Andrew Dunstan wrote:
So here's the patch.
I don't think there is documentation required;
correct me if I am wrong.
How will people know how to use it, or that it's even there without at
least a note in the docs
On Thu, Oct 01, 2009 at 03:54:37PM +0200, Magnus Hagander wrote:
On Thu, Oct 1, 2009 at 15:26, Albe Laurenz laurenz.a...@wien.gv.at wrote:
Andrew Dunstan wrote:
So here's the patch.
I don't think there is documentation required;
correct me if I am wrong.
How will people know how to
* Albe Laurenz laurenz.a...@wien.gv.at [091001 08:54]:
In the discussion following
http://archives.postgresql.org/pgsql-hackers/2009-09/msg01766.php
the consensus was that a hook that allows you to implement
a password checking routine as a module would not hurt.
So here's the patch.
I
Aidan Van Dyk wrote:
Can we have the check password hook function called in both the
plaintext/encrypted case, with a flag as to whether it's encrypted or
not?
It will be called in both cases, and I figured that you can
check yourself the same way that PostgreSQL does:
If isMD5(password), then
Dave Page dp...@pgadmin.org writes:
How will people know how to use it, or that it's even there without at
least a note in the docs somewhere?
We don't normally document function hooks anywhere but the source code.
That's one of the things that makes them low overhead ;-)
I agree with the
On Thu, Oct 1, 2009 at 17:24, Tom Lane t...@sss.pgh.pa.us wrote:
Dave Page dp...@pgadmin.org writes:
How will people know how to use it, or that it's even there without at
least a note in the docs somewhere?
We don't normally document function hooks anywhere but the source code.
That's one
Magnus Hagander escreveu:
On Thu, Oct 1, 2009 at 17:24, Tom Lane t...@sss.pgh.pa.us wrote:
Dave Page dp...@pgadmin.org writes:
How will people know how to use it, or that it's even there without at
least a note in the docs somewhere?
We don't normally document function hooks anywhere but the
Magnus Hagander mag...@hagander.net writes:
On Thu, Oct 1, 2009 at 17:24, Tom Lane t...@sss.pgh.pa.us wrote:
I agree with the subsequent comments suggesting a sample module that
actually does something useful --- although if it's going to link to
external code like cracklib, it probably is
On Thu, Oct 1, 2009 at 19:07, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
On Thu, Oct 1, 2009 at 17:24, Tom Lane t...@sss.pgh.pa.us wrote:
I agree with the subsequent comments suggesting a sample module that
actually does something useful --- although if it's
On Thu, Oct 01, 2009 at 01:07:04PM -0400, Tom Lane wrote:
Magnus Hagander mag...@hagander.net writes:
On Thu, Oct 1, 2009 at 17:24, Tom Lane t...@sss.pgh.pa.us wrote:
I agree with the subsequent comments suggesting a sample module that
actually does something useful --- although if it's
Tom Lane wrote:
Magnus Hagander mag...@hagander.net writes:
On Thu, Oct 1, 2009 at 17:24, Tom Lane t...@sss.pgh.pa.us wrote:
I agree with the subsequent comments suggesting a sample module that
actually does something useful --- although if it's going to link to
external code like
Magnus Hagander mag...@hagander.net writes:
That said, it would still be good to have something actually *useful*
in contrib. A bit more than just comparing userid and password.
Perhaps at least being able to set the min length, and the requirement
on having 1 character class?
+1. There's
Tom Lane wrote:
pgAdmin MD5's the passwords if you use the GUI to change them, or when
add a user. It doesn't make any attempt to parse the SQL if you enter
it yourself in the query tool though (nor is it going to).
No, I wouldn't expect it to go that far. My point is just that
On Mon, 2009-09-28 at 15:59 -0700, Joshua D. Drake wrote:
On Mon, 2009-09-28 at 15:52 -0700, Josh Berkus wrote:
It takes about 32 hours to brute force all passwords from [a-zA-Z0-9]
of up to 8 chars in length.
That would be a reason to limit the number of failed connection attempts
On Tue, Sep 29, 2009 at 4:49 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Josh Berkus j...@agliodbs.com writes:
Hmmm, that would be a useful, easy (I think) security feature: add a GUC
for failed_logins_allowed.
And the counts would be tracked and enforced where?
Combining this with other
Albe Laurenz laurenz.a...@wien.gv.at writes:
I thought about it some more, and I think that a password checking
hook might still be somewhat useful even for MD5-encrypted passwords;
the function could guess and exclude at least that dreadful
all-too-frequent case of username = password.
True.
On Tue, Sep 29, 2009 at 9:48 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Albe Laurenz laurenz.a...@wien.gv.at writes:
I thought about it some more, and I think that a password checking
hook might still be somewhat useful even for MD5-encrypted passwords;
the function could guess and exclude at
Robert Haas wrote:
On Tue, Sep 29, 2009 at 9:48 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Albe Laurenz laurenz.a...@wien.gv.at writes:
I thought about it some more, and I think that a password checking
hook might still be somewhat useful even for MD5-encrypted passwords;
the function
Robert Haas robertmh...@gmail.com writes:
But how much value is there in that? This whole thing seems like a
dead end to me. No matter how long you're willing to wait, putting
the checking on the client side will let you far more validation for
the same price.
No doubt, but ...
The value
Andrew Dunstan and...@dunslane.net writes:
Why do we need to answer that question? If all we do is provide a hook,
the cost is very low, and the decision on value is left to whoever is
deploying some module to use the hook.
Right. As long as it's just a hook, it's not enough work to justify
On 09/29/2009 09:07 AM, Gurjeet Singh wrote:
On Tue, Sep 29, 2009 at 4:49 AM, Tom Lane t...@sss.pgh.pa.us
mailto:t...@sss.pgh.pa.us wrote:
Josh Berkus j...@agliodbs.com mailto:j...@agliodbs.com writes:
Hmmm, that would be a useful, easy (I think) security feature:
add a GUC
Mark,
I read Josh's original suggestion to eventually evolve to if a
particular user account from a particular IP address uses the wrong
password more than N times in T minutes, than the IP address is locked
out for U minutes. This is the *only* way of significantly reducing the
ability of a
On 09/29/2009 12:54 PM, Josh Berkus wrote:
I read Josh's original suggestion to eventually evolve to if a
particular user account from a particular IP address uses the wrong
password more than N times in T minutes, than the IP address is locked
out for U minutes. This is the *only* way of
Dear hackers,
I have been thinking about ways to have PostgreSQL reject
weak passwords.
I think the standard recommendation is use PAM and LDAP,
but that requires the user to change the password outside
of PostgreSQL. And who would want to setup and maintain an
LDAP server just for this?
Since
On 28 sep 2009, at 11.54, Albe Laurenz laurenz.a...@wien.gv.at
wrote:
Dear hackers,
I have been thinking about ways to have PostgreSQL reject
weak passwords.
I think the standard recommendation is use PAM and LDAP,
but that requires the user to change the password outside
of PostgreSQL.
Albe Laurenz wrote:
Dear hackers,
I have been thinking about ways to have PostgreSQL reject
weak passwords.
I think the standard recommendation is use PAM and LDAP,
but that requires the user to change the password outside
of PostgreSQL. And who would want to setup and maintain an
LDAP
Andrew Dunstan escribió:
Albe Laurenz wrote:
Dear hackers,
I have been thinking about ways to have PostgreSQL reject
weak passwords.
I think the standard recommendation is use PAM and LDAP,
but that requires the user to change the password outside
of PostgreSQL. And who would want to setup
* Magnus Hagander (mag...@hagander.net) wrote:
Are there better ways?
Isn't there some library we can link with and (conditionally) use? I
believe windows exposes api function(s) to let you verify password
complexity - I'm sure there is something similar available on unix,
hopefully
In response to Ing. Marcos L. Ortíz Valmaseda mlor...@uci.cu:
Andrew Dunstan escribió:
Albe Laurenz wrote:
Dear hackers,
I have been thinking about ways to have PostgreSQL reject
weak passwords.
I think the standard recommendation is use PAM and LDAP,
but that requires the
2009/9/28 Stephen Frost sfr...@snowman.net:
* Magnus Hagander (mag...@hagander.net) wrote:
Are there better ways?
Isn't there some library we can link with and (conditionally) use? I
believe windows exposes api function(s) to let you verify password
complexity - I'm sure there is something
Ing. Marcos L. Ortíz Valmaseda wrote:
My vote is for #3, if anything.
You have to analyze all points before to do this. I vote too for the
third option, but you have to be clear that how do you ´ll check the
weakness of the password:
1- For example: the length should be greater that 6
2009/9/28 Andrew Dunstan and...@dunslane.net:
Ing. Marcos L. Ortíz Valmaseda wrote:
My vote is for #3, if anything.
You have to analyze all points before to do this. I vote too for the third
option, but you have to be clear that how do you ´ll check the weakness of
the password:
1-
Andrew Dunstan and...@dunslane.net writes:
Albe Laurenz wrote:
1) One could have a set of GUCs like min_password_length,
min_password_nonchars and similar that everybody
could configure. This is not extremely flexible though.
2) Another idea would be a GUC that contains a regular
expression
Actually there's a much bigger problem with asking the backend to reject
weak passwords: what ya gonna do with a pre-MD5'd string? Which is
exactly what the backend is going to always get, in a security-conscious
environment.
regards, tom lane
--
Sent via pgsql-hackers
Albe Laurenz laurenz.a...@wien.gv.at writes:
Tom Lane wrote:
Actually there's a much bigger problem with asking the backend to reject
weak passwords: what ya gonna do with a pre-MD5'd string? Which is
exactly what the backend is going to always get, in a security-conscious
environment.
I'm
On Mon, Sep 28, 2009 at 4:38 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Albe Laurenz laurenz.a...@wien.gv.at writes:
Tom Lane wrote:
Actually there's a much bigger problem with asking the backend to reject
weak passwords: what ya gonna do with a pre-MD5'd string? Which is
exactly what the
Dave Page dp...@pgadmin.org writes:
pgAdmin MD5's the passwords if you use the GUI to change them, or when
add a user. It doesn't make any attempt to parse the SQL if you enter
it yourself in the query tool though (nor is it going to).
No, I wouldn't expect it to go that far. My point is just
Tom Lane wrote:
Actually there's a much bigger problem with asking the backend to reject
weak passwords: what ya gonna do with a pre-MD5'd string? Which is
exactly what the backend is going to always get, in a security-conscious
environment.
You mean if the password is set with
CREATE/ALTER
On 9/28/09, Tom Lane t...@sss.pgh.pa.us wrote:
Actually there's a much bigger problem with asking the backend to reject
weak passwords: what ya gonna do with a pre-MD5'd string? Which is
exactly what the backend is going to always get, in a security-conscious
environment.
Hmm... Looking at
Marko Kreen mark...@gmail.com writes:
So promoting the ENCRYPTED 'foo' as secure may lure users into
false sense of security, and be lax against sniffing and logfile
protection.
This argument is entirely irrelevant to the point. Yes, ENCRYPTED
doesn't fix everything, but it is still good
On Mon, Sep 28, 2009 at 2:00 PM, Marko Kreen mark...@gmail.com wrote:
So promoting the ENCRYPTED 'foo' as secure may lure users into
false sense of security, and be lax against sniffing and logfile
protection.
ENCRYPTED prevents the user's password from being stolen by a modified server.
The case that ENCRYPTED
protects against is database superusers finding out other users'
original passwords, which is a security issue to the extent that those
users have used the same/similar passwords for other systems.
I just want to note that md5 is not much of a protection against this
It takes about 32 hours to brute force all passwords from [a-zA-Z0-9]
of up to 8 chars in length.
That would be a reason to limit the number of failed connection attempts
from a single source, then, rather than a reason to change the hash
function.
Hmmm, that would be a useful, easy (I think)
On Mon, 2009-09-28 at 15:52 -0700, Josh Berkus wrote:
It takes about 32 hours to brute force all passwords from [a-zA-Z0-9]
of up to 8 chars in length.
That would be a reason to limit the number of failed connection attempts
from a single source, then, rather than a reason to change the
On Mon, 2009-09-28 at 15:52 -0700, Josh Berkus wrote:
It takes about 32 hours to brute force all passwords from [a-zA-Z0-9]
of up to 8 chars in length.
That would be a reason to limit the number of failed connection attempts
from a single source, then, rather than a reason to change the
Jeff Davis wrote:
On Mon, 2009-09-28 at 15:52 -0700, Josh Berkus wrote:
It takes about 32 hours to brute force all passwords from [a-zA-Z0-9]
of up to 8 chars in length.
That would be a reason to limit the number of failed connection attempts
from a single source, then, rather than
Josh Berkus j...@agliodbs.com writes:
Hmmm, that would be a useful, easy (I think) security feature: add a GUC
for failed_logins_allowed.
And the counts would be tracked and enforced where?
regards, tom lane
--
Sent via pgsql-hackers mailing list
marcin mank marcin.m...@gmail.com writes:
The case that ENCRYPTED
protects against is database superusers finding out other users'
original passwords, which is a security issue to the extent that those
users have used the same/similar passwords for other systems.
I just want to note that md5
101 - 156 of 156 matches
Mail list logo
