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
