Dan White <dwhite@xxxxxxx>: (Sun Aug 15 05:57:15 2010) [ Charset ISO-8859-1 converted... ] > On 10/08/10 08:03 +0200, Mathias Laurenz Baumann wrote: > > Greetings, > > > > I plan to use sasl for a conferencing protocol. Users would register > > using a simple registering mechanism using the protocol itself, before > > they link themselves to their identities. > > > > I don't want my server to ever know the plain-text password. So I mainly > > want to use SCRAM and SRP. The server itself takes care of storing the > > secrets (I define a secret as something that proves that you know the > > password). > > Try using a saslauthd backend that supports hashing, such as pam_unix, > which would use a typical crypt(1) verification on the user supplied > password. User management can then be handled outside of libsasl and would > not require any extensions, or use of auxprop. > > > For this to work, a client would simply transmit the secret (not the > > plain password- in the registering process so the server can add it > > to its database. There are several problems in this scenario and the > > library as it is now. > > If the user is sending a pregenerated value to the server, it's really a > password either way. For instance, what happens if the secret is captured > over the wire by an attacker? Hmm. On SRP server does not need know plain-text password and these values what are send to server are not usefull -- replaying them does not help. Values depends also what server sends as challenge. http://srp.stanford.edu/whatisit.html > > I was very surprised to discover that these very simple usecases are so > > difficult to realize. I assumed this would be the normal usecase. > > SASL mechanisms, in the protocol sense, are not really designed to get > involved with account management or creation. You should aim for a clear > distinction between authentication and account management (or lack thereof) > in your protocol design. > > From a server implementation perspective, if you are using the Cyrus SASL > library to implement your SASL support, you shouldn't really know or care > how passwords are stored. That should be a security decision made by the > system administrator via SASL config files. > > Augmenting auxprop, or adding addition auxprop plugins should also be a > separate activity from your protocol design, and server implementation. > > -- > Dan White
