* Abhijit Menon-Sen (a...@2ndquadrant.com) wrote:
> As a followup, I spoke to an IETF friend who's used and implemented both
> SRP and SCRAM. He agrees that SRP is cryptographically solid, that it's
> significantly more difficult to implement (and therefore has a bit of a
> monoculture risk overall
Abhijit Menon-Sen wrote:
> P.S. I don't know why the SRP code was removed from LibreSSL; nor am I
> sure how seriously to take that. It's possible that it's only because
> it's (still) rather obscure.
As I recall, the working principle of the LibreSSL guys is to remove
everything that can't be un
As a followup, I spoke to an IETF friend who's used and implemented both
SRP and SCRAM. He agrees that SRP is cryptographically solid, that it's
significantly more difficult to implement (and therefore has a bit of a
monoculture risk overall, though of course that wouldn't apply to us if
we were to
At 2015-03-14 09:44:02 +0200, hlinn...@iki.fi wrote:
>
> Perhaps it would be time to restart the discussion on standardizing
> SRP as a SASL mechanism in IETF.
I haven't seen much evidence that there's any interest in doing this; in
fact, I can't remember the author of the draft you pointed to bei
On 03/09/2015 04:43 PM, Abhijit Menon-Sen wrote:
At 2015-03-09 13:52:10 +0200, hlinn...@iki.fi wrote:
Do you have any insight on why the IETF working group didn't choose a
PAKE protocol instead of or in addition to SCRAM, when SCRAM was
standardized?
Hi Heikki.
It was a long time ago, but I
At 2015-03-09 13:52:10 +0200, hlinn...@iki.fi wrote:
>
> Do you have any insight on why the IETF working group didn't choose a
> PAKE protocol instead of or in addition to SCRAM, when SCRAM was
> standardized?
Hi Heikki.
It was a long time ago, but I recall that SRP was patent-encumbered:
https:
Hi Abhijit, I didn't realize you were involved in the IETF process on
SCRAM :-).
On 03/09/2015 09:21 AM, Abhijit Menon-Sen wrote:
At 2015-03-08 12:48:44 -0700, j...@agliodbs.com wrote:
Since SCRAM has been brought up a number of times here, I thought
I'd loop in the PostgreSQL contributor who
At 2015-03-08 12:48:44 -0700, j...@agliodbs.com wrote:
>
> Since SCRAM has been brought up a number of times here, I thought
> I'd loop in the PostgreSQL contributor who is co-author of the SCRAM
> standard to see if he has anything to say about implementing SCRAM as
> a built-in auth method for Po
All,
Since SCRAM has been brought up a number of times here, I thought I'd
loop in the PostgreSQL contributor who is co-author of the SCRAM
standard to see if he has anything to say about implementing SCRAM as a
built-in auth method for Postgres.
Abhijit?
--
Josh Berkus
PostgreSQL Experts Inc.
* Bruce Momjian (br...@momjian.us) wrote:
> On Sat, Mar 7, 2015 at 03:15:46PM -0500, Bruce Momjian wrote:
> > > Gave me 9.15s, or ~0.00915s per connection on a single thread. That
> > > times 16k is 146s or about two and a half minutes. Of course, I'm
> > > comparing this against what we current
On Sat, Mar 7, 2015 at 03:15:46PM -0500, Bruce Momjian wrote:
> > Gave me 9.15s, or ~0.00915s per connection on a single thread. That
> > times 16k is 146s or about two and a half minutes. Of course, I'm
> > comparing this against what we currently do since, well, that's what we
> > currently do
* Bruce Momjian (br...@momjian.us) wrote:
> On Sat, Mar 7, 2015 at 01:56:51PM -0500, Stephen Frost wrote:
> > * Bruce Momjian (br...@momjian.us) wrote:
> > > Yes, I used the term cluster-wide salt in two cases: first,
> > > cluster-wide counter for the MD5 session salt improvement, and second,
>
On Sat, Mar 7, 2015 at 01:56:51PM -0500, Stephen Frost wrote:
> * Bruce Momjian (br...@momjian.us) wrote:
> > On Sat, Mar 7, 2015 at 12:49:15PM -0500, Stephen Frost wrote:
> > > Ok, this is the incremented counter approach you brought up previously.
> > > Using the term 'cluster-wide salt' confus
* Bruce Momjian (br...@momjian.us) wrote:
> On Sat, Mar 7, 2015 at 12:49:15PM -0500, Stephen Frost wrote:
> > Ok, this is the incremented counter approach you brought up previously.
> > Using the term 'cluster-wide salt' confused me as I thought you were
> > referring to changing the on-disk forma
On Sat, Mar 7, 2015 at 12:49:15PM -0500, Stephen Frost wrote:
> * Bruce Momjian (br...@momjian.us) wrote:
> > On Fri, Mar 6, 2015 at 07:02:36PM -0500, Stephen Frost wrote:
> > > * Bruce Momjian (br...@momjian.us) wrote:
> > > > I think the best solution to this would be to introduce a per-cluster
On Sat, Mar 7, 2015 at 12:52:15PM -0500, Stephen Frost wrote:
> * Bruce Momjian (br...@momjian.us) wrote:
> > On Fri, Mar 6, 2015 at 07:00:10PM -0500, Stephen Frost wrote:
> > > suggested to me as one change we could make that would reduce the risk
> > > of disk-based attacks while trading that o
* Bruce Momjian (br...@momjian.us) wrote:
> On Fri, Mar 6, 2015 at 07:00:10PM -0500, Stephen Frost wrote:
> > suggested to me as one change we could make that would reduce the risk
> > of disk-based attacks while trading that off for a higher risk on the
> > side of network-based attacks while not
* Bruce Momjian (br...@momjian.us) wrote:
> On Fri, Mar 6, 2015 at 07:02:36PM -0500, Stephen Frost wrote:
> > * Bruce Momjian (br...@momjian.us) wrote:
> > > I think the best solution to this would be to introduce a per-cluster
> > > salt that is used for every password hash. That way, you could
On Fri, Mar 6, 2015 at 07:00:10PM -0500, Stephen Frost wrote:
> > > I'm also worried about both, but if the admin is worried about sniffing
> > > in their environment, they're much more likely to use TLS than to set up
> > > client side certificates, kerberos, or some other strong auth mechanism,
On Fri, Mar 6, 2015 at 07:02:36PM -0500, Stephen Frost wrote:
> * Bruce Momjian (br...@momjian.us) wrote:
> > On Fri, Mar 6, 2015 at 12:50:14PM -0800, Josh Berkus wrote:
> > > On 03/06/2015 08:19 AM, Stephen Frost wrote:
> > > > Well, server-side, we already have that- have pgbouncer run on the
>
* Bruce Momjian (br...@momjian.us) wrote:
> On Fri, Mar 6, 2015 at 12:50:14PM -0800, Josh Berkus wrote:
> > On 03/06/2015 08:19 AM, Stephen Frost wrote:
> > > Well, server-side, we already have that- have pgbouncer run on the
> > > database server (something which I'm typically in favor of anyway)
* Bruce Momjian (br...@momjian.us) wrote:
> On Thu, Mar 5, 2015 at 11:15:55AM -0500, Stephen Frost wrote:
> > * Bruce Momjian (br...@momjian.us) wrote:
> > > On Wed, Mar 4, 2015 at 05:56:25PM -0800, Josh Berkus wrote:
> > > > So, are we more worried about attackers getting a copy of pg_authid, or
On Fri, Mar 6, 2015 at 12:50:14PM -0800, Josh Berkus wrote:
> On 03/06/2015 08:19 AM, Stephen Frost wrote:
> > * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> >> Stephen Frost wrote:
> >> Sure. I was thinking we would have some mechanism to authenticate the
> >> connection as coming from a p
On Thu, Mar 5, 2015 at 11:15:55AM -0500, Stephen Frost wrote:
> * Bruce Momjian (br...@momjian.us) wrote:
> > On Wed, Mar 4, 2015 at 05:56:25PM -0800, Josh Berkus wrote:
> > > So, are we more worried about attackers getting a copy of pg_authid, or
> > > sniffing the hash on the wire?
> >
> > Bot
On 03/06/2015 08:19 AM, Stephen Frost wrote:
> * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
>> Stephen Frost wrote:
>> Sure. I was thinking we would have some mechanism to authenticate the
>> connection as coming from a pooler that has been previously authorized;
>> something simple as a new
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Stephen Frost wrote:
> > * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> > > Perhaps one of the requirements of a new auth method should be to allow
> > > middlemen such as connection poolers. It's been over two years since I
> > > had a lo
Stephen Frost wrote:
> Alvaro,
>
> * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> > Perhaps one of the requirements of a new auth method should be to allow
> > middlemen such as connection poolers. It's been over two years since I
> > had a look, but IIRC pgbouncer had the very ugly requir
Alvaro,
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Stephen Frost wrote:
> > * Josh Berkus (j...@agliodbs.com) wrote:
>
> > > > 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
Stephen Frost wrote:
> * Josh Berkus (j...@agliodbs.com) wrote:
> > > 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.
> >
> > This is a feature as well as a bug. For example, pgBouncer r
Greg,
* Greg Stark (st...@mit.edu) wrote:
> Locked accounts are a terrible terrible idea. All they do is hand attackers
> an easy DOS vulnerability. They're pure security theatre if your
> authentication isn't vulnerable to brute force attacks and an unreliable
> band-aid if they are.
For starter
* Albe Laurenz (laurenz.a...@wien.gv.at) wrote:
> Stephen Frost wrote:
> > Yes, it certainly was. I think Bruce was thinking that we could simply
> > hash what goes on to disk with an additional salt that's stored, but
> > that wouldn't actually work without requiring a change to the wireline
> >
Locked accounts are a terrible terrible idea. All they do is hand attackers
an easy DOS vulnerability. They're pure security theatre if your
authentication isn't vulnerable to brute force attacks and an unreliable
band-aid if they are.
Having dealt with mechanisms for locking accounts in other dat
Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Bruce Momjian writes:
>>> Let me update my list of possible improvements:
>>
>>> 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 i
* Jim Nasby (jim.na...@bluetreble.com) wrote:
> On 3/5/15 2:17 PM, Stephen Frost wrote:
> >* Jim Nasby (jim.na...@bluetreble.com) wrote:
> >I'm all for it, though I would ask that we provide a way for superusers
> >to delegate the ability to reset locked accounts to non-superusers.
> >
> >I'd want
On 3/5/15 2:17 PM, Stephen Frost wrote:
* Jim Nasby (jim.na...@bluetreble.com) wrote:
On 3/4/15 2:56 PM, Stephen Frost wrote:
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.
Yes, and we have no
* Jim Nasby (jim.na...@bluetreble.com) wrote:
> On 3/4/15 2:56 PM, Stephen Frost wrote:
> >>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.
> >Yes, and we have no (PG-based) mechanism to pr
On 3/4/15 2:56 PM, Stephen Frost wrote:
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.
Yes, and we have no (PG-based) mechanism to prevent those connection
attempts, which is a pretty horrible
* Bruce Momjian (br...@momjian.us) wrote:
> On Wed, Mar 4, 2015 at 04:19:00PM -0500, Stephen Frost wrote:
> > > Hm, well, "don't change the wireline protocol" could be another wanna-have
> > > ... but if we want to stop using MD5, that's not really a realistic goal
> > > is it?
> >
> > I'm trying
* Bruce Momjian (br...@momjian.us) wrote:
> One way to fix #2 would be to use a per-user or per-cluster counter for
> the session salt, rather than a random number --- that would change
> replays from ~16k to 4 billion, with no wire protocol change needed.
I'm not against doing that if we decide t
* Bruce Momjian (br...@momjian.us) wrote:
> On Wed, Mar 4, 2015 at 05:56:25PM -0800, Josh Berkus wrote:
> > So, are we more worried about attackers getting a copy of pg_authid, or
> > sniffing the hash on the wire?
>
> Both. Stephen is more worried about pg_authid, but I am more worried
> about
* Josh Berkus (j...@agliodbs.com) wrote:
> Catching up here ...
>
> On 03/03/2015 06:01 PM, Bruce Momjian 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 us
On Wed, Mar 4, 2015 at 05:56:25PM -0800, Josh Berkus wrote:
> Catching up here ...
>
> On 03/03/2015 06:01 PM, Bruce Momjian 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:
> >
Catching up here ...
On 03/03/2015 06:01 PM, Bruce Momjian 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
On Wed, Mar 4, 2015 at 04:19:00PM -0500, Stephen Frost wrote:
> > Hm, well, "don't change the wireline protocol" could be another wanna-have
> > ... but if we want to stop using MD5, that's not really a realistic goal
> > is it?
>
> I'm trying to address both sides of the issue- improve the curre
On Wed, Mar 4, 2015 at 03:59:02PM -0500, Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > Bruce Momjian writes:
> > > Let me update my list of possible improvements:
> >
> > > 1) MD5 makes users feel uneasy (though our usage is mostly safe)
> >
> > > 2) The per-session salt s
On Wed, Mar 4, 2015 at 03:54:09PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > Let me update my list of possible improvements:
>
> > 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
* Robert Haas (robertmh...@gmail.com) wrote:
> So, the server can only authenticate the user with the salts it has
> stored, because those are the only salts for which it knows what the
> response should be?
That's correct- except that it doesn't directly know what the response
is, it only knows
On Wed, Mar 4, 2015 at 10:52 AM, 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"
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> What happened to "possession of the contents of pg_authid is sufficient
> >> to log in"? I thought fixing that was one of the objectives here.
>
> > Yes, it certainly was. I think Bruc
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> What happened to "possession of the contents of pg_authid is sufficient
>> to log in"? I thought fixing that was one of the objectives here.
> Yes, it certainly was. I think Bruce was thinking that we could simply
> hash what goe
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Bruce Momjian writes:
> > Let me update my list of possible improvements:
>
> > 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 a
* Bruce Momjian (br...@momjian.us) wrote:
> On Wed, Mar 4, 2015 at 02:46:54PM -0500, Stephen Frost wrote:
> > > Well, passwords are already addressed by certificate authentication, so
> > > what's your point? I think we decided we wanted a way to do passwords
> > > without requiring network encry
Bruce Momjian writes:
> Let me update my list of possible improvements:
> 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.
>
On Wed, Mar 4, 2015 at 02:46:54PM -0500, Stephen Frost wrote:
> > Well, passwords are already addressed by certificate authentication, so
> > what's your point? I think we decided we wanted a way to do passwords
> > without requiring network encryption.
>
> It's completely unclear to me what you
* Magnus Hagander (mag...@hagander.net) wrote:
> On Wed, Mar 4, 2015 at 5:03 PM, Stephen Frost 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 straig
On Wed, Mar 4, 2015 at 02:21:51PM -0500, Stephen Frost wrote:
> * Bruce Momjian (br...@momjian.us) wrote:
> > On Wed, Mar 4, 2015 at 01:27:32PM -0500, Stephen Frost wrote:
> > > This further makes what is sent over the network not directly
> > > susceptible to a replay attack because the server h
* Bruce Momjian (br...@momjian.us) wrote:
> On Wed, Mar 4, 2015 at 02:21:51PM -0500, Stephen Frost wrote:
> > * Bruce Momjian (br...@momjian.us) wrote:
> > > On Wed, Mar 4, 2015 at 01:27:32PM -0500, Stephen Frost wrote:
> > > > This further makes what is sent over the network not directly
> > > >
* Bruce Momjian (br...@momjian.us) wrote:
> On Wed, Mar 4, 2015 at 01:27:32PM -0500, Stephen Frost wrote:
> > 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
* Heikki Linnakangas (hlinn...@iki.fi) wrote:
> I'm not sure how expensive a brute force attack on SRP would be,
> using a stolen backup tape. There doesn't seem to be an iterations
> count similar to SCRAM. But note that SRP's resistance to
> brute-forcing the authentication handshake is of a diff
On 03/04/2015 08:59 PM, Stephen Frost wrote:
* Heikki Linnakangas (hlinn...@iki.fi) wrote:
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
On Wed, Mar 4, 2015 at 01:27:32PM -0500, Stephen Frost wrote:
> 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 cur
* Heikki Linnakangas (hlinn...@iki.fi) wrote:
> 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 w
On 03/04/2015 06:11 PM, Stephen Frost wrote:
* Magnus Hagander (mag...@hagander.net) wrote:
On Wed, Mar 4, 2015 at 5:03 PM, Stephen Frost 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-
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 a
* Bruce Momjian (br...@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
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
* Stephen Frost (sfr...@snowman.net) wrote:
> * Bruce Momjian (br...@momjian.us) wrote:
> > On Wed, Mar 4, 2015 at 11:36:23AM -0500, Stephen Frost wrote:
> > > * Andres Freund (and...@2ndquadrant.com) wrote:
> > > > On 2015-03-04 11:06:33 -0500, Stephen Frost wrote:
> > > > > * Andres Freund (and.
* Bruce Momjian (br...@momjian.us) wrote:
> On Wed, Mar 4, 2015 at 11:36:23AM -0500, Stephen Frost wrote:
> > * Andres Freund (and...@2ndquadrant.com) wrote:
> > > On 2015-03-04 11:06:33 -0500, Stephen Frost wrote:
> > > > * Andres Freund (and...@2ndquadrant.com) wrote:
> > > > > On 2015-03-04 10:
* Bruce Momjian (br...@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 t
On Wed, Mar 4, 2015 at 11:36:23AM -0500, Stephen Frost wrote:
> * Andres Freund (and...@2ndquadrant.com) wrote:
> > On 2015-03-04 11:06:33 -0500, Stephen Frost wrote:
> > > * Andres Freund (and...@2ndquadrant.com) wrote:
> > > > On 2015-03-04 10:52:30 -0500, Stephen Frost wrote:
> > > > > The firs
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
* Andres Freund (and...@2ndquadrant.com) wrote:
> On 2015-03-04 11:06:33 -0500, Stephen Frost wrote:
> > * Andres Freund (and...@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
> > > > needl
On 2015-03-04 11:06:33 -0500, Stephen Frost wrote:
> * Andres Freund (and...@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 sen
* Andres Freund (and...@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
On Wed, Mar 4, 2015 at 5:03 PM, Stephen Frost wrote:
> Magnus,
>
> * Magnus Hagander (mag...@hagander.net) wrote:
> > On Wed, Mar 4, 2015 at 4:52 PM, Stephen Frost
> 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
Magnus,
* Magnus Hagander (mag...@hagander.net) wrote:
> On Wed, Mar 4, 2015 at 4:52 PM, Stephen Frost 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 b
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 anythin
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 "netw
On Wed, Mar 4, 2015 at 4:52 PM, Stephen Frost 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 tha
Bruce, all,
* Bruce Momjian (br...@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-s
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 po
81 matches
Mail list logo
