Requirement of plaintext pass for sasl_setpass

[Dan White]

On 26/05/10 23:32 +0200, Mathias Laurenz Baumann wrote:
>> Users do not need to be created with sasl_setpass or other SASL utility,
>> and often are not, such as when using PAM for authentication.
>>
>> That's also true when storing cmusaslsecretSRP for SRP authentication,
>> which can be stored using any method supported by the auxprop store, such
>> as the mysql client when using the SQL auxprop plugin.
>>
>
> Well, I need some way to create the cmusaslsecret{mech}s on the client, so
> I can send them to the server which then can add it to the database.

Which the sasl library can do, on the client. ldapdb and sql auxprop
plugins have the added benefit of allowing you to transmit those attributes
securely.

If your client systems don't have the sasl library installed, then you can
accept a plain text password (transmitted over SSL e.g.) and have whichever
auxprop plugin you prefer convert it to mech specific credentials directly
on the server, but the server then has knowledge of the plain text
password.

>> If you use a network enabled auxprop plugin (SQL or LDAPDB), and you
>> allow users permissions to change their own security credentials, then
>> you could assign a temporary password and let them change it
>> themselves.
>
> I don't use an external server for storing authentication (at least not
> primary) but instead want to use server itself to store it (that is, the
> client of the libsasl library).
>
> From what I've understood from the documentation I can only do that, by
> writing my own auxprop plugin that calls some functions in the host
> application. There  are several problems with that:

Your application could just call 'saslpasswd2'. That's what we do when
customers change their passwords from a PHP webpage.

I might be misinterpreting your needs. Where do you intend to store your
authentication credentials? 

> 1) I don't want an extra plugin to be installed in the sasl2
> plugin-directory just for my server, so I would just ship it as regular
> lib and use the sasl_getpath_t function to tell libsasl to load the
> (previously set using sasl_getopt_t) auxprop plugin using a specific path
>
> 2) Depending on whether the applications symbols are being exported back
> to the library or not, I can't just call an function from the host
> application but I could load the library  before libsasl does and
> register some own callback functions.

You could look at the internal 'slapd' auxprop module OpenLDAP uses. It
seems to do something very similar: storing and retrieving credentials via
it's own internal auxprop module without any changes to the sasl library.

> To allow a user to register, I would need to do nearly the same in the
> client, I would then just do sasl_setpass to make the mech generate the
> cmusaslsecret and saving it in my custom auxprop which would then just
> tell the host application (which is the client of my  server) and send
> the cmusaslsecrets to the server which then can add them to its database.
>
> Am I over-complicating things here? Are there better ways to reach what I
> try to achieve?  I haven't found any other way than the one I just
> described.

-- 
Dan White