Re: Possible to store invalid SCRAM-SHA-256 Passwords - Mailing list pgsql-bugs

From Jonathan S. Katz
Subject Re: Possible to store invalid SCRAM-SHA-256 Passwords
Date
Msg-id 7e5b5f9e-6cde-b066-837d-9af22e7b1152@postgresql.org
Whole thread Raw
In response to Re: Possible to store invalid SCRAM-SHA-256 Passwords  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
On 4/22/19 9:42 AM, Tom Lane wrote:
> Michael Paquier <michael@paquier.xyz> writes:
>> On Sat, Apr 20, 2019 at 04:12:56PM -0400, Jonathan S. Katz wrote:
>>> I modified the "get_password_type" function to perform a SCRAM
>>> verification to see if it is a properly hashed SCRAM password. If it is,
>>> we treat the password as a SCRAM hashed one. Otherwise, we proceed to
>>> the next step, which is to treat it as a plainly stored one.
>
>> Any objections to back-patch that stuff to v10?
>
> Patch looks OK as far as it goes, but ISTM it raises an obvious
> question: shouldn't the immediately-preceding test to see if a
> password is MD5 also be trying harder?  Currently it only checks
> the length, but verifying that the rest is valid hex data would
> go far towards preventing the same set of problems for MD5.
>
> You might argue that MD5 is deprecated and we shouldn't expend
> any effort on it, but a simple strspn check would only require
> about one more line ...

Yeah, but at least if people look back at it as a reference for how to
properly(?) validate various password hashes it would look better. If it
was any higher effort, I'd say "no" given the status of md5, but this is
fairly innocuous.

I'm happy to put something together in a separate patch. I can take a
look later today.

Jonathan


Attachment

pgsql-bugs by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Possible to store invalid SCRAM-SHA-256 Passwords
Next
From: Grigory Smolkin
Date:
Subject: Re: amcheck assert failure