Re: Maximum password length

From: "Bossart, Nathan" <bossartn(at)amazon(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, Isaac Morland <isaac(dot)morland(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Maximum password length
Date: 2018-10-13 04:30:05
Message-ID: 5978410F-83E9-42D1-B3E6-E335E211A15E@amazon.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 10/12/18, 7:02 PM, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "Bossart, Nathan" <bossartn(at)amazon(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2018-10-13 08:30:40 Re: pgsql: Add TAP tests for pg_verify_checksums
Previous Message Andres Freund 2018-10-13 02:01:31 Re: Alter index rename concurrently to