Rejecting weak passwords
in [PgSql]
|
From: Tom Lane on 28 Sep 2009 11:38 "Albe Laurenz" <laurenz.albe(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 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Dave Page on 28 Sep 2009 11:48 On Mon, Sep 28, 2009 at 4:38 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > "Albe Laurenz" <laurenz.albe(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 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 28 Sep 2009 11:50 Dave Page <dpage(a)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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: "Albe Laurenz" on 28 Sep 2009 11:31 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Marko Kreen on 28 Sep 2009 14:00
On 9/28/09, Tom Lane <tgl(a)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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |