[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
  Web www.spinics.net

A simple usecase being ignored


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).

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.

* To get the secret, the client has to call sasl_setpasswd with the appropriate mechanisms enabled (at least SRP) which will use the auxprop plugin(s) to set the secret. ** I can either write my own small auxprop plugin that does nothing more than providing the secret to the host application or ** I call the mechanisms setpasswd function myself and change the parameter for sasl_setprop (or something like this) to my own host-internal function. Both solutions are ugly hacks in my opinion and yet the solution to this would be very simple: A mechanism specific function that gets the password and returns the secret. A third possibility exists: ** Write a auxprop plugin that does the registering process itself. I don't like this solution, as it requires creating a connection and takes away the control from the library user. But this would be the only one not being an ugly hack.

* the server manages the storing itself, yet libsasl requires me to write a auxprop plugin which would in turn just call/forward the calls back to the server. Also an ugly hack. Again, the solution would be very simple: let the hostapplication provide some callbacks in libsasl so it can take care of fetching/storing.

On a side note:
I discovered, that only SRP and OTP use prop_set to store their cmusaslsecret* using the auxprop plugin and that for example CRAM doesn't provide a setpasswd function at all. I don't understand why? Doesn't CRAM (and some others) use only a secret for authentication? How would the cmusaslsecret for CRAM be created?

I was very surprised to discover that these very simple usecases are so difficult to realize. I assumed this would be the normal usecase.

what do you think about my proposed changes/extensions to libsasl?



[Video For Linux]     [Photos]     [Yosemite News]    [Yosemite Photos]     [gtk]     [KDE]     [Info Cyrus]     [Gimp on Windows]     [Steve's Art]     [Script Fu]

Powered by Linux