From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | David Fetter <david(at)fetter(dot)org> |
Cc: | PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Increase psql's password buffer size |
Date: | 2020-01-20 19:38:02 |
Message-ID: | 23206.1579549082@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
David Fetter <david(at)fetter(dot)org> writes:
> On Mon, Jan 20, 2020 at 07:44:25PM +0100, David Fetter wrote:
>> On Mon, Jan 20, 2020 at 01:12:35PM -0500, Tom Lane wrote:
>>> (I can't say that s/100/2048/ in one place is a particularly evil
>>> change; what bothers me is the likelihood that there are other
>>> places that won't cope with arbitrarily long passwords. Not all of
>>> them are necessarily under our control, either.)
>> I found one that is, so please find attached the next revision of the
>> patch.
> I found another place that assumes 100 bytes and upped it to 2048.
So this is pretty much exactly what I expected. And have you tried
it with e.g. PAM, or LDAP?
I think the AWS guys are fools to imagine that this will work in very
many places, and I don't see why we should be leading the charge to
make it work for them. What's the point of having a huge amount of
data in a password, anyway? You can't expect to get it back out
again, and there's no reason to believe that it adds any security
after a certain point. If they want a bunch of different things
contributing to the password, OK, but they could just hash those
things together and thereby keep their submitted password to a length
that will work with most services.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Dean Rasheed | 2020-01-20 20:13:12 | Re: Greatest Common Divisor |
Previous Message | David Fetter | 2020-01-20 19:21:41 | Re: Increase psql's password buffer size |