Re: [BUGS] BUG #1134: ALTER USER ... RENAME breaks md5

The following bug has been logged online:

Bug reference: 1134
Logged by: Fabien COELHO

Email address: coelho(at)cri(dot)ensmp(dot)fr

PostgreSQL version: 7.5 Dev

Operating system: any

Description: ALTER USER ... RENAME breaks md5 passwords

Details:

If you rename a user with a md5 password, the
password is broken. md5 passwords are the default,
so it means that renaming a user with a password
does not work by default.

This is because the username is used implicitly as salt. This was a bad idea
(tm).

Fixing this has implications on the client/server
protocol for md5 authentication. If you're going
to fix it some day, consider also adding more
characters to the server nonce used in the protocol.

PostgreSQL Bugs List wrote:
>
> The following bug has been logged online:
>
> Bug reference: 1134
> Logged by: Fabien COELHO
>
> Email address: coelho(at)cri(dot)ensmp(dot)fr
>
> PostgreSQL version: 7.5 Dev
>
> Operating system: any
>
> Description: ALTER USER ... RENAME breaks md5 passwords
>
> Details:
>
> If you rename a user with a md5 password, the
> password is broken. md5 passwords are the default,
> so it means that renaming a user with a password
> does not work by default.
>
> This is because the username is used implicitly as salt. This was a bad idea
> (tm).
>
> Fixing this has implications on the client/server
> protocol for md5 authentication. If you're going
> to fix it some day, consider also adding more
> characters to the server nonce used in the protocol.

Yes, the problem is that we used the username for the salt, just like
FreeBSD does for its MD5 passwords. Of course, you can't rename unix
users, while PostgreSQL allows user renaming.

The attached patch clears the password field on rename:

test=> CREATE USER pass password 'aa';
CREATE USER
test=> ALTER USER pass RENAME TO pass2;
NOTICE: password cleared because OF USER RENAME
ALTER USER
test=> ALTER USER pass2 RENAME TO pass3;
ALTER USER

and adds documention explaining this behavior. I can't think of a
better solution.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Dear Bruce,

> Yes, the problem is that we used the username for the salt, just like
> FreeBSD does for its MD5 passwords.

Not that I know of on FreeBSD?

shell> uname -a
FreeBSD palo-alto2.ensmp.fr 4.9-STABLE FreeBSD 4.9-STABLE #5: Mon Mar 1 21:31:30 CET 2004 root(at)palo-alto2(dot)ensmp(dot)fr:/usr/src/sys/compile/IAR2M i386

shell> grep coelho /var/yp/master.passwd
coelho:$1$00EacB0I$4kQ/HmqFFQANZP/mxj8ZX0:210:20::0:0:COELHO, Fabien:/users/cri/coelho:/usr/local/bin/bash
^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^
salt some base 64 encoding of 1002 paranoid md5 computations.

Even of the salt is based on the login, the point is that it is stored
separatly, so the system does not rely on the login string to check the
password.

The only other scheme which requires the user password somehow is the HTTP
digest authentification, and AFAIK no one in the world uses it;-)

> The attached patch clears the password field on rename:

By 'clearing' and after a look at the patch, I understand that the access
will be denied after the rename, which is the current behavior anyway;-)

> and adds documention explaining this behavior. I can't think of a
> better solution.

Yes, I'm afraid there is no 'light' fix, other than acknowledging the
fact... Not a big issue.

Thanks,

--
Fabien Coelho - coelho(at)cri(dot)ensmp(dot)fr

Fabien COELHO wrote:
>
> Dear Bruce,
>
> > Yes, the problem is that we used the username for the salt, just like
> > FreeBSD does for its MD5 passwords.
>
> Not that I know of on FreeBSD?
>
> shell> uname -a
> FreeBSD palo-alto2.ensmp.fr 4.9-STABLE FreeBSD 4.9-STABLE #5: Mon Mar 1 21:31:30 CET 2004 root(at)palo-alto2(dot)ensmp(dot)fr:/usr/src/sys/compile/IAR2M i386
>
> shell> grep coelho /var/yp/master.passwd
> coelho:$1$00EacB0I$4kQ/HmqFFQANZP/mxj8ZX0:210:20::0:0:COELHO, Fabien:/users/cri/coelho:/usr/local/bin/bash
> ^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^
> salt some base 64 encoding of 1002 paranoid md5 computations.
>
> Even of the salt is based on the login, the point is that it is stored
> separatly, so the system does not rely on the login string to check the
> password.

Oh, I thought FreeBSD used the username. Not sure were we got that
idea. I know we needed a different salt only so users with the same
password would not have the same MD5 value.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

On Tue, Apr 27, 2004 at 09:37:50AM +0200, Fabien COELHO wrote:

> Even of the salt is based on the login, the point is that it is stored
> separatly, so the system does not rely on the login string to check the
> password.
>
> The only other scheme which requires the user password somehow is the HTTP
> digest authentification, and AFAIK no one in the world uses it;-)

I think (some of the) SASL authentication mechanisms also use a digest
of the user and password, if that's what you meant. But the username
and password have to be stored separately on the server anyway, just
like HTTP digest -- they are means of hiding it on the wire, not on
disk.

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"El miedo atento y previsor es la madre de la seguridad" (E. Burke)

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> The attached patch clears the password field on rename:

I think you should clear the password field *only* if it's
MD5-encrypted.

regards, tom lane

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > The attached patch clears the password field on rename:
>
> I think you should clear the password field *only* if it's
> MD5-encrypted.

I thought about that but it seems strange to conditionally do the
clearing, but if you think we should, I can do it.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > The attached patch clears the password field on rename:
>
> I think you should clear the password field *only* if it's
> MD5-encrypted.

Patch attached and applied.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > > The attached patch clears the password field on rename:
> >
> > I think you should clear the password field *only* if it's
> > MD5-encrypted.
>
> Patch attached and applied.

Oh, I forgot to display the new behavior:

test=> CREATE USER test;
CREATE USER
test=> ALTER USER test RENAME TO test2;
ALTER USER
test=> ALTER USER test2 UNENCRYPTED PASSWORD 'x';
ALTER USER
test=> ALTER USER test2 RENAME TO test4;
ALTER USER
test=> ALTER USER test4 PASSWORD 'x';
ALTER USER
test=> ALTER USER test4 RENAME TO test8;
NOTICE: MD5 password cleared because of user rename
ALTER USER
test=> SELECT * FROM pg_shadow WHERE usename = 'test8';
usename | usesysid | usecreatedb | usesuper | usecatupd | passwd |
valuntil | useconfig
---------+----------+-------------+----------+-----------+--------+----------+-----------

test8 | 100 | f | f | f | |
|
(1 row)

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073