MD5 authentication needs help

Bruce, all,

* Bruce Momjian (bruce@momjian.us) wrote:

It feels like MD5 has accumulated enough problems that we need to start
looking for another way to store and pass passwords. The MD5 problems
are:

1) MD5 makes users feel uneasy (though our usage is mostly safe)

2) The per-session salt sent to the client is only 32-bits, meaning
that it is possible to reply an observed MD5 hash in ~16k connection
attempts.

3) Using the user name for the MD5 storage salt allows the MD5 stored
hash to be used on a different cluster if the user used the same
password.

4) Using the user name for the MD5 storage salt causes the renaming of
a user to break the stored password.

For these reasons, it is probably time to start thinking about a
replacement that fixes these issues. We would keep MD5 but recommend
a better option.

For more background, I'd suggest taking a look at this recent thread:

CA+TgmoaWdkNBT4mNZ+wf=fgjd7aV9bq7NtsvCha7yeoX0LyQPg@mail.gmail.com

Thanks!

Stephen

Bruce, all,

I've been discussing this with a few folks outside of the PG community
(Debian and Openwall people specifically) and a few interesting ideas
have come out of that which might be useful to discuss.

The first is a "don't break anything" approach which would move the
needle between "network data sensitivity" and "on-disk data sensitivity"
a bit back in the direction of making the network data more sensitive.

this approach looks like this: pre-determine and store the values (on a
per-user basis, so a new field in pg_authid or some hack on the existing
field) which will be sent to the client in the AuthenticationMD5Password
message. Further, calculate a random salt to be used when storing data
in pg_authid. Then, for however many variations we feel are necessary,
calculate and store, for each AuthenticationMD5Password value:

md5_challenge, hash(salt || response)

We wouldn't store 4 billion of these, of course, which means that the
challenge / response system becomes less effective on a per-user basis.
We could, however, store X number of these and provide a lock-out
mechanism (something users have asked after for a long time..) which
would make it likely that the account would be locked before the
attacker was able to gain access. Further, an attacker with access to
the backend still wouldn't see the user's cleartext password, nor would
we store the cleartext password or a token in pg_authid which could be
directly used for authentication, and we don't break the wireline
protocol or existing installations (since we could detect that the
pg_authid entry has the old-style and simply 'upgrade' it).

That's probably the extent of what we could do to improve the current
'md5' approach without breaking the wireline protocol or existing stored
data.

A lot of discussion has been going on with SCRAM and SASL, which is all
great, but that means we end up with a dependency on SASL or we have to
reimplement SCRAM (which I've been thinking might not be a bad idea-
it's actually not that hard), but another suggestion was made which may
be worthwhile to consider- OpenSSL and GnuTLS both support TLS-SRP, the
RFC for which is here: http://www.ietf.org/rfc/rfc5054.txt. We already
have OpenSSL and therefore this wouldn't create any new dependencies and
might be slightly simpler to implement.

Thoughts?

Thanks!

Stephen

On Wed, Mar 4, 2015 at 4:52 PM, Stephen Frost <sfrost@snowman.net> wrote:

A lot of discussion has been going on with SCRAM and SASL, which is all
great, but that means we end up with a dependency on SASL or we have to
reimplement SCRAM (which I've been thinking might not be a bad idea-
it's actually not that hard), but another suggestion was made which may

I'd really rather not add a dependency on SASL if we can avoid it. I
haven't read up on SCRAM, but if it's reasonable enough to reimplement - or
if there is a BSD licensed implementation that we can import into our own
sourcetree without adding a dependency on SASL, that sounds like a good way
to proceed.

be worthwhile to consider- OpenSSL and GnuTLS both support TLS-SRP, the
RFC for which is here: http://www.ietf.org/rfc/rfc5054.txt. We already
have OpenSSL and therefore this wouldn't create any new dependencies and
might be slightly simpler to implement.

OpenSSL is not a *requirement* today, it's an optional dependency. Given
it's license we really can't make it a mandatory requirement I think. So if
we go down that route, we still leave md5 in there as the one that works
everywhere.

Also AFAICT TLS-SRP actually requires the connection to be over TLS - so
are you suggesting that TLS becomes mandatory?

It sounds like something that could be interesting to have, but not as a
solution to the "md5 problem", imo.

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

Hi,

On 2015-03-04 10:52:30 -0500, Stephen Frost wrote:

I've been discussing this with a few folks outside of the PG community
(Debian and Openwall people specifically) and a few interesting ideas
have come out of that which might be useful to discuss.

The first is a "don't break anything" approach which would move the
needle between "network data sensitivity" and "on-disk data sensitivity"
a bit back in the direction of making the network data more sensitive.

I think that's a really bad tradeoff for pg. There's pretty good reasons
not to encrypt database connections. I don't think you really can
compare routinely encrypted stuff like imap and submission with
pg. Neither is it as harmful to end up with leaked hashes for database
users as it is for a email provider's authentication database.

A lot of discussion has been going on with SCRAM and SASL, which is all
great, but that means we end up with a dependency on SASL or we have to
reimplement SCRAM (which I've been thinking might not be a bad idea-
it's actually not that hard), but another suggestion was made which may
be worthwhile to consider- OpenSSL and GnuTLS both support TLS-SRP, the
RFC for which is here: http://www.ietf.org/rfc/rfc5054.txt. We already
have OpenSSL and therefore this wouldn't create any new dependencies and
might be slightly simpler to implement.

We don't have a hard dependency openssl, so I can't really see that
being a fully viable alternative to md5 TBH.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Magnus,

* Magnus Hagander (magnus@hagander.net) wrote:

On Wed, Mar 4, 2015 at 4:52 PM, Stephen Frost <sfrost@snowman.net> wrote:

A lot of discussion has been going on with SCRAM and SASL, which is all
great, but that means we end up with a dependency on SASL or we have to
reimplement SCRAM (which I've been thinking might not be a bad idea-
it's actually not that hard), but another suggestion was made which may

I'd really rather not add a dependency on SASL if we can avoid it. I
haven't read up on SCRAM, but if it's reasonable enough to reimplement - or
if there is a BSD licensed implementation that we can import into our own
sourcetree without adding a dependency on SASL, that sounds like a good way
to proceed.

I actually like the idea of supporting SASL generally, but I agree that
we don't really want to force it as a dependency. I've started looking
around for BSD-licensed SCRAM implementations and will update with any I
find that are worthwhile to review.

be worthwhile to consider- OpenSSL and GnuTLS both support TLS-SRP, the
RFC for which is here: http://www.ietf.org/rfc/rfc5054.txt. We already
have OpenSSL and therefore this wouldn't create any new dependencies and
might be slightly simpler to implement.

OpenSSL is not a *requirement* today, it's an optional dependency. Given
it's license we really can't make it a mandatory requirement I think. So if
we go down that route, we still leave md5 in there as the one that works
everywhere.

Also AFAICT TLS-SRP actually requires the connection to be over TLS - so
are you suggesting that TLS becomes mandatory?

It sounds like something that could be interesting to have, but not as a
solution to the "md5 problem", imo.

No, I'm not suggesting that OpenSSL or TLS become mandatory but was
thinking it might be good alternative as a middle-ground between full
client-and-server side certificates and straight password-based auth
(which is clearly why it was invented in the first place) and so, yes,
md5 would still have to be kept around, but we'd at least be able to
deprecate it and tell people "Use TLS-SRP if you really want to use
passwords and care about network security".

SCRAM doesn't actually fix the issue with network connection hijacking
or eavesdropping, except to the extent that it protects the password
itself, and so we might want to recommend, for people who are worried
about network-based attacks, using TLS-SRP.

Thanks!

Stephen

On Wed, Mar 4, 2015 at 5:03 PM, Stephen Frost <sfrost@snowman.net> wrote:

Magnus,

* Magnus Hagander (magnus@hagander.net) wrote:

On Wed, Mar 4, 2015 at 4:52 PM, Stephen Frost <sfrost@snowman.net>

wrote:

A lot of discussion has been going on with SCRAM and SASL, which is all
great, but that means we end up with a dependency on SASL or we have to
reimplement SCRAM (which I've been thinking might not be a bad idea-
it's actually not that hard), but another suggestion was made which may

I'd really rather not add a dependency on SASL if we can avoid it. I
haven't read up on SCRAM, but if it's reasonable enough to reimplement -

or

if there is a BSD licensed implementation that we can import into our own
sourcetree without adding a dependency on SASL, that sounds like a good

way

to proceed.

I actually like the idea of supporting SASL generally, but I agree that
we don't really want to force it as a dependency. I've started looking
around for BSD-licensed SCRAM implementations and will update with any I
find that are worthwhile to review.

be worthwhile to consider- OpenSSL and GnuTLS both support TLS-SRP, the
RFC for which is here: http://www.ietf.org/rfc/rfc5054.txt. We

already

have OpenSSL and therefore this wouldn't create any new dependencies

and

might be slightly simpler to implement.

OpenSSL is not a *requirement* today, it's an optional dependency. Given
it's license we really can't make it a mandatory requirement I think. So

if

we go down that route, we still leave md5 in there as the one that works
everywhere.

Also AFAICT TLS-SRP actually requires the connection to be over TLS - so
are you suggesting that TLS becomes mandatory?

It sounds like something that could be interesting to have, but not as a
solution to the "md5 problem", imo.

No, I'm not suggesting that OpenSSL or TLS become mandatory but was
thinking it might be good alternative as a middle-ground between full
client-and-server side certificates and straight password-based auth
(which is clearly why it was invented in the first place) and so, yes,
md5 would still have to be kept around, but we'd at least be able to
deprecate it and tell people "Use TLS-SRP if you really want to use
passwords and care about network security".

SCRAM doesn't actually fix the issue with network connection hijacking
or eavesdropping, except to the extent that it protects the password
itself, and so we might want to recommend, for people who are worried
about network-based attacks, using TLS-SRP.

Assuming we do implement SCRAM, what does TLS-SRP give us that we wouldn't
get by just using SCRAM over a TLS connection?

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

* Andres Freund (andres@2ndquadrant.com) wrote:

Hi,

On 2015-03-04 10:52:30 -0500, Stephen Frost wrote:

I've been discussing this with a few folks outside of the PG community
(Debian and Openwall people specifically) and a few interesting ideas
have come out of that which might be useful to discuss.

The first is a "don't break anything" approach which would move the
needle between "network data sensitivity" and "on-disk data sensitivity"
a bit back in the direction of making the network data more sensitive.

I think that's a really bad tradeoff for pg. There's pretty good reasons
not to encrypt database connections. I don't think you really can
compare routinely encrypted stuff like imap and submission with
pg. Neither is it as harmful to end up with leaked hashes for database
users as it is for a email provider's authentication database.

I'm confused.. The paragraph you reply to here discusses an approach
which doesn't include encrypting the database connection.

A lot of discussion has been going on with SCRAM and SASL, which is all
great, but that means we end up with a dependency on SASL or we have to
reimplement SCRAM (which I've been thinking might not be a bad idea-
it's actually not that hard), but another suggestion was made which may
be worthwhile to consider- OpenSSL and GnuTLS both support TLS-SRP, the
RFC for which is here: http://www.ietf.org/rfc/rfc5054.txt. We already
have OpenSSL and therefore this wouldn't create any new dependencies and
might be slightly simpler to implement.

We don't have a hard dependency openssl, so I can't really see that
being a fully viable alternative to md5 TBH.

Right, agreed, that wasn't intended to be a complete replacement for md5
but rather an additional auth mechanism we could get nearly "for free"
which would provide password-based authentication with network-level
encryption for users who are worried about network-based attacks (and
therefore want to or are already using TLS, as Debian is configured to
do by default...).

Thanks!

Stephen

On 2015-03-04 11:06:33 -0500, Stephen Frost wrote:

* Andres Freund (andres@2ndquadrant.com) wrote:

On 2015-03-04 10:52:30 -0500, Stephen Frost wrote:

The first is a "don't break anything" approach which would move the
needle between "network data sensitivity" and "on-disk data sensitivity"
a bit back in the direction of making the network data more sensitive.

I think that's a really bad tradeoff for pg. There's pretty good reasons
not to encrypt database connections. I don't think you really can
compare routinely encrypted stuff like imap and submission with
pg. Neither is it as harmful to end up with leaked hashes for database
users as it is for a email provider's authentication database.

I'm confused.. The paragraph you reply to here discusses an approach
which doesn't include encrypting the database connection.

An increase in "network data sensitivity" also increases the need for
encryption.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

* Magnus Hagander (magnus@hagander.net) wrote:

On Wed, Mar 4, 2015 at 5:03 PM, Stephen Frost <sfrost@snowman.net> wrote:

No, I'm not suggesting that OpenSSL or TLS become mandatory but was
thinking it might be good alternative as a middle-ground between full
client-and-server side certificates and straight password-based auth
(which is clearly why it was invented in the first place) and so, yes,
md5 would still have to be kept around, but we'd at least be able to
deprecate it and tell people "Use TLS-SRP if you really want to use
passwords and care about network security".

SCRAM doesn't actually fix the issue with network connection hijacking
or eavesdropping, except to the extent that it protects the password
itself, and so we might want to recommend, for people who are worried
about network-based attacks, using TLS-SRP.

Assuming we do implement SCRAM, what does TLS-SRP give us that we wouldn't
get by just using SCRAM over a TLS connection?

Good question and I'll have to dig more into that. SCRAM does appear to
support channel binding with TLS and therefore there might not be much
to be gained from having both.

Thanks!

Stephen

* Andres Freund (andres@2ndquadrant.com) wrote:

On 2015-03-04 11:06:33 -0500, Stephen Frost wrote:

* Andres Freund (andres@2ndquadrant.com) wrote:

On 2015-03-04 10:52:30 -0500, Stephen Frost wrote:

The first is a "don't break anything" approach which would move the
needle between "network data sensitivity" and "on-disk data sensitivity"
a bit back in the direction of making the network data more sensitive.

I think that's a really bad tradeoff for pg. There's pretty good reasons
not to encrypt database connections. I don't think you really can
compare routinely encrypted stuff like imap and submission with
pg. Neither is it as harmful to end up with leaked hashes for database
users as it is for a email provider's authentication database.

I'm confused.. The paragraph you reply to here discusses an approach
which doesn't include encrypting the database connection.

An increase in "network data sensitivity" also increases the need for
encryption.

Ok, I see what you're getting at there, though our existing md5
implementation with no lock-out mechanism or ability to deal with
hijacking isn't exactly making us all that safe when it comes to network
based attacks. The best part about md5 is that we don't send the user's
password over the wire in the clear, the actual challenge/response piece
is not considered terribly secure today, nor is the salt+password we use
for pg_authid for that matter. :/

SCRAM won't fix network connection hijacking but it does address replay
attacks better than our current challenge/response system (at least the
example in the RFC uses a 16-byte base64-encoded salt)) and the on-disk
storage risk (multiple iterations are supported), and multiple hashing
algorithms can be supported including ones much better than what we
support today (eg: SHA256) which applies to both network and on-disk
vectors.

Thanks,

Stephen

On Wed, Mar 4, 2015 at 10:52:30AM -0500, Stephen Frost wrote:

The first is a "don't break anything" approach which would move the
needle between "network data sensitivity" and "on-disk data sensitivity"
a bit back in the direction of making the network data more sensitive.

this approach looks like this: pre-determine and store the values (on a
per-user basis, so a new field in pg_authid or some hack on the existing
field) which will be sent to the client in the AuthenticationMD5Password
message. Further, calculate a random salt to be used when storing data
in pg_authid. Then, for however many variations we feel are necessary,
calculate and store, for each AuthenticationMD5Password value:

md5_challenge, hash(salt || response)

We wouldn't store 4 billion of these, of course, which means that the
challenge / response system becomes less effective on a per-user basis.
We could, however, store X number of these and provide a lock-out
mechanism (something users have asked after for a long time..) which
would make it likely that the account would be locked before the
attacker was able to gain access. Further, an attacker with access to
the backend still wouldn't see the user's cleartext password, nor would
we store the cleartext password or a token in pg_authid which could be
directly used for authentication, and we don't break the wireline
protocol or existing installations (since we could detect that the
pg_authid entry has the old-style and simply 'upgrade' it).

What does storing multiple hash(password || stoarage_salt) values do for
us that session_salt doesn't already do?

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Wed, Mar 4, 2015 at 11:36:23AM -0500, Stephen Frost wrote:

* Andres Freund (andres@2ndquadrant.com) wrote:

On 2015-03-04 11:06:33 -0500, Stephen Frost wrote:

* Andres Freund (andres@2ndquadrant.com) wrote:

On 2015-03-04 10:52:30 -0500, Stephen Frost wrote:

The first is a "don't break anything" approach which would move the
needle between "network data sensitivity" and "on-disk data sensitivity"
a bit back in the direction of making the network data more sensitive.

I think that's a really bad tradeoff for pg. There's pretty good reasons
not to encrypt database connections. I don't think you really can
compare routinely encrypted stuff like imap and submission with
pg. Neither is it as harmful to end up with leaked hashes for database
users as it is for a email provider's authentication database.

I'm confused.. The paragraph you reply to here discusses an approach
which doesn't include encrypting the database connection.

An increase in "network data sensitivity" also increases the need for
encryption.

Ok, I see what you're getting at there, though our existing md5
implementation with no lock-out mechanism or ability to deal with
hijacking isn't exactly making us all that safe when it comes to network
based attacks. The best part about md5 is that we don't send the user's
password over the wire in the clear, the actual challenge/response piece

----- here is where I was lost

is not considered terribly secure today, nor is the salt+password we use
for pg_authid for that matter. :/

Can you please rephrase the last sentence as it doesn't make sense to
me?

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

* Bruce Momjian (bruce@momjian.us) wrote:

On Wed, Mar 4, 2015 at 10:52:30AM -0500, Stephen Frost wrote:

The first is a "don't break anything" approach which would move the
needle between "network data sensitivity" and "on-disk data sensitivity"
a bit back in the direction of making the network data more sensitive.

this approach looks like this: pre-determine and store the values (on a
per-user basis, so a new field in pg_authid or some hack on the existing
field) which will be sent to the client in the AuthenticationMD5Password
message. Further, calculate a random salt to be used when storing data
in pg_authid. Then, for however many variations we feel are necessary,
calculate and store, for each AuthenticationMD5Password value:

md5_challenge, hash(salt || response)

We wouldn't store 4 billion of these, of course, which means that the
challenge / response system becomes less effective on a per-user basis.
We could, however, store X number of these and provide a lock-out
mechanism (something users have asked after for a long time..) which
would make it likely that the account would be locked before the
attacker was able to gain access. Further, an attacker with access to
the backend still wouldn't see the user's cleartext password, nor would
we store the cleartext password or a token in pg_authid which could be
directly used for authentication, and we don't break the wireline
protocol or existing installations (since we could detect that the
pg_authid entry has the old-style and simply 'upgrade' it).

What does storing multiple hash(password || stoarage_salt) values do for
us that session_salt doesn't already do?

By storing a hash of the result of the challenge/response, we wouldn't
be susceptible to attacks where the user has gained access to the
contents of pg_authid because the values there would not be (directly)
useful for authentication. Today, an attacker can take what's in
pg_authid and directly use it to authenticate (which is what the
interwebs are complaining about).

We wouldn't want to do that for just a single value though because then
there wouldn't be any value to the challenge/response system (which is
intended to prevent replay attacks where the attacker has sniffed a
value from the network and then uses that value to authenticate
themselves).

The only way we can keep the session salt random without breaking the
wireline protocol is to keep the raw data necessary for authentication
in pg_authid (as we do now) since we'd need that information to recreate
the results of the random session salt+user-hash for comparison.

This is essentially a middle ground which maintains the existing
wireline protocol while changing what is in pg_authid to be something
that an attacker can't trivially use to authenticate. It is not a
proper solution as that requires changing the wireline protocol (or,
really, extending it with another auth method that's better).

Thanks,

Stephen

* Bruce Momjian (bruce@momjian.us) wrote:

On Wed, Mar 4, 2015 at 11:36:23AM -0500, Stephen Frost wrote:

* Andres Freund (andres@2ndquadrant.com) wrote:

On 2015-03-04 11:06:33 -0500, Stephen Frost wrote:

* Andres Freund (andres@2ndquadrant.com) wrote:

On 2015-03-04 10:52:30 -0500, Stephen Frost wrote:

The first is a "don't break anything" approach which would move the
needle between "network data sensitivity" and "on-disk data sensitivity"
a bit back in the direction of making the network data more sensitive.

I think that's a really bad tradeoff for pg. There's pretty good reasons
not to encrypt database connections. I don't think you really can
compare routinely encrypted stuff like imap and submission with
pg. Neither is it as harmful to end up with leaked hashes for database
users as it is for a email provider's authentication database.

I'm confused.. The paragraph you reply to here discusses an approach
which doesn't include encrypting the database connection.

An increase in "network data sensitivity" also increases the need for
encryption.

Ok, I see what you're getting at there, though our existing md5
implementation with no lock-out mechanism or ability to deal with
hijacking isn't exactly making us all that safe when it comes to network
based attacks. The best part about md5 is that we don't send the user's
password over the wire in the clear, the actual challenge/response piece

----- here is where I was lost

is not considered terribly secure today, nor is the salt+password we use
for pg_authid for that matter. :/

Can you please rephrase the last sentence as it doesn't make sense to
me?

The best part of the existing authentication method we call "md5" is
that the user's password is never sent over the network in the clear.

The challenge/response implementation we have only provides for 4 bytes
of hash (or around four billion possible permutations) which is not very
secure today (as compared to the 16-character base64 salt used in SCRAM,
which is 16^64 or 2^96 instead of 2^32).

Thanks,

Stephen

* Stephen Frost (sfrost@snowman.net) wrote:

* Bruce Momjian (bruce@momjian.us) wrote:

On Wed, Mar 4, 2015 at 11:36:23AM -0500, Stephen Frost wrote:

* Andres Freund (andres@2ndquadrant.com) wrote:

On 2015-03-04 11:06:33 -0500, Stephen Frost wrote:

* Andres Freund (andres@2ndquadrant.com) wrote:

On 2015-03-04 10:52:30 -0500, Stephen Frost wrote:

The first is a "don't break anything" approach which would move the
needle between "network data sensitivity" and "on-disk data sensitivity"
a bit back in the direction of making the network data more sensitive.

I think that's a really bad tradeoff for pg. There's pretty good reasons
not to encrypt database connections. I don't think you really can
compare routinely encrypted stuff like imap and submission with
pg. Neither is it as harmful to end up with leaked hashes for database
users as it is for a email provider's authentication database.

I'm confused.. The paragraph you reply to here discusses an approach
which doesn't include encrypting the database connection.

An increase in "network data sensitivity" also increases the need for
encryption.

Ok, I see what you're getting at there, though our existing md5
implementation with no lock-out mechanism or ability to deal with
hijacking isn't exactly making us all that safe when it comes to network
based attacks. The best part about md5 is that we don't send the user's
password over the wire in the clear, the actual challenge/response piece

----- here is where I was lost

is not considered terribly secure today, nor is the salt+password we use
for pg_authid for that matter. :/

Can you please rephrase the last sentence as it doesn't make sense to
me?

The best part of the existing authentication method we call "md5" is
that the user's password is never sent over the network in the clear.

The challenge/response implementation we have only provides for 4 bytes
of hash (or around four billion possible permutations) which is not very
secure today (as compared to the 16-character base64 salt used in SCRAM,
which is 16^64 or 2^96 instead of 2^32).

Err, 64^16 or 2^96, that is. 16^64 is not the same and would be way
larger. :)

Thanks!

Stephen

On Wed, Mar 4, 2015 at 12:43:54PM -0500, Stephen Frost wrote:

What does storing multiple hash(password || stoarage_salt) values do for
us that session_salt doesn't already do?

By storing a hash of the result of the challenge/response, we wouldn't
be susceptible to attacks where the user has gained access to the
contents of pg_authid because the values there would not be (directly)
useful for authentication. Today, an attacker can take what's in
pg_authid and directly use it to authenticate (which is what the
interwebs are complaining about).

We wouldn't want to do that for just a single value though because then
there wouldn't be any value to the challenge/response system (which is
intended to prevent replay attacks where the attacker has sniffed a
value from the network and then uses that value to authenticate
themselves).

So you are storing the password + storage-salt + session-saltX, where X
is greater than the maximum number of login attempts? How do you know
the attacker will not be given a salt that was already seen before?

The only way we can keep the session salt random without breaking the
wireline protocol is to keep the raw data necessary for authentication
in pg_authid (as we do now) since we'd need that information to recreate
the results of the random session salt+user-hash for comparison.

This is essentially a middle ground which maintains the existing
wireline protocol while changing what is in pg_authid to be something
that an attacker can't trivially use to authenticate. It is not a

I don't understand how this works.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

* Bruce Momjian (bruce@momjian.us) wrote:

On Wed, Mar 4, 2015 at 12:43:54PM -0500, Stephen Frost wrote:

What does storing multiple hash(password || stoarage_salt) values do for
us that session_salt doesn't already do?

By storing a hash of the result of the challenge/response, we wouldn't
be susceptible to attacks where the user has gained access to the
contents of pg_authid because the values there would not be (directly)
useful for authentication. Today, an attacker can take what's in
pg_authid and directly use it to authenticate (which is what the
interwebs are complaining about).

We wouldn't want to do that for just a single value though because then
there wouldn't be any value to the challenge/response system (which is
intended to prevent replay attacks where the attacker has sniffed a
value from the network and then uses that value to authenticate
themselves).

So you are storing the password + storage-salt + session-saltX, where X
is greater than the maximum number of login attempts? How do you know
the attacker will not be given a salt that was already seen before?

The password isn't stored and I don't know what you're talking about
regarding the number of login attempts. Further, we don't know today if
an attacker has seen a particular challege/response sequence or not (nor
can we...) and we can certainly repeat it.

The only way we can keep the session salt random without breaking the
wireline protocol is to keep the raw data necessary for authentication
in pg_authid (as we do now) since we'd need that information to recreate
the results of the random session salt+user-hash for comparison.

This is essentially a middle ground which maintains the existing
wireline protocol while changing what is in pg_authid to be something
that an attacker can't trivially use to authenticate. It is not a

I don't understand how this works.

Ok, let me try to explain it another way.

The current system looks like this:

client has username and password
server has hash(username + password)

client:

send auth request w/ username and database

server:

send random salt to client

client:

send hash(hash(username + password) + salt) to server

server:

calculate hash(hash(username + password) + salt)
compare to what client sent

What the interwebs are complaining about is that the
"hash(username + password)" piece that's stored in pg_authid is
sufficient to authenticate.

Here's what was proposed as an alternative which would prevent that
without breaking the existing wireline protocol:

client has username and password
server has user_salt,
N *
{salt, hash(hash(hash(username + password) + salt), user_salt)}

client:

send auth request w/ username and database

server:

picks random salt from the salts available for this user
sends salt to the user

client:

send hash(hash(username + password) + salt) to server

server:

server calculates, using the data from the client,
hash(FROM_CLIENT + user_salt)
compares to hash stored for salt chosen

This makes what is stored in pg_authid no longer directly useful for
authentication (similar to how Unix passwd-based authentication works)
because if the client sent any of those values, we'd add the user_salt
and hash it again and it wouldn't match what's stored.

This further makes what is sent over the network not directly
susceptible to a replay attack because the server has multiple values
available to pick for the salt to use and sends one at random to the
client, exactly how our current challenge/response replay-prevention
system works. The downside is that the number of possible values for
the server to send to prevent replay attacke is reduced from 2^32 to N.

To mitigate the replay risk we would, ideally, support a lock-out
mechanism. This won't help if the attacker has extended network access
though as we would almost certainly eventually go through all N
permutations for this user.

However, use of TLS would prevent the network-based attack vector.

Using TLS + the 'password' authentication mechanism would also achieve
the goal of making what is in pg_authid not directly useful for
authentication, but that would mean that the postmaster would see the
user's password (post-decryption), leading to a risk that the password
could be reused for access to other systems by a rogue server
administrator. Now, that's what SSH and *most* systems have had for
ages when it comes to password-based authentication and therefore it's
well understood in the industry and session-level encryption is
generally considered to avoid the network-based vector associated with
that approach.

For PG users, however, we encourage using md5 instead of password as we
consider that "better", but users familiar with SSH and other
unix-password based authentication mechanisms might, understandably,
think that MD5+TLS prevents both attack vectors, but it doesn't.
Password+TLS is what they would actually want to get the traditional
unix-password-style trade-offs.

Of course, the hashing algorithm used for all of the current
authentication systems we support is no longer generally considered
secure and that we use a non-random salt for storage (the username)
makes it worse.

Thanks!

Stephen

On 03/04/2015 04:52 PM, Stephen Frost wrote:

Bruce, all,

I've been discussing this with a few folks outside of the PG community
(Debian and Openwall people specifically) and a few interesting ideas
have come out of that which might be useful to discuss.

The first is a "don't break anything" approach which would move the
needle between "network data sensitivity" and "on-disk data sensitivity"
a bit back in the direction of making the network data more sensitive.

this approach looks like this: pre-determine and store the values (on a
per-user basis, so a new field in pg_authid or some hack on the existing
field) which will be sent to the client in the AuthenticationMD5Password
message. Further, calculate a random salt to be used when storing data
in pg_authid. Then, for however many variations we feel are necessary,
calculate and store, for each AuthenticationMD5Password value:

md5_challenge, hash(salt || response)

We wouldn't store 4 billion of these, of course, which means that the
challenge / response system becomes less effective on a per-user basis.
We could, however, store X number of these and provide a lock-out
mechanism (something users have asked after for a long time..) which
would make it likely that the account would be locked before the
attacker was able to gain access. Further, an attacker with access to
the backend still wouldn't see the user's cleartext password, nor would
we store the cleartext password or a token in pg_authid which could be
directly used for authentication, and we don't break the wireline
protocol or existing installations (since we could detect that the
pg_authid entry has the old-style and simply 'upgrade' it).

That's probably the extent of what we could do to improve the current
'md5' approach without breaking the wireline protocol or existing stored
data.

A lot of discussion has been going on with SCRAM and SASL, which is all
great, but that means we end up with a dependency on SASL or we have to
reimplement SCRAM (which I've been thinking might not be a bad idea-
it's actually not that hard), but another suggestion was made which may
be worthwhile to consider- OpenSSL and GnuTLS both support TLS-SRP, the
RFC for which is here: http://www.ietf.org/rfc/rfc5054.txt. We already
have OpenSSL and therefore this wouldn't create any new dependencies and
might be slightly simpler to implement.

not sure we should depend on TLS-SRP - the libressl people removed the
support for SRP pretty early in the development process:
https://github.com/libressl/libressl/commit/f089354ca79035afce9ec649f54c18711a950ecd

Stefan

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 03/04/2015 06:11 PM, Stephen Frost wrote:

* Magnus Hagander (magnus@hagander.net) wrote:

On Wed, Mar 4, 2015 at 5:03 PM, Stephen Frost <sfrost@snowman.net> wrote:

No, I'm not suggesting that OpenSSL or TLS become mandatory but was
thinking it might be good alternative as a middle-ground between full
client-and-server side certificates and straight password-based auth
(which is clearly why it was invented in the first place) and so, yes,
md5 would still have to be kept around, but we'd at least be able to
deprecate it and tell people "Use TLS-SRP if you really want to useou
passwords and care about network security".

SCRAM doesn't actually fix the issue with network connection hijacking
or eavesdropping, except to the extent that it protects the password
itself, and so we might want to recommend, for people who are worried
about network-based attacks, using TLS-SRP.

Assuming we do implement SCRAM, what does TLS-SRP give us that we wouldn't
get by just using SCRAM over a TLS connection?

Good question and I'll have to dig more into that. SCRAM does appear to
support channel binding with TLS and therefore there might not be much
to be gained from having both.

The big difference between SRP and SCRAM is that if you eavesdrop the
SCRAM handshake, you can use that information to launch a brute-force or
dictionary attack. With SRP, you cannot do that. That makes it
relatively safe to use weak passwords with SRP, which is not the case
with SCRAM (nor MD5)

Let me list the possible attacks that we're trying to protect against:

A) Eve eavesdrops on the authentication exchange. Can she use the
information gathered directly to authenticate to the server?

B) Can Eve use the information to launch a dictionary or brute force the
password?

C) Can a malicious server impersonate the real server? (i.e. does the
protocol not authenticate the server to the client)

D) If Eve obtains a copy pg_authid (e.g from a backup tape), can she use
that information to authenticate directly? (Brute forcing the passwords
is always possible in this case)

A) B) C) D)
password Yes Yes Yes No [1]assuming that pg_authid stored MD5 hashes, not plaintext passwords, which should be the case these days.
MD5 No Yes Yes Yes
SCRAM No Yes No No
SRP No No No No

[1]: assuming that pg_authid stored MD5 hashes, not plaintext passwords, which should be the case these days.
which should be the case these days.

Note that this table does not consider how difficult a brute-force
attack is in each case; MD5 is a lot cheaper to calculate than SCRAM or
SRP hashes. And there are more things to consider like implementation
effort, strength of the underlying hash and other algorithms etc.

Also, attacks A), B) and C) can be thwarted by using SSL, with the
client configured to check the server certificate (sslmode=verify-full).
So actually, password authentication with SSL is not a bad option at
all; it's actually better than MD5 because it doesn't allow attack D).

- Heikki

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers