[jdev] Alternate MUC Authentication Mechanisms

[Alex Milowski]

On Wed, Oct 20, 2010 at 3:29 PM, Kurt Zeilenga <Kurt.Zeilenga at isode.com> wrote:
>
> If the former, however, I would have significant reservations.   SASL mechanisms such as SCRAM is commonly used to authenticate the user's identity to an application service, they are not intended to be used to establish who knows a password shared amongst many users.   How would a user know whether to which identity/password, their personal subscriber password or the room's, to use in computing the challenge responses?  If this was going to be done, I'd argue that the identity they should assert is the room's jid (versus any identity string specific to the subscriber).
>

You could use the same argument against HTTP DIGEST authentication
over https but it is well known that DIGEST is a much better choice
and offers better security in a number of ways.

Most simply, I want to be able to use something like DIGEST
authentication to keep the shared secret from being exposed.  I think
that is a simple request that is fairly straightforward to accomodate.
  A simple hash scheme doesn't protect against replay attacks and so
we do need the challenge in the mix somehow.


-- 
--Alex Milowski
"The excellence of grammar as a guide is proportional to the paucity of the
inflexions, i.e. to the degree of analysis effected by the language
considered."

Bertrand Russell in a footnote of Principles of Mathematics