On Wed Jan 3 21:18:35 2007, Andreas Winkelmann wrote:
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.
No, and it's not very hard, either. The client application then
receives the transition request, and assuming the user accepts,
negotiates TLS, and reauthenticates with PLAIN.
> > 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.
Exactly - Cyrus SASL tells the server, and the server can tell the
client via the application level protocol. ACAP happens to be an
example of a protocol which allows this, whereas IMAP does not.
BTW, a failed Authentification with right Credentials has always a
bad taste. Looks like a Trojan Horse at the first sight.
No, it's not a matter of the right or wrong credentials, it's a
matter of the credentials not being validatable.
Dave.
--
Dave Cridland - mailto:dave@xxxxxxxxxxxx - xmpp:dwd@xxxxxxxxxx
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
