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
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost 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
Stephen Frost 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 external authenti
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Heikki Linnakangas 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 mechanisms.
> If people wan
Heikki Linnakangas 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 without extra librarie
On 02/11/2015 11:30 PM, Claudio Freire wrote:
On Wed, Feb 11, 2015 at 5:25 PM, Heikki Linnakangas
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
On Wed, Feb 11, 2015 at 6:30 PM, Claudio Freire wrote:
> On Wed, Feb 11, 2015 at 5:25 PM, Heikki Linnakangas
> 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 stren
On Wed, Feb 11, 2015 at 5:25 PM, Heikki Linnakangas
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 bruteforceable.
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 hash
On 02/11/2015 03:52 PM, Robert Haas wrote:
On Wed, Feb 11, 2015 at 8:02 AM, Heikki Linnakangas
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,
On 02/11/2015 05:34 PM, Claudio Freire wrote:
On Wed, Feb 11, 2015 at 12:20 PM, José Luis Tallón
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 changes back possible, righ
* 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 un
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 repl
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:
>
> * scr
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?= 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.
On 02/11/2015 04:40 PM, Tom Lane wrote:
=?UTF-8?B?Sm9zw6kgTHVpcyBUYWxsw7Nu?= 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 to
=?UTF-8?B?Sm9zw6kgTHVpcyBUYWxsw7Nu?= 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 exactly the direction
On Wed, Feb 11, 2015 at 12:20 PM, José Luis Tallón
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 where people are alrea
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 also
On Wed, Feb 11, 2015 at 11:48 AM, José Luis Tallón
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 actuall
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 fix
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
nam
On Wed, Feb 11, 2015 at 10:31 AM, Magnus Hagander wrote:
> On Wed, Feb 11, 2015 at 4:57 AM, Tom Lane wrote:
>>
>> Robert Haas writes:
>> > On Tue, Feb 10, 2015 at 9:30 PM, Tom Lane wrote:
>> >> Another thing we need to keep in mind besides client compatibility
>> >> is dump/reload compatibility
On Wed, Feb 11, 2015 at 3:26 PM, Robert Haas wrote:
> On Wed, Feb 11, 2015 at 9:14 AM, Magnus Hagander
> wrote:
> > On Wed, Feb 11, 2015 at 3:10 PM, José Luis Tallón
> > wrote:
> >>
> >> On 02/11/2015 02:31 PM, Magnus Hagander wrote:
> >>
> >>
> >>> In any case, my larger point was that given t
On Wed, Feb 11, 2015 at 9:14 AM, Magnus Hagander wrote:
> On Wed, Feb 11, 2015 at 3:10 PM, José Luis Tallón
> 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
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 w
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 foolish to think only about replacing the MD5
algorithm and
not about
On Wed, Feb 11, 2015 at 8:02 AM, Heikki Linnakangas
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. So I wonder if a
On Wed, Feb 11, 2015 at 4:57 AM, Tom Lane wrote:
> Robert Haas writes:
> > On Tue, Feb 10, 2015 at 9:30 PM, Tom Lane 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 compatibil
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 t
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 shou
On Wed, Feb 11, 2015 at 4:13 AM, Heikki Linnakangas
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 challenge/response mes
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 us
On 02/11/2015 04:38 AM, Tom Lane wrote:
Peter Eisentraut 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, somebod
On 2/10/15 6:32 PM, Peter Geoghegan wrote:
On Tue, Feb 10, 2015 at 4:21 PM, Robert Haas 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
On Tue, Feb 10, 2015 at 10:19 PM, Peter Geoghegan wrote:
> On Tue, Feb 10, 2015 at 5:14 PM, Arthur Silva 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 both sides. Not sure
abou
Robert Haas writes:
> On Tue, Feb 10, 2015 at 9:30 PM, Tom Lane 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 proposed, since it only has to do with
On Tue, Feb 10, 2015 at 11:25 PM, Peter Geoghegan wrote:
> On Tue, Feb 10, 2015 at 5:22 PM, Arthur Silva 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 a
On Tue, Feb 10, 2015 at 9:30 PM, Tom Lane 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 the server d
Peter Eisentraut 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
>> cryptography
Robert Haas 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 any discussion
of im
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 PostgreS
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 c
On Tue, Feb 10, 2015 at 7:32 PM, Peter Geoghegan wrote:
> On Tue, Feb 10, 2015 at 4:21 PM, Robert Haas 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 exist
On Tue, Feb 10, 2015 at 5:22 PM, Arthur Silva 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 Geoghegan
--
S
On Tue, Feb 10, 2015 at 11:19 PM, Peter Geoghegan wrote:
> On Tue, Feb 10, 2015 at 5:14 PM, Arthur Silva wrote:
> > I don't think the "password storing best practices" apply to db
> connection
> > authentication.
>
> Why not?
>
> --
> Peter Geoghegan
>
I assume if the hacker can intercept the s
On Tue, Feb 10, 2015 at 5:14 PM, Arthur Silva 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 subscription:
http://w
On Tue, Feb 10, 2015 at 10:32 PM, Peter Geoghegan wrote:
> On Tue, Feb 10, 2015 at 4:21 PM, Robert Haas
> 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 fo
On Tue, Feb 10, 2015 at 4:21 PM, Robert Haas 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 should add something ne
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
patc
50 matches
Mail list logo
