RE: Pidgin IM Client Password Disclosure Vulnerability.

["Memisyazici, Aras" <arasm () vt edu>]

John:
 
Thank you for your reply.
 
Indeed, as I tried to explain in my previous reply, my "suggestion" in obscurity as a means of securing things, was not 
meant as (encryption of encryption) ^ ?, rather building another barrier to make it "harder" for compromise.
 
IMO, a "real" solution would be to be able to deploy/install Pidgin in a fashion so that:
 
a) the accounts.xml file's location can be overriden (so that I can re-direct to a network shared TrueCrypt drive over 
an IPSEC protected pipe in a VLAN'd network :p)
b) to be able to disable the "Save Password" option and ensure it cannot be overridden by the user by default
 
In an institution where the authentication piece is tied into the universal PIM LDAP, as-is, the usage of your 
application puts us in awkward position, as it has been deemed against the policies to "store" such authentication 
information in the open in an easily accessible location. 
 
Per your post on http://developer.pidgin.im/wiki/PlainTextPasswords here, AFAIK there still isn't any plugin that 
decrypts/encrypts the saved password file either :/
 
Such position your team is taking, pretty much ties our hands and cripples us on spreading the good word about Pidgin: 
IMO one of the best chat applications out there!
 
Anyways, please keep up the good work and I look forward to the development of Pidgin!
 
Sincerely,

Aras "Russ" Memisyazici
Systems Administrator
 
Virginia Tech
________________________________

From: John Bailey [mailto:rekkanoryo () rekkanoryo org]
Sent: Thu 9/18/2008 5:44 PM
To: Memisyazici, Aras
Cc: bugtraq () securityfocus com; Siim Põder
Subject: Re: Pidgin IM Client Password Disclosure Vulnerability.



On Thu, Sep 18, 2008 at 03:16:18PM -0400, Memisyazici, Aras wrote:
> While I agree with your comments, I cannot help but suggest that maybe the method of choice could be 'security 
> through obscurity' whereby they take a hash of the password, with a non-std. hashing mechanism. The idea being that 
> in today's world where there are so many scr1pt-kiddi3 toolz out there allowing the avg. Joe Schmoe the capability of 
> analyzing one's memory processes i.e. Tsearch, memhack etc... It only makes it non-trivial for them to extract the 
> info needed. This way you are making it a tad more annoying and adding another buffer they need to bypass :)
>
> Just a thought,
> Aras 'Russ' Memisyazici
> Systems Administrator
>
> Virginia Tech

Wow, security through obscurity.  That's a good practice alright.  So
you propose that I and my fellow Pidgin developers implement security
through obscurity, thus giving our users a false sense of security?  No
chance.  Note also that we store passwords on-disk without any form of
encryption or obfuscation, which has been debated to death on numerous
occasions--so much so, in fact, that we've written an FAQ entry dealing
specifically with this.  Additionally, *any* form of encryption that we
were to use would have to be reversible, as storing protocol-specific
hashes is, as Siim pointed out, no better than storing the plain text.
Reversible encryption again makes it completely trivial to decrypt the
passwords (by using our own code against the user), to the point that
it really is no "improvement" at all.

I find it curious that the person disclosing this so-called
vulnerability made no effort to contact us before disclosing, let alone
do any research to find out where the affected area of code is (the code
being complained about here is in libpurple, not Pidgin).  We have
enough visible methods of contact that there is no excuse for not
attempting to contact us directly.

John