On 10/3/24 7:29 PM, Jacob Champion wrote:
On Thu, Oct 3, 2024 at 3:25 PM Tom Lane <t...@sss.pgh.pa.us> wrote:Nathan Bossart <nathandboss...@gmail.com> writes:I don't mind proceeding with the patch if there is strong support for it. I wavered only because it's hard to be confident that we are choosing the right limit.I'm not that fussed about it; surely 256 is more than anyone is using? If not, we'll get push-back and then we can have a discussion about the correct limit that's informed by more than guesswork.+1. Next up is probably SCRAM-SHA-512, which should still have smaller entries than that -- 222 bytes, I think, with 128-bit salts and a 5-digit iteration count?
The challenge is that salts can be an arbitrary length, even today (as can the iterator value, though IIRC I think we check if it's in int bounds, and a large iterator becomes pretty impractical for usage).
Probabalistically, it's unlikely there are many very large salts in the wild (though I don't have data on that) and most folks are using the default length, but that probability isn't 0.
I think Tom's initial suggestion (BLCKSZ/2) is better than 256, given we really don't know what' out there in the wild, and this could end up being a breaking change. Every other type in pg_authid is pretty small. That said, I'm also imagining other things we may add that could require TOAST support (remembering previous passwords? storing multiple passwords options)?
Thanks, Jonathan
OpenPGP_signature.asc
Description: OpenPGP digital signature
