| From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Alexander Lakhin <exclusion(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Should rolpassword be toastable? |
| Date: | 2024-09-19 21:52:02 |
| Message-ID: | ZuydAj4nrt4cpGU5@nathan |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Sep 19, 2024 at 12:44:32PM -0500, Nathan Bossart wrote:
> On Thu, Sep 19, 2024 at 10:31:15AM -0400, Tom Lane wrote:
>> We could put an arbitrary limit (say, half of BLCKSZ) on the length of
>> passwords.
>
> Something like that could be good enough. I was thinking about actually
> validating that the hash had the correct form, but that might be a little
> more complex than is warranted here.
Oh, actually, I see that we are already validating the hash, but you can
create valid SCRAM-SHA-256 hashes that are really long. So putting an
arbitrary limit (patch attached) is probably the correct path forward. I'd
also remove pg_authid's TOAST table while at it.
--
nathan
| Attachment | Content-Type | Size |
|---|---|---|
| fail_for_long_scram_hash.patch | text/plain | 967 bytes |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2024-09-19 22:14:34 | Re: Should rolpassword be toastable? |
| Previous Message | Tom Lane | 2024-09-19 21:35:33 | Re: BUG #18545: \dt breaks transaction, calling error when executed in SET SESSION AUTHORIZATION |