Re: Pidgin IM Client Password Disclosure Vulnerability.

[John Bailey <rekkanoryo () rekkanoryo org>]

Memisyazici, Aras wrote:
> 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.

Which we can't do, because we need to be able to generate the hash a given
server requires.  Some protocols can ask for different types of hashes at
various times, and if we store the password in a non-reversible hash we lose the
ability to use these protocols.  Not to mention the fact that it still does
nothing but provide a false sense of security, which we feel is worse than no
security at all.

> 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)

This can already be done--on a Windows system, which this so-called
"vulnerability disclosure" obviously focused solely on, forcing the PURPLEHOME
environment variable to be set by a user's logon script will use the specified
path for not just accounts.xml but all configuration and data files for Pidgin.
 The pidgin.exe binary can also be renamed and replaced with a script (or
executable stub) that calls the renamed binary with the -c option to specify a
different location for the configuration directory.  We have no intention of
allowing individual files to be relocated outside the configuration directory
through any measure other than symbolic links.

> b) to be able to disable the "Save Password" option and ensure it cannot be overridden by the user by default

I'm sure we'd accept a patch that allowed this in a portable fashion--i.e. one
not tied to any specific OS.  As it is, however, I seriously doubt any of us
care to implement this ourselves.

> 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 :/

There is no intent to ever provide encryption on the file itself or the
passwords stored in it (again, the false sense of security).  If your file
system's permissions model is insufficient to protect the file, find a better
filesystem.  If your understanding of the file system's permissions model is
insufficient, learn about it.  NTFS and all common UNIX file systems provide
adequate protection for the file; arguments about the disk falling into the
wrong hands don't really carry any weight, because if the disk is lost you're
screwed whether there's a hash or encryption or anything else.  If your disk is
lost, you have much bigger problems than lost IM passwords.  However, the
ability to use external keyrings for more "secure" storage of passwords has been
the focus of a Google Summer of Code project this year.

> 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!

If our position on any matter costs us a few users, we're willing to live with
that.  Being the most popular IM application has never been our goal--our goal
is to make Pidgin the best client it can be for ourselves and those who think
and act like we do.

John

Attachment: signature.asc
Description: OpenPGP digital signature