SASL was done by many of the same people who did GSSAPI. It's main practical
advantages are that it supports password-based mechanisms (in addition to
GSSAPI/krb5), and that it’s more explicitly pluggable than GSSAPI is.
The password mechanism is simple enough that it's frequently implemented
On 02/11/2015 03:55 PM, Claudio Freire wrote:
On 02/11/2015 03:39 PM, Claudio Freire wrote:
[snip]
Seems the risk of someone either lifting pg_authid from disk or by hacking
the system and being postgres, thereby accessing passwords stored
somewhere
else, is actually the bigger problem. But
On Tue, Feb 10, 2015 at 09:30:37PM -0500, Tom Lane wrote:
I think it would be wise to take two steps back and think about what
the threat model is here, and what we actually need to improve.
Offhand I can remember two distinct things we might wish to have more
protection against:
* scraping
All,
* Heikki Linnakangas (hlinnakan...@vmware.com) wrote:
On 02/11/2015 05:57 AM, Tom Lane wrote:
In any case, my larger point was that given the pain that we're going to
incur here, and the certainly years-long transition interval involved,
it would be foolish to think only about replacing
* Heikki Linnakangas (hlinnakan...@vmware.com) wrote:
Let's do this properly. I can help with that,
although I don't know if I'll find the time and enthusiasm to do all
of it alone.
Agreed- let's do it properly. This is definitely an area of interest
for me and if I can ever get out from
On 02/11/2015 07:54 AM, José Luis Tallón wrote:
On 02/11/2015 04:40 PM, Tom Lane wrote:
=?UTF-8?B?Sm9zw6kgTHVpcyBUYWxsw7Nu?= jltal...@adv-solutions.net writes:
In any case, just storing the password BLOB(text or base64 encoded)
along with a mechanism identifier would go a long way towards
On Wed, Feb 11, 2015 at 10:31 AM, Magnus Hagander mag...@hagander.net wrote:
On Wed, Feb 11, 2015 at 4:57 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Feb 10, 2015 at 9:30 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Another thing we need to keep in
On 02/11/2015 03:39 PM, Claudio Freire wrote:
[snip]
Seems the risk of someone either lifting pg_authid from disk or by hacking
the system and being postgres, thereby accessing passwords stored somewhere
else, is actually the bigger problem. But also one that should be reasonably
easy (TM) to
On Wed, Feb 11, 2015 at 3:10 PM, José Luis Tallón
jltal...@adv-solutions.net wrote:
On 02/11/2015 02:31 PM, Magnus Hagander wrote:
In any case, my larger point was that given the pain that we're going to
incur here, and the certainly years-long transition interval involved,
it would be
On 02/11/2015 03:14 PM, Magnus Hagander wrote:
[snip]
The hash value in pg_authid already contains md5 as a prefix. No
need for another column.
Yes, but for variable length mechanism names (i.e. not just 3 chars) it
would become increasingly difficult to differentiate between the algo
name
On Wed, Feb 11, 2015 at 11:48 AM, José Luis Tallón
jltal...@adv-solutions.net wrote:
On 02/11/2015 03:39 PM, Claudio Freire wrote:
[snip]
Seems the risk of someone either lifting pg_authid from disk or by hacking
the system and being postgres, thereby accessing passwords stored
somewhere
On Wed, Feb 11, 2015 at 12:20 PM, José Luis Tallón
jltal...@adv-solutions.net wrote:
Both seem a step backwards IMO.
Hmmm... as opposed to breaking applications innecesarily when simply
enabling SSL/TLS would not make it insecure? or when users don't really need
it?
No, as opposed to cases
On 02/11/2015 04:40 PM, Tom Lane wrote:
=?UTF-8?B?Sm9zw6kgTHVpcyBUYWxsw7Nu?= jltal...@adv-solutions.net writes:
In any case, just storing the password BLOB(text or base64 encoded)
along with a mechanism identifier would go a long way towards making
this part pluggable... just like we do with
On Wed, Feb 11, 2015 at 8:02 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 02/11/2015 02:49 PM, Robert Haas wrote:
So, this all sounds fairly nice if somebody's willing to do the work,
but I can't help noticing that you originally proposed adopting SCRAM
in 2012, and it's 2015 now.
=?UTF-8?B?Sm9zw6kgTHVpcyBUYWxsw7Nu?= jltal...@adv-solutions.net writes:
In any case, just storing the password BLOB(text or base64 encoded)
along with a mechanism identifier would go a long way towards making
this part pluggable... just like we do with LDAP/RADIUS/Kerberos/PAM today.
That's
On Wed, Feb 11, 2015 at 6:30 PM, Claudio Freire klaussfre...@gmail.com wrote:
On Wed, Feb 11, 2015 at 5:25 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 02/11/2015 06:35 AM, Claudio Freire wrote:
Usually because handshakes use a random salt on both sides. Not sure
about pg's
On 02/11/2015 05:34 PM, Claudio Freire wrote:
On Wed, Feb 11, 2015 at 12:20 PM, José Luis Tallón
jltal...@adv-solutions.net wrote:
Moreover, requiring everybody to change all passwords and clients *at once*
seems like a very poor decision towards allowing for graceful upgrades and
make rolling
On Wed, Feb 11, 2015 at 5:25 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 02/11/2015 06:35 AM, Claudio Freire wrote:
Usually because handshakes use a random salt on both sides. Not sure
about pg's though, but in general collision strength is required but
not slowness, they're not
On 02/11/2015 11:30 PM, Claudio Freire wrote:
On Wed, Feb 11, 2015 at 5:25 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 02/11/2015 06:35 AM, Claudio Freire wrote:
Usually because handshakes use a random salt on both sides. Not sure
about pg's though, but in general collision
On 02/11/2015 06:35 AM, Claudio Freire wrote:
Usually because handshakes use a random salt on both sides. Not sure
about pg's though, but in general collision strength is required but
not slowness, they're not bruteforceable.
To be precise: collision resistance is usually not important for
On 02/11/2015 03:52 PM, Robert Haas wrote:
On Wed, Feb 11, 2015 at 8:02 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 02/11/2015 02:49 PM, Robert Haas wrote:
So, this all sounds fairly nice if somebody's willing to do the work,
but I can't help noticing that you originally proposed
Heikki Linnakangas hlinnakan...@vmware.com writes:
On 02/11/2015 03:52 PM, Robert Haas wrote:
So are you thinking to integrate with the Cyrus SASL library, or do
you have another thought?
I think we need to implement the primary MD5 replacement ourselves, so
that it's always available
Stephen Frost sfr...@snowman.net writes:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
We've already got a sufficiency of external authentication mechanisms.
If people wanted to use non-built-in authentication, we'd not be having
this discussion.
Just to be clear- lots of people *do* use the
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Stephen Frost sfr...@snowman.net writes:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
We've already got a sufficiency of external authentication mechanisms.
If people wanted to use non-built-in authentication, we'd not be having
this discussion.
Just
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Heikki Linnakangas hlinnakan...@vmware.com writes:
We could also support using a library like that for additional
authentication mechanisms, though, for those who really need them.
We've already got a sufficiency of external authentication
On 02/11/2015 05:57 AM, Tom Lane wrote:
In any case, my larger point was that given the pain that we're going to
incur here, and the certainly years-long transition interval involved,
it would be foolish to think only about replacing the MD5 algorithm and
not about reconsidering the context we
On 02/11/2015 04:38 AM, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
On 2/10/15 8:28 PM, Robert Haas wrote:
I don't actually care which algorithm we use, and I dowannahafta care.
What I do want to do is provide a framework so that, when somebody
discovers that X is better than Y
On Wed, Feb 11, 2015 at 4:13 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
For the first cut, I propose:
1. Implement SASL. The server sends a new AuthenticationSASLRequest message,
to which the client responds with AuthenticationSASLResponse message. These
messages carry the SASL
On 11/02/15 02:30, Tom Lane wrote:
[...]
I think it would be wise to take two steps back and think about what
the threat model is here, and what we actually need to improve.
Offhand I can remember two distinct things we might wish to have more
protection against:
* scraping of passwords off
On 02/11/2015 02:49 PM, Robert Haas wrote:
So, this all sounds fairly nice if somebody's willing to do the work,
but I can't help noticing that you originally proposed adopting SCRAM
in 2012, and it's 2015 now. So I wonder if anyone's really going to
do all this work, and if not, whether we
On Wed, Feb 11, 2015 at 4:57 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Feb 10, 2015 at 9:30 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Another thing we need to keep in mind besides client compatibility
is dump/reload compatibility.
I don't
On Tue, Feb 10, 2015 at 5:22 PM, Arthur Silva arthur...@gmail.com wrote:
I assume if the hacker can intercept the server unencrypted traffic and/or
has access to its hard-drive the database is compromised anyway.
That sounds like an argument against hashing the passwords in general.
--
Peter
On Tue, Feb 10, 2015 at 7:32 PM, Peter Geoghegan p...@heroku.com wrote:
On Tue, Feb 10, 2015 at 4:21 PM, Robert Haas robertmh...@gmail.com wrote:
Although the patch was described as relatively easy to write, it never
went anywhere, because it *replaced* MD5 authentication with bcrypt,
which
On Tue, Feb 10, 2015 at 5:14 PM, Arthur Silva arthur...@gmail.com wrote:
I don't think the password storing best practices apply to db connection
authentication.
Why not?
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Robert Haas robertmh...@gmail.com writes:
On Tue, Feb 10, 2015 at 9:30 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Another thing we need to keep in mind besides client compatibility
is dump/reload compatibility.
I don't think there's an issue with dump/reload compatibility as far
as what I
On Tue, Feb 10, 2015 at 11:19 PM, Peter Geoghegan p...@heroku.com wrote:
On Tue, Feb 10, 2015 at 5:14 PM, Arthur Silva arthur...@gmail.com wrote:
I don't think the password storing best practices apply to db
connection
authentication.
Why not?
--
Peter Geoghegan
I assume if the
On 02/10/2015 05:28 PM, Robert Haas wrote:
I don't actually care which algorithm we use, and I dowannahafta care.
What I do want to do is provide a framework so that, when somebody
discovers that X is better than Y because Z, somebody who knows about
cryptography and not much about PostgreSQL
Peter Eisentraut pete...@gmx.net writes:
On 2/10/15 8:28 PM, Robert Haas wrote:
I don't actually care which algorithm we use, and I dowannahafta care.
What I do want to do is provide a framework so that, when somebody
discovers that X is better than Y because Z, somebody who knows about
On Tue, Feb 10, 2015 at 10:19 PM, Peter Geoghegan p...@heroku.com wrote:
On Tue, Feb 10, 2015 at 5:14 PM, Arthur Silva arthur...@gmail.com wrote:
I don't think the password storing best practices apply to db connection
authentication.
Why not?
Usually because handshakes use a random salt on
On Tue, Feb 10, 2015 at 9:30 PM, Tom Lane t...@sss.pgh.pa.us wrote:
2. We'd have to figure out how to get support for the new algorithms
into libpq. This actually seems a good bit harder than doing it on
the server-side, because I don't think libpq has any dynamic loading
facilities the way
On 2/10/15 8:28 PM, Robert Haas wrote:
I don't actually care which algorithm we use, and I dowannahafta care.
What I do want to do is provide a framework so that, when somebody
discovers that X is better than Y because Z, somebody who knows about
cryptography and not much about PostgreSQL ca
Robert Haas robertmh...@gmail.com writes:
Although the patch was described as relatively easy to write, it never
went anywhere, because it *replaced* MD5 authentication with bcrypt,
which would be a big problem for existing clients.
Right. The client end of it is the elephant in the room in
On Tue, Feb 10, 2015 at 11:25 PM, Peter Geoghegan p...@heroku.com wrote:
On Tue, Feb 10, 2015 at 5:22 PM, Arthur Silva arthur...@gmail.com wrote:
I assume if the hacker can intercept the server unencrypted traffic
and/or
has access to its hard-drive the database is compromised anyway.
On 2/10/15 6:32 PM, Peter Geoghegan wrote:
On Tue, Feb 10, 2015 at 4:21 PM, Robert Haas robertmh...@gmail.com wrote:
Although the patch was described as relatively easy to write, it never
went anywhere, because it *replaced* MD5 authentication with bcrypt,
which would be a big problem for
There have been a few previous attempts to wean PostgreSQL off of MD5.
Back in 2012, Heikki proposed using SCRAM for our next-generation
authentication mechanism:
http://www.postgresql.org/message-id/507550bd.2030...@vmware.com
That seems likely to be a good idea, but nobody's come up with a
On Tue, Feb 10, 2015 at 4:21 PM, Robert Haas robertmh...@gmail.com wrote:
Although the patch was described as relatively easy to write, it never
went anywhere, because it *replaced* MD5 authentication with bcrypt,
which would be a big problem for existing clients. It seems clear
that we
On Tue, Feb 10, 2015 at 10:32 PM, Peter Geoghegan p...@heroku.com wrote:
On Tue, Feb 10, 2015 at 4:21 PM, Robert Haas robertmh...@gmail.com
wrote:
Although the patch was described as relatively easy to write, it never
went anywhere, because it *replaced* MD5 authentication with bcrypt,
47 matches
Mail list logo
