Multiple-Mechanism Sample Code?

[Andreas Winkelmann]

On Wednesday 03 January 2007 21:23, Dave Cridland wrote:

> > If the Server offers DIGEST-MD5 and PLAIN. And the User/Client trys
> > wrong Credentials, the Second try will pass in Cleartext the
> > Internet. I would not like to see that if I just make a Typo in the
> > Password, you?
>
> Well, the client really ought to be warning about this, and checking
> with the user. Of course, this might need a new API/callback for
> Cyrus SASL, I can't recall. (All my Cyrus SASL usage is on the
> server, my client usage uses its own library, which does do warnings).

Hmm, ok, you have a Server, which does only allow Plaintext-Passwords with 
SSL/TLS and Shared-Secret Mechanisms without SSL/TLS. The Client connects 
without TLS and trys DIGEST-MD5, it fails. What shall happen? Cyrus-SASL 
cannot switch to PLAIN without a heavy Interaction with the 
Server-Application. At least it has to establish a SSL/TLS-Layer to enable 
Plaintext-Passwords in the Authentification-Phase. I don't think this 
hypothetical Situation is a rare exception.

> > Oh and useless, because why should there be a difference between
> > one of the Offered Mechanisms? If DIGEST-MD5 with one set of
> > Credentials fails, why should it succeed with PLAIN? This is only
> > the case with misconfigured Servers (Offering *-MD5 Mechanisms with
> > saslauthd for example).
>
> Ah... No, there's the transition case. For ACAP, for example, the
> attempt to authenticate with DIGEST-MD5 might yield a
> TRANSITION-NEEDED, but (all?) other protocols won't communicate that
> back to the client, so it's reasonable to try PLAIN.
>
> PLAIN might work because SASL can pass the credentials onto the
> operating system's authentication method, whereas DIGEST-MD5 needs
> either a copy of the plaintext, or the intemediate hash, in which
> case that's per-user, not per-site. The simplest way of getting the
> data needed is to get the user to authenticate once using PLAIN,
> after which DIGEST-MD5 works.

I don't know ACAP so good to see this relation, but this sounds like the 
Cyrus-SASL auto_transition Feature. To "convert" a Crypted Password Storage 
(shadow/passwd/...) to an UnEncrypted (auxprop) you enable auto_transition 
and waits until all Accounts/Passwords are created in auxprop. In this Phase 
you run with Plaintext-Passwords only (mech_list: plain login) though it 
would be possible to use *-MD5 Mechanisms for the already created Accounts.

BTW, a failed Authentification with right Credentials has always a bad taste. 
Looks like a Trojan Horse at the first sight.

-- 
	Andreas