Requirement of plaintext pass for sasl_setpass

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

 



Greetings,

I was wondering if there is another way to add a new user without ever sending his real plain-text password over the wire and without the server knowing the plain-text password? I think in SRP this should be the case, but I was confused by the sasl_setpass method, because it seems to require an plain-text password.

What I was also wondering about: If a client chooses SCRAM-SHA (let's say, while it is registering) and then later chooses a different one like SRP, isn't this a problem because you can't "convert" the secret that SCRAM uses to the one that SRP uses? (I don't know SCRAM in detail, but I think it has a secret instead of a password, for the sake of the example let's assume this here). I guess this is closely related to my first question :)

And while I am at it, another question: Did I understand it right that libsasl also provides the encryption itself with the sasl_encode functions and no ssl is required anymore if one uses this? And can I use sasl_encode even when a user didn't authenticate yet (for example to secure the registering process)? If not, I would have to setup an encrypted certificate based TLS encryption just for the registering process and then use sasl_encode from that point on. Which is kinda .. redundant.

In the protocol([1]psyc), it should be possible to "link" a client to several personalities, that's what I want to use sasl for. But the RFC and the libsasl documentation says there should only be one context for one connection. Of course I could just ignore that, but first I want to know your opinion on that matter. Is it a good choice to ignore that? Are there alternatives? And of course it could confuse the encryption layer as to which context to use for which transmission (in that case I would just declare that the first link to a personality is the one that will be used for encryption... at least if I am going to use sasl_encode).


--Marenz


[1] http://about.psyc.eu/Specification (dont bitch about the organisation, I agree that it sucks)


[Index of Archives]     [Info Cyrus]     [Squirrel Mail]     [Linux Media]     [Yosemite News]     [gtk]     [KDE]     [Gimp on Windows]     [Steve's Art]

  Powered by Linux