[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SCRAM methods
From: |
Simon Josefsson |
Subject: |
Re: SCRAM methods |
Date: |
Wed, 15 Jan 2020 10:27:52 +0100 |
User-agent: |
Evolution 3.30.5-1.1 |
>On 14/01/2020 22:19, Simon Josefsson wrote:
>> Please try version 1.9.1 and tell me if it does what you
>> want! There are new properties for ServerKey/StoredKey now.
>
>Yes, that works nicely for the server side.
>Client side in the next patch release?
Currently I prefer to not implement ClientKey support -- there isn't
any security advantage with it as far as I can see. Stealing
SaltedPassword or ClientKey/StoredKey both make client and server
impersonation possible.
I believe clients should store cleartext-password or the
SaltedPassword. Storing PBKDF2 values in clients is not that uncommon,
so there may be infrastructure in place for it in some environments --
whereas ClientKey/StoredKey are entirely SCRAM-specific.
I could be convinced to change my mind, but currently I value lesser
code complexity both in gsasl and in application as more important than
any perceived advantage with ClientKey/StoredKey over SaltedPassword.
I just don't see any significant advantage with ClientKey/StoredKey
over SaltedPassword. It saves two HMAC operations is all I can see,
but those are cheap compared to code maintenance.
Thoughts?
/Simon
signature.asc
Description: This is a digitally signed message part
- Re: SCRAM methods, (continued)
- Re: SCRAM methods, Jeremy Harris, 2020/01/03
- Re: SCRAM methods, Jeremy Harris, 2020/01/05
- Re: SCRAM methods, Simon Josefsson, 2020/01/06
- Re: SCRAM methods, Jeremy Harris, 2020/01/06
- Re: SCRAM methods, Simon Josefsson, 2020/01/14
- Re: SCRAM methods, Jeremy Harris, 2020/01/14
- Re: SCRAM methods, Jeremy Harris, 2020/01/06
RE: SCRAM methods, - Neustradamus -, 2020/01/03
RE: SCRAM methods, - Neustradamus -, 2020/01/03
Re: SCRAM methods,
Simon Josefsson <=