On 2010-05-03 12:37, Joe Hildebrand wrote: > On 5/3/10 8:05 AM, "Evan Schoenberg, M.D." <e...@adium.im> wrote: > >> Ah. Your problem is not with trying multiple SASL mechs but rather that we >> have to use jabber:iq:auth even if SASL fails entirely. > > Yes. > >> A long and detailed discussion of this is found at >> http://trac.adium.im/ticket/8108 - please see >> http://trac.adium.im/ticket/8108#comment:15 and the two following comments, >> in >> particular. > > This points out a downgrade attack that Adium is currently subject to. > Right now, Adium will try to send the server the plaintext password, even if > the server doesn't want it. All I have to do as an attacker to get your > password is contrive a transient login failure through the mechanisms that > the server supports.
Maybe I'm missing something, but couldn't an attacker just swap out all the advertised mechanisms for PLAIN and get a plaintext password the same way? libpurple does not immediately send the password when it falls back to jabber:iq:auth; it queries for what the server supports and requires a fairly valid IQ result stanza. libpurple also will not send plaintext passwords over an unencrypted stream without an explicit OK from the user (not that I expect this step to make /much/ of a difference -- I wonder how many people removing that ability at all would impact). > I agree that this situation is poorly documented in the standards, and even > more poorly implemented in the servers (seeing as how few of them send the > iq:auth stream feature as XEP-78 requires). FWIW, even though libpurple was/is in violation of XEP-78, the server's response could be better, too: "If the server does not support non-SASL authentication (e.g., because it supports only SASL authentication as defined in RFC 3920), it MUST return a <service-unavailable/> error. If the client previously attempted SASL authentication but that attempt failed, the server MUST return a <policy-violation/> stream error (see RFC 3920 regarding stream error syntax)." ~Paul
signature.asc
Description: OpenPGP digital signature
