Thread: Re: DETAIL for wrong scram password

On Tue, Mar 02, 2021 at 05:48:05PM +0000, Jacob Champion wrote:
> What would you think about adding the additional detail right after
> verify_client_proof() fails? I.e.

Agreed.  Having that once all the code paths have been taken and the
client proof has been verified looks more solid.  On top of what's
proposed, would it make sense to have a second logdetail for the case
of a mock authentication?  We don't log that yet, so I guess that it
could be useful for audit purposes?
--
Michael

On Thu, 2021-03-25 at 16:41 +0900, Michael Paquier wrote:
> On top of what's
> proposed, would it make sense to have a second logdetail for the case
> of a mock authentication?  We don't log that yet, so I guess that it
> could be useful for audit purposes?
It looks like the code paths that lead to a doomed authentication
already provide their own, more specific, logdetail (role doesn't
exist, role has no password, role doesn't have a SCRAM secret, etc.).

--Jacob

On Thu, Mar 25, 2021 at 03:54:10PM +0000, Jacob Champion wrote:
> It looks like the code paths that lead to a doomed authentication
> already provide their own, more specific, logdetail (role doesn't
> exist, role has no password, role doesn't have a SCRAM secret, etc.).

Yes, you are right here.  I missed the parts before
mock_scram_secret() gets called and there are comments in the whole
area.  Hmm, at the end of the day, I think that would just have
verify_client_proof() fill in logdetail when the client proof does not
match, and use a wording different than what's proposed upthread to
outline that this is a client proof mismatch.
--
Michael

On Fri, Mar 26, 2021 at 09:49:00AM +0900, Michael Paquier wrote:
> Yes, you are right here.  I missed the parts before
> mock_scram_secret() gets called and there are comments in the whole
> area.  Hmm, at the end of the day, I think that would just have
> verify_client_proof() fill in logdetail when the client proof does not
> match, and use a wording different than what's proposed upthread to
> outline that this is a client proof mismatch.

Seeing no updates, this has been marked as RwF.
--
Michael