On 06/02/2011 07:42 PM, Evan Schoenberg, M.D. wrote: >>> /* Client Login is a newer login method, enabled by default in Pidgin. It >>> is required to use SSL for ICQ; it is unclear what benefits it provides >>> otherwise. */ >>> purple_account_set_bool(account, "use_clientlogin", TRUE); > >> I might very well have been wrong in that, I did (and really still do) not >> know at all how they actually work and I do not know what issues it had in >> the past. > > Me, either :)
I'll add my $0.02 here. The clientLogin method is more secure than the old BUCP login that is used when clientLogin is turned off. The BUCP login method is either the password XOR'ed with some value or an MD5 hash of the password (there's more to it with the MD5 bit, but I don't recall the details). The clientLogin method with SSL enabled, on the other hand, submits a hashed version of the password over an SSL connection, adding a layer of security to the login process. Security-conscious people will like this, as MD5 has not been considered "secure" for quite some time now due to collision possibilities. The big hangup that could happen is when clientLogin tells us we can use an SSL connection to the BOS server but something between the client and the server prevents *that* SSL connection, which I believe happens on port 5190 (like regular OSCAR) instead of 443 (like the HTTPS login portion of the connection). I don't recall us seeing that with Pidgin for quite a while. Looking at the ticket in question, I'm not quite sure what's going on there, but it sounds like the HTTP proxy in question is denying HTTPS connectivity. FYI, we've also been led to believe that the AIM servers will at some point in the not-too-distant future refuse to accept BUCP logins, which would force us to always use clientLogin. We weren't given a specific timeframe, just a vague "sooner than later" warning. John
signature.asc
Description: OpenPGP digital signature
