Rejecting weak passwords

On 28 sep 2009, at 11.54, "Albe Laurenz" <laurenz.albe@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. And who would want to setup and maintain an
LDAP server just for this?

Since everybody has different ideas what is a good password,
there should be some way to configure that. I've looked at
how Oracle does it, and they simply let you write a
stored procedure that throws an exception if it doesn't
like the password.
Since users are on cluster level and functions live in
databases, that won't work in PostgreSQL.

I have come up with an idea or two and like to hear your
opinion.

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 that a password may *not* match.
Perhaps that's too limiting too.
3) I have also considered a GUC that points to a loadable
module that performs the password check if set.

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 included on most common platforms?

/Magnus

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 server just for this?

Since everybody has different ideas what is a good password,
there should be some way to configure that. I've looked at
how Oracle does it, and they simply let you write a
stored procedure that throws an exception if it doesn't
like the password.
Since users are on cluster level and functions live in
databases, that won't work in PostgreSQL.

I have come up with an idea or two and like to hear your
opinion.

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 that a password may *not* match.
Perhaps that's too limiting too.
3) I have also considered a GUC that points to a loadable
module that performs the password check if set.

My vote is for #3, if anything.

cheers

andrew

* Magnus Hagander (magnus@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 included on most common platforms?

cracklib2.

Stephen

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 and maintain an
LDAP server just for this?

Since everybody has different ideas what is a good password,
there should be some way to configure that. I've looked at
how Oracle does it, and they simply let you write a
stored procedure that throws an exception if it doesn't
like the password.
Since users are on cluster level and functions live in
databases, that won't work in PostgreSQL.

I have come up with an idea or two and like to hear your
opinion.

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 that a password may *not* match.
Perhaps that's too limiting too.
3) I have also considered a GUC that points to a loadable
module that performs the password check if set.

My vote is for #3, if anything.

cheers

andrew

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 char..
2- The password should be have a combination fo numbers, letters and
others dots

Things like that you have to think very well, or to do a question to the
list asking which are the best options.

I think the same about the PAM and LDAP auth

Regards

--
"DBAs must implements decisions based on the best fit of the application,DBMS, and platform
......for that reason.......I use PostgreSQL + Linux"

Ing. Marcos L. Ortiz Valmaseda
Línea Soporte y Despliegue
Centro de Tecnologías de Almacenamiento y Análisis de Datos (CENTALAD)

Linux User # 418229
PostgreSQL User
http://www.postgresql.org
http://www.planetpostgresql.org/
http://www.postgresql-es.org/

In response to "Ing. Marcos L. Ortí­z Valmaseda" <mlortiz@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 user to change the password outside
of PostgreSQL. And who would want to setup and maintain an
LDAP server just for this?

An option here is to have a way for PG to hook in to LDAP/PAM so
that an ALTER ROLE actually changes the LDAP/PAM password.

Since everybody has different ideas what is a good password,
there should be some way to configure that. I've looked at
how Oracle does it, and they simply let you write a
stored procedure that throws an exception if it doesn't
like the password.

[snip]

3) I have also considered a GUC that points to a loadable
module that performs the password check if set.

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 char..
2- The password should be have a combination fo numbers, letters and
others dots

I think you've missed the point. If a loadable module is used, then
it can do anything the DBAs need it to. You can write your own module
if you're not happy with those provided. At that point, arguing about
what makes a good password is pretty irrelevant. Note the paragraph
that I didn't snip where Albe points this out.

--
Bill Moran
http://www.potentialtech.com
http://people.collaborativefusion.com/~wmoran/

2009/9/28 Stephen Frost <sfrost@snowman.net>:

* Magnus Hagander (magnus@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 included on most common platforms?

cracklib2.

That sounds like the one I thought about :-)

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

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 char..
2- The password should be have a combination fo numbers, letters and
others dots

Things like that you have to think very well, or to do a question to
the list asking which are the best options.

I think the same about the PAM and LDAP auth

I'm voting for #3 precisely so postgres doesn't have to think about it,
and the module author will do all the work implementing whatever rules
they want to enforce.

cheers

andrew

2009/9/28 Andrew Dunstan <andrew@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- For example: the length should be greater that 6 char..
2- The password should be have  a combination fo numbers, letters and others dots

Things like that you have to think very well, or to do a question to the list asking which are the best options.

I think the same about the PAM and LDAP auth

I'm voting for #3 precisely so postgres doesn't have to think about it, and the module author will do all the work implementing whatever rules they want to enforce.

That makes a lot of sense. Then we could perhaps ship a cracklib2
provider in contrib.

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

Andrew Dunstan <andrew@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 that a password may *not* match.
Perhaps that's too limiting too.
3) I have also considered a GUC that points to a loadable
module that performs the password check if set.

My vote is for #3, if anything.

Yeah. I think there is no chance of anything in this vein getting
accepted into core Postgres, if only because everybody will have a
different idea of what it needs to do. A hook function (no need
for a GUC) would be a reasonable proposal.

regards, tom lane

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

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 ROLE x ENCRYPTED PASSWORD 'md5string' ?
That could not be checked of course...

I'm thinking of the case where somebody changes his or her
password interactively on the command line, with pgAdmin III,
or similar. People would hardly use the above in that case,
and you can do it safely over SSL encrypted connections.

Given the feedback by everybody (thanks!) I will investigate
the option of a loadable module or some other kind of hook.

Is there code in PostgreSQL that uses something like that
to get me started?

Yours,
Laurenz Albe

"Albe Laurenz" <laurenz.albe@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 thinking of the case where somebody changes his or her
password interactively on the command line, with pgAdmin III,
or similar. People would hardly use the above in that case,

Really? If pgAdmin has a password-change function that doesn't use
client-side password encryption then somebody should file a bug against
it. Sending unencrypted passwords exposes the password at least to the
postmaster logfile. createuser has been doing encryption, unless
specifically commanded not to, for a long time.

regards, tom lane

On Mon, Sep 28, 2009 at 4:38 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

"Albe Laurenz" <laurenz.albe@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 thinking of the case where somebody changes his or her
password interactively on the command line, with pgAdmin III,
or similar. People would hardly use the above in that case,

Really?  If pgAdmin has a password-change function that doesn't use
client-side password encryption then somebody should file a bug against
it.  Sending unencrypted passwords exposes the password at least to the
postmaster logfile.  createuser has been doing encryption, unless
specifically commanded not to, for a long time.

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).

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

Dave Page <dpage@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 that
pre-MD5'd passwords are a lot commoner than Albe seems to think.

regards, tom lane

On 9/28/09, Tom Lane <tgl@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 the docs, I don't see anywhere mention that the MD5
hashed passwords can still be used to log in, that only thing MD5'ing
protects from is actually knowing what the password was.

Also, although it does protect from sniffing password at login time,
it is as insecure as plaintext password against sniffing on
CREATE/ALTER USER time.

Thus only secure way to change password is over SSL, in which case
it does not make much difference whether it's plaintext or not.
Logfile may seem to be as argument against plaintext, but note
that you still cannot allow unprivileged users to access logfile
that may contain MD5 passwords, as they can use them to log in
as another user.

So promoting the ENCRYPTED 'foo' as "secure" may lure users into
false sense of security, and be lax against sniffing and logfile
protection.

Better approach seems to be simply refuse to log the password
value into logfile, whether it's MD5 or not, and promote SSL
as only secure way of changing passwords.

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.

We just need to fix the logging.

--
marko

Marko Kreen <markokr@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 practice to use it
and most well-written tools will. So having a weak-password detector
that can only work on non-encrypted passwords is going to not be
very helpful.

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
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.
We're not going to give up protection for that in order to provide
an option to do weak-password checking in a place that simply isn't
the best place to do it anyway.

regards, tom lane

On Mon, Sep 28, 2009 at 2:00 PM, Marko Kreen <markokr@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.

...Robert

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
case these days. Take a look at this:
http://www.golubev.com/hashgpu.htm

It takes about 32 hours to brute force all passwords from [a-zA-Z0-9]
of up to 8 chars in length.

Maybe it is time to look at something like bcrypt.
http://chargen.matasano.com/chargen/2007/9/7/enough-with-the-rainbow-tables-what-you-need-to-know-about-s.html

Greetings
Marcin

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) security feature: add a GUC
for failed_logins_allowed.

--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com