Re: Postgres: pg_hba.conf, md5, pg_shadow, encrypted passwords

pgman wrote:
> Stephen Frost wrote:
> -- Start of PGP signed section.
> > * Andrew Dunstan (andrew(at)dunslane(dot)net) wrote:
> > > The docs say: "only md5 supports encrypted passwords stored in
> > > pg_shadow; the other two require unencrypted passwords to be stored
> > > there." So either your assertion that 'password' auth does not imply
> > > plaintext password storage is wrong, or the docs are.
> >
> > The docs are wrong. Sorry, I knew that and forgot to mention it
> > explicitly previously. Using 'password' in pg_hba.conf while using
> > 'with encrypted password'/md5 in pg_shadow works just fine.
> >
> > Just tested here to make 100% sure, under 8.0.1.
>
> I see the documentation is slightly confusing. I have applied this
> patch to HEAD and 8.0.X to clarify it.

With the documentation text clarified, this patch fixes the actual
documentation problem that both 'password' and 'md5' supporte encrypted
pg_shadow passwords, while only crypt does not. Applied to 8.0.X and
HEAD.

--
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 (pgman(at)candle(dot)pha(dot)pa(dot)us) wrote:
> With the documentation text clarified, this patch fixes the actual
> documentation problem that both 'password' and 'md5' supporte encrypted
> pg_shadow passwords, while only crypt does not. Applied to 8.0.X and
> HEAD.

Great, thanks. Here's a suggestion to replace the last two sentences:

These methods differ in how the password is sent across the network and
in the meaning of what is stored in pg_shadow.

The 'password' method sends the password across the network in
plaintext which could allow someone sniffing the network to retrieve
it unless there is encryption being done in the transport layer (ie:
SSL or IPSEC). Using the 'password' method the server will either
compare the provided password to what is stored in pg_shadow or, if
the 'with encrypted password' option was used to md5 the password in
pg_shadow, the server will concatenate the user's name to the
password and perform an md5 hash and compare that to what is in
pg_shadow.

With the 'md5' method the server will send will send a randomly
generated salt to the client which will then concatenate the user's name
to the password, perform an md5 on that result, then concatenate the
result of the md5 to the salt provided by the server and will then md5
that. The client sends the result of that md5 to the server which then
reads what is in pg_shadow, which must be md5 using 'with encrypted
password', concatenates that with the random salt sent to client,
performs an md5 on the result and compares that to what was sent by the
client. Note: this makes the md5 hash stored in pg_shadow what is known
as a 'password-equivilant', which means that an attacker does not need
the original password to authenticate to PostgreSQL, the attacker needs
only the hash which is stored directly in pg_shadow. In other words, if
pg_shadow is compromised an attacker can then log into the database as
any user without any effort.

Thanks,

Stephen

I think the behaviour on the wire should be more explcitly stated.

cheers

andrew

Bruce Momjian wrote:

>------------------------------------------------------------------------
>
>Index: doc/src/sgml/client-auth.sgml
>===================================================================
>RCS file: /cvsroot/pgsql/doc/src/sgml/client-auth.sgml,v
>retrieving revision 1.75
>diff -c -c -r1.75 client-auth.sgml
>*** doc/src/sgml/client-auth.sgml 21 Apr 2005 22:19:19 -0000 1.75
>--- doc/src/sgml/client-auth.sgml 21 Apr 2005 22:23:47 -0000
>***************
>*** 575,583 ****
> The password-based authentication methods are <literal>md5</>,
> <literal>crypt</>, and <literal>password</>. These methods operate
> similarly except for the way that the password is sent across the
>! connection. However, only <literal>md5</> allows encrypted
>! passwords to be stored in <structname>pg_shadow</structname>;
>! the other two require unencrypted passwords to be stored there.
> </para>
>
> <para>
>--- 575,582 ----
> The password-based authentication methods are <literal>md5</>,
> <literal>crypt</>, and <literal>password</>. These methods operate
> similarly except for the way that the password is sent across the
>! connection. However, <literal>crypt</> does not allow encrypted
>! passwords to be stored in <structname>pg_shadow</structname>.
> </para>
>
> <para>
>
>
>------------------------------------------------------------------------
>
>
>
>

* Andrew Dunstan (andrew(at)dunslane(dot)net) wrote:
> I think the behaviour on the wire should be more explcitly stated.

Please comment on the message I just sent to -hackers which has a much
longer and more detailed explanation of what happens.

Thanks,

Stephen

Stephen Frost wrote:
-- Start of PGP signed section.
> * Andrew Dunstan (andrew(at)dunslane(dot)net) wrote:
> > I think the behaviour on the wire should be more explcitly stated.
>
> Please comment on the message I just sent to -hackers which has a much
> longer and more detailed explanation of what happens.

The next paragraph in the docs is:

If you are at all concerned about password
<quote>sniffing</> attacks then <literal>md5</> is preferred, with
<literal>crypt</> a second choice if you must support pre-7.2
clients. Plain <literal>password</> should especially be avoided for
connections over the open Internet (unless you use <acronym>SSL</acronym>, SSH, or
other communications security wrappers around the connection).

--
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 (pgman(at)candle(dot)pha(dot)pa(dot)us) wrote:
> Stephen Frost wrote:
> -- Start of PGP signed section.
> > * Andrew Dunstan (andrew(at)dunslane(dot)net) wrote:
> > > I think the behaviour on the wire should be more explcitly stated.
> >
> > Please comment on the message I just sent to -hackers which has a much
> > longer and more detailed explanation of what happens.
>
> The next paragraph in the docs is:
>
> If you are at all concerned about password
> <quote>sniffing</> attacks then <literal>md5</> is preferred, with
> <literal>crypt</> a second choice if you must support pre-7.2
> clients. Plain <literal>password</> should especially be avoided for
> connections over the open Internet (unless you use <acronym>SSL</acronym>, SSH, or
> other communications security wrappers around the connection).

Huh, I thought I had looked and hadn't seen anything after the paragraph
you modified in the online stuff. Apparently I was being deliusional.
Even so though, I think my description was somewhat more verbose and
useful. A merge of the two may be in order actually, it's true that
sniffing attacks may be thwarted by the md5 method but this does not
mention that the hash in pg_shadow becomes password-equivilant in that
method and it really should.

Thanks,

Stephen

Stephen Frost <sfrost(at)snowman(dot)net> writes:

> With the 'md5' method the server will send will send a randomly
> generated salt to the client which will then concatenate the user's name
> to the password, perform an md5 on that result, then concatenate the
> result of the md5 to the salt provided by the server and will then md5
> that.

I think that in this case calling it a salt altogether is wrong. It's a
"challenge".

And I'm inclined to suggest that this authentication method be removed
altogether. The security flaw is that it exists at all. Not the details of the
implementation.

--
greg

Greg Stark wrote:
> Stephen Frost <sfrost(at)snowman(dot)net> writes:
>
> > With the 'md5' method the server will send will send a randomly
> > generated salt to the client which will then concatenate the user's name
> > to the password, perform an md5 on that result, then concatenate the
> > result of the md5 to the salt provided by the server and will then md5
> > that.
>
> I think that in this case calling it a salt altogether is wrong. It's a
> "challenge".
>
> And I'm inclined to suggest that this authentication method be removed
> altogether. The security flaw is that it exists at all. Not the details of the
> implementation.

That idea is so detached from reality, I don't know how to respond.

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

* Greg Stark (gsstark(at)mit(dot)edu) wrote:
> Stephen Frost <sfrost(at)snowman(dot)net> writes:
> > With the 'md5' method the server will send will send a randomly
> > generated salt to the client which will then concatenate the user's name
> > to the password, perform an md5 on that result, then concatenate the
> > result of the md5 to the salt provided by the server and will then md5
> > that.
>
> I think that in this case calling it a salt altogether is wrong. It's a
> "challenge".

Ah, yeah, you're right.

> And I'm inclined to suggest that this authentication method be removed
> altogether. The security flaw is that it exists at all. Not the details of the
> implementation.

I'm not quite sure it's as dire as all that. It's intended to solve a
different problem. As I recall, Kerberos does much the same, it takes
the password, the user's princ, performs a hash and uses *that* as
password-equiv by using it as the key to encrypt with. One big reason
why you had better be *very* careful with your KDC, and why the KDC
encrypts its database again with the Master KDC password. Additionally,
KDCs can be locked down and you can pretty easily set up slaves of them
for backup purposes and just not put the Master KDC password on the
system anywhere and type it in by hand when bringing up the system.

Unfortunately, Postgres doesn't currently encrypt pg_shadow and even if
it did you'd have to have the password stored on disk somewhere in the
clear if you wanted the database to start automatically, which is more
important if you havn't got backup databases and whatnot (which aren't
really as easy to set up w/ Postgres and generally Postgres requires
more disk space than a KDC).

Stephen

Stephen Frost wrote:
> Unfortunately, Postgres doesn't currently encrypt pg_shadow and even if
> it did you'd have to have the password stored on disk somewhere in the
> clear if you wanted the database to start automatically, which is more
> important if you havn't got backup databases and whatnot (which aren't
> really as easy to set up w/ Postgres and generally Postgres requires
> more disk space than a KDC).

Yeah, but who cares? If the attacker has enough access to the box
that they can grab the stored master password, then they can modify
the postgresql binaries and intercept the salt information (at a
minimum) as it's being sent to the client anyway.

That's because in any sane implementation, you'd store the master
password in a root-readable-only file, and have Postgres start up as
root, grab the password, and then immediately setuid() to the postgres
account, so that accessing the database itself isn't enough to allow
you to compromise the master password. If they can grab the master
password with that setup, then they have root on the box anyway and
can do anything they want.

--
Kevin Brown kevin(at)sysexperts(dot)com

* Kevin Brown (kevin(at)sysexperts(dot)com) wrote:
> Stephen Frost wrote:
> > Unfortunately, Postgres doesn't currently encrypt pg_shadow and even if
> > it did you'd have to have the password stored on disk somewhere in the
> > clear if you wanted the database to start automatically, which is more
> > important if you havn't got backup databases and whatnot (which aren't
> > really as easy to set up w/ Postgres and generally Postgres requires
> > more disk space than a KDC).
>
> Yeah, but who cares? If the attacker has enough access to the box
> that they can grab the stored master password, then they can modify
> the postgresql binaries and intercept the salt information (at a
> minimum) as it's being sent to the client anyway.

Security in layers *is* good. It is not unlikely that an attacker would
be able to gain enough access to read some small portion of protected
data without having full root access to the system. Your argument would
suggest that we should put plaintext passwords in /etc/shadow and that
there's no reason for a KDC to encrypt its database.

> That's because in any sane implementation, you'd store the master
> password in a root-readable-only file, and have Postgres start up as
> root, grab the password, and then immediately setuid() to the postgres
> account, so that accessing the database itself isn't enough to allow
> you to compromise the master password. If they can grab the master
> password with that setup, then they have root on the box anyway and
> can do anything they want.

Postgres won't start, atm anyway, if it's being run as root. You could
have something else do what you're suggesting though, yes. And, yes,
it'd be better than having the master password be readable from the disk
directly as the Postgres user. I certainly wouldn't complain if this
was available in Postgres and it would alliviate some of my concerns
about the 'md5' method in pg_hba.conf.

Stephen