On 10/12/18, 7:02 PM, "Tom Lane" <tgl@sss.pgh.pa.us> wrote:
> "Bossart, Nathan" <bossartn@amazon.com> writes:
>> The main one I am thinking of is generated security tokens. It seems
>> reasonable to me to limit md5 and scram-sha-256 passwords to a much
>> shorter length, but I think the actual server message limit should be
>> somewhat more flexible.
>
> Sure, but even a generated security token seems unlikely to be more
> than a couple dozen bytes long. What's the actual use-case for tokens
> longer than that? ISTM that a limit around 100 bytes already has a
> whole lot of headroom.
I can't speak to the technical necessity of longer tokens, but several
services provide them. One specific example is the AWS Security Token
Service. The documentation for that service currently suggests that
"the typical size is less than 4096 bytes..." [0]. I understand this
alone doesn't warrant a change to PostgreSQL, but it seems valuable to
me to ease this restriction on custom client authentication
mechanisms.
Regarding md5 and scram-sha-256 passwords, I'll look into establishing
some sort of maximum password length that is well-documented and
provides users with clear error messages. My vote would be something
like 128 characters just to be safe. One interesting question is how
we handle existing longer passwords after upgrading. Maybe we could
continue to allow longer passwords to be used for authentication and
only restrict the length of new ones.
Nathan
[0] https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html
