Re: SCRAM methods

[Simon Josefsson]

Jeremy Harris <address@hidden> writes:

> On 03/01/2020 14:09, Simon Josefsson wrote:
>> Thank you -- I have added this on the 'scram-sha256' branch which is
>> where all development happens right now. 
>
> Great - thanks.
>
> I did wonder, after doing that, that possibly the client side should
> have the (or also have the) salted-password readout facility; then a
> client having to calculate it on first-time use could store it for
> subsequent use.  I've not thought through what happens if the server
> does present different itercnt or salt next time, though.

That made sense, and I commited exactly that fix too before I realized
the more serious problems (see other email).

If the server presents another salt/itercnt next time, the client will
notice it differs and re-compute a new derived password.  There is no
way around this and it is to be expected.  Therefor, servers should
simply not do this unless absolutely necessary.  Clients could possibly
remember multiple versions of the derived password, as could servers,
but I think this will be fragile and nobody is going to implement it
that way.  Better to think of it as server decide on salt/itercnt when
deriving the stored password, and that's the end of it until the
password changes.  The client picks up what the server chose and lives
with that.

/Simon

signature.asc
Description: PGP signature