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?
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
