On 4/22/19 9:04 AM, Jonathan S. Katz wrote:
> On 4/21/19 9:50 PM, Michael Paquier wrote:
>> 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.
>>
>> Since v10, we don't allow the storage of plain verifiers so if a
>> string does not match what we think is a correct SCRAM or MD5
>> verifier, then it should be processed according to
>> password_encryption when storing the verifier or processed according
>> to the auth protocol with the HBA entry matching. Your patch looks
>> fine to me, I would have just added a test case in password.sql (no
>> need to send a new patch I can take care of it).
>
> Thanks for verifying. I'm happy to add the test case -- I first wanted
> to ensure I was on the right track.
Attached is modified patch with tests included. For the patch against
HEAD, I only test to demonstrate that storing an invalid SCRAM-SHA-256
lookalike hash is stored as an actual SCRAM-SHA-256 password, given we
do not allow storing passwords UNENCRYPTED anymore (yay!). I followed
the testing format that was used in the other cases in the file.
What I would love to add as a test would be a function that checks
whether or not a user/password combo of something like
"jkatz/SCRAM-SHA-256$1234" where the password is stored as plaintext
would validate, but I don't believe we expose anything that does that in
the SQL API. So I feel this is just a light sanity check.
Thanks,
Jonathan
