Re: Maximum password length

Alexander Kukushkin <cyberdemn@gmail.com> writes:
> Self-containing tokens, for example JWT, could be easily longer than 100 bytes.
> We at Zalando are using such tokens and the usual size of JWT token is
> 600-700 bytes.

> It is not possible to "paste" such token into psql password prompt,
> because the input is truncated by 100 bytes.
> It is not possible to put it into ".pgpass" either, because it assumes
> that line could not be longer than 320 bytes (64*5)

> At the moment there are only two ways to use such tokens as a password:
> 1. export PGPASSWORD=very_long.token
> 2. specify the token(password) in the connection url

This thread seems to have fallen off the radar, but I got interested again
now that we have a report of somebody else trying to use an 800-or-so-byte
password [1], so I looked over Nathan's patches in some detail.

I concur with Stephen's position that there ought to be just one upper
limit not several.  At the same time, it's not clear to me that the
password packet's length is closely related to the plaintext password
limit when we're using SCRAM --- is there any case where the verifier
string could exceed a few hundred bytes?

Also, I'm not exactly convinced that we need to document the limit in the
SGML docs, and I'm definitely down on repeating that info in 16 different
places.  If we make the limit high enough to not be a problem, nobody is
going to care exactly what it is.

Therefore, I propose setting this up with a #define symbol in
pg_config_manual.h and leaving it at that.  Giving documentation in
pg_config_manual.h seems sufficient to me.  Attached is a revised
version of Nathan's patches that does it like that.

I set the proposed limit at 1024 bytes, but given that we now know
of use-cases needing up to 800 bytes, maybe there should be a little
more headroom?  I don't want to make it enormous, though, seeing that
we're allocating static buffers of that size.

Note this patch is intended to be applied over my patch at [2],
since it modifies the test case added there.

			regards, tom lane

[1] https://www.postgresql.org/message-id/flat/CAOhmDze1nqG2vfegpSsTFCgaiFRsqgjO6yLsbmhroz2zGmJHog%40mail.gmail.com
[2] https://www.postgresql.org/message-id/4187382.1598909041%40sss.pgh.pa.us