On 10/12/18, 7:02 PM, "Tom Lane" <t...@sss.pgh.pa.us> wrote: > "Bossart, Nathan" <bossa...@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
