Plain Text Passwords

Purple does not now and is not likely to encrypt the passwords in the accounts.xml file, nor is it likely to be encrypted in a future release. This is somewhat controversial in Windows, where file permissions have traditionally been more open, but that's the way things are.

The reasoning for this is multi-part.

Instant messaging is not very secure, and it's kind of pointless to spend a lot of time adding protections onto the fairly strong file protections of UNIX (our native platform) when the protocols themselves aren't all that secure. The way to truly know who you are talking to is to use an encryption plugin on both ends (such as OTR or pidgin-encryption), and use verified GPG keys. Secondly, you shouldn't be using your instant messaging password for anything else. While some protocols have decent password security, others are insufficient and some (like IRC) don't have any at all.

There are basically four approaches to password storage.

• Store a password(s) behind a password. Basically this means that we require you to type in some passphrase as Pidgin or Finch starts in order to read the accounts.xml file, and, to be truly secure, require you to type it again if you write to it. Windows ICQ does something very similar to this if you set it to its highest security settings.
• Obscure a password. This means we do something to store the password in some format other than plain text, but we automatically convert it for you. This is security by obscurity, and is a Very Bad Thing^TM in that it gives users a false sense of security that we (Pidgin, Finch, and libpurple developers) believe would be worse to have than to let informed users deal with the password issue themselves. Consider that a naive user might think that it is safe to share his or her accounts.xml, because the passwords are "encrypted".
• Store the password in plain text and control access to the file. This is what libpurple (and therefore Pidgin and Finch) does: the password is in accounts.xml in plain text, but the file itself is only readable by its owner. We allow the user to determine under what conditions sensitive files should be opened (if at all), and what constitutes a breach of security.
• Lastly, you can not store passwords at all. This is Purple's default, and by far the most secure of all of the options.

If you really wanted to, you could write a script to wrap Pidgin or Finch that would decrypt accounts.xml and re-encrypt it when the application exits. You wouldn't be able to encrypt it while they are running, because libpurple clients write to accounts.xml for things like info change. This would minimize your exposure time unless (like me) you run Pidgin nearly 24/7. Personally, I feel that on any decent operating system, if someone can get to your files you should either be able to trust the person to not touch them, or you shouldn't be storing sensitive information there at all.

"But other programs don't store my password in plain text!"

That's true. But few of them store it in a way that's any safer. A Google search for ​im passwords shows a bunch of hits for getting the passwords out of other IM clients just as easily as Pidgin.

The very first link is a clear indication that none of these IM applications provide any sort of real password security:

• ICQ and ICQLite
• AOL Instant Messenger and AIM Triton
• AIM Pro
• Yahoo! Messenger
• Excite Messenger
• MSN Messenger and Windows Live Messenger
• Microsoft Office Communicator 2005
• Google Talk
• Odigo
• Trillian
• AT&T IM Anywhere
• T-Online Messenger
• Match Messenger
• Praize IM
• ScreenFIRE
• ACD Express Comunicator
• Imici Messenger
• Prodigy IM
• PowWow Messenger
• Jabber IM
• Kellster IM
• PalTalk
• Indiatimes Messenger
• Miranda
• Tiscali
• Ya.com Messenger
• Rediff Bol
• Sify Buzz
• Devil
• Tencent QQ and QQ (Africa Version)
• &RQ
• Ipswitch Instant Messenger
• Eighth Wonder Catax
• Simple Instant Messenger
• Vista IM
• GAIM
• Global-IM
• Psi Jabber client
• Messenger2
• Picasa Hello
• iWon
• Blowsearch
• MessageMate
• Meca Messenger
• Qnext
• Bubbler (Five Across)
• InterComm IM (Five Across)
• Easy Message
• QIP
• Gizmo
• MySpace IM
• Exodus
• Gadu-Gadu
• Mail.Ru Agent
• ScatterChat
• Just Another Jabber Client
• Maple Messenger
• Pandion
• IMVITE Messenger
• Oyco Messenger.

"But surely something is better than nothing, right?"

No. When a Pidgin user looks at her accounts.xml file, she can tell immediately that it's a sensitive file and should be treated as such. When an application attempts to 'trick' the user into thinking its passwords are secure by obfuscating it in some way, the user assumes it's safe.

It is an absolute fact that people will share their accounts file, with their supposedly safe passwords, even in very public places: typically so that they can conveniently access their settings remotely. Not only can these passwords be trivially decoded, if you plug those settings files into the same client, it will login without even needing to decode it.

Having our passwords in plaintext is more secure than obfuscating them precisely because, when a user is not misled by a false sense of security, he is likely to use the software in a more secure manner.

When people propose inefficient security, it's because they prefer a false sense of security to a false sense of insecurity. File systems, in general, do a very good job of keeping your information private. For most people, there is no insecurity inherent in plain-text passwords. There's only the perception that, because they can read their passwords with ease, that perhaps others can too. Obfuscated passwords are no more secure than plain text; they can be read, about just as easily with the aid of certain programs. It provides a false perception of security.

We're 100% fine with people having false perceptions of how insecurely Pidgin handles your passwords. We are not, however, fine with sacrificing actual security for false security.

"But I'm in a corporate environment! One password does everything!"

Then don't save your passwords in Pidgin or Finch. As noted above, not saving the password is the default behavior. This is another instance of "if someone else can access your files and you can't trust them not to misuse stored sensitive data, don't store the sensitive data." Besides, you have to log in to your operating system anyway; it's not really going to kill you to have to type the same password one more time.

"Is that the final word?"

No. The Pidgin developers are generally open to, and would encourage integration with keyrings (KeyringSupport). A keyring is an implementation of the first bullet point above. It would be used to cryptographically secure your password in a way that would generally be more secure (although not perfect). It would require a master password, shared amongst all the applications on your computer, to get at your passwords.

The problem is that Pidgin runs on so many different environments, each of which has their own system for keyrings. It's difficult (but not impossible) to make Pidgin integrate with all of these, and still allow you to use one set of configuration files for each of them.

If someone were to do this in a way that worked well, securely, and seamlessly to the user, without interfering with people who prefer to trust their file system's security, we'd gladly accept it.

DIGEST-MD5 in Jabber/XMPP

​RFC 3920 requires that Jabber/XMPP servers implement SASL DIGEST‑MD5 authentication method. This allows clients (and servers) to not store the password in plain-text but instead store cryptographic hash (MD5) of user name, domain and password. If the password is strong this makes nearly impossible for an attacker to recover the password.

Following downsides remain:

• If accounts.xml is revealed, the attacker is still able to login to the Jabber account (but not to, say, email account, even if they had the same password)
• User may by fooled in to believing accounts.xml does not contain sensitive information and give the file out. (If the password is weak it can be recovered from the hash)
• When server stops supporting DIGEST‑MD5 authentication (but still provide other password-based), Pidgin will have to ask for password.

Currently (as of 2008) Pidgin does not store the hash. elb: "I would accept a good patch to implement that"

As of 2010, the draft version of the next XMPP standard specifies ​SCRAM-SHA-1 as the mandatory-to-implement mechanism, replacing DIGEST-MD5, though not all servers support it currently.