| From: | Alexander Kukushkin <cyberdemn(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | bossartn(at)amazon(dot)com, Stephen Frost <sfrost(at)snowman(dot)net>, isaac(dot)morland(at)gmail(dot)com, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Maximum password length |
| Date: | 2018-10-13 12:27:55 |
| Message-ID: | CAFh8B=k6N5Y2nknTkmA9WmzbmSxOzb5WL8UAnvaBLK+FJn2w8w@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sat, 13 Oct 2018 at 02:02, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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.
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
Regards,
--
Alexander Kukushkin
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Kapila | 2018-10-13 12:56:33 | Re: WIP: Avoid creation of the free space map for small tables |
| Previous Message | Thomas Munro | 2018-10-13 10:45:17 | Re: DSM segment handle generation in background workers |