help-gsasl
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

SCRAM methods


From: Jeremy Harris
Subject: SCRAM methods
Date: Wed, 25 Dec 2019 16:31:16 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2

Hi,

I'm looking at expanding the usage that Exim (an SMTP MTA) can
make of libgsasl.  There has been server-only coverage for a while;
I'm adding client-side and looking specifically at the SCRAM family
of methods.

I see from the git that SCRAM-SHA-256 is on the way, which is very
pleasing.


However - there seems to be no way to supply, on the server side,
the password in non-cleartext (at least, per the docs.  I've not
tried writing a GSASL_SCRAM_SALTED_PASSWORD property yet,
mainly because of a second issue [below]).
 This lack seems at variance with one of the major advantages
of SCRAM noted in RFC 5802:

   o  The authentication information stored in the authentication
      database is not sufficient by itself to impersonate the client.
      The information is salted to prevent a pre-stored dictionary
      attack if the database is stolen.

- at least as applied to the server.  The library does support
the client only storing a salted version of the password, though
it isn't entirely clear how that works in combination with the
server possibly using a different salt (as permitted by the
protocol definition, if impractical vs. storage of salted passwords)
or different iteration-count (also permitted by the protocol,
and without any practical problems I can see).


The second issue is that there is no way to extract a
salted-password from the library.  Without coding a full duplicate
implementation, it seems difficult for an application to get
one to store in the first place - for later use either on a
client or on a server.


So, please consider these feature requests:

- library API returning a salted-password, given password and
  optional salt, optional iteration-count
- utility access to that API
- library acceptance and use, server side, of a salted password.

-- 
Cheers,
  Jeremy



reply via email to

[Prev in Thread] Current Thread [Next in Thread]