Today, while I was trying to create a SIP Presence account for VoIPBuster, Pidgin kept crashing. I had to find its settings in my personal folder in order to manually edit the accounts.xml file and remove the entry (so Pidgin could start up again normally instead of keep crashing on load). When I opened the accounts.xml file with a plain text editor, all the passwords of all my accounts were listed out in the open in plain text. This is not a new issue, it was discussed many times before, but it can still be a surprise for most users.

On a Unix based system, just make sure that only the owner has read/write access to that file.
I cant say what the default permissions are on an NTFS based windows though I suspect that with FAT32 that file is unsecured.

That's correct. If it's a standard install on Windows, a Pidgin profile will be stored in %appdata% (which is roughly equivalent to a collection of the "dot" directories in the home directory on a *n?x).

That means that -- if "Documents and Settings" (or the custom equivalent) is on an NTFS drive -- non-administrator accounts can't access it, which is enough information for most people reading this to secure it without even touching NTFS ACLs (which is a sticky spider web itself, even if ultimately deviously fun).

This is not a security problem where someone on the outside can gain access to your computers or data like we see in web browser security threats and the like. From the OSNews description, the problem is that the password information is stored locally in an insecured way, but that does not mean that they are exposed to the outside. You are safe while you don't let someone else use your computer or get access to it thru another application's security hole (which can or cannot be an open source application). Looking at the Pidgin code will reveal where the file is written, how it is written, and how it is parsed, but it is no way a gateway to access the file's data.

The fact that the passwords are stored in an non-encrypted file is a problem, but do not make things up by spinning the whole thing.

In all fairness, I suppose there is a class of casual snooper who might walk over to someone's workstation and look in the settings file to try and get some passwords.

If someone had ten minutes to snoop around, having the passwords ROT13ed might protect you. If someone with the technical skills has physical access to your machine for as long as they need, simple ROT13 wont be enough to deter them.

As it it stands, with that program, anyone who has the sense to walk over to the machine and do a text search on all files for the word "password" is going to hit gold.

Come on, what's the point of this article? Stop pretending pseudo-encryption would help the user in any way.

AIM did that (probably still does) and made people believe that it was protected, so there were a bunch of methods used to retrieve someone's stored password. I had to change my password on AIM years ago before I understood that it wasn't real encryption.

If you care even the slightest bit about security, you shouldn't be saving your password at all. It's a bad idea to be able to log in to a system without authenticating yourself. If you want to - Fine. Noone is stopping you, but stop complaining about your desire for pointless cpu cycles.

There is no security hole here, at least not one that can be fixed in the general case. Stored passwords, by there very nature, don't involve any user authentication. To encrypt them would not add any security against attack, it would just obfuscate them a little.

ESR addressed this in CatB, in re fetchmail: in an open source app, encrypting stored passwords is wanking, because the decryption algorithm is necessarily documented in the source. (The same is, of course, true of closed source apps, just more painful to exploit: read machine code for source.)

To do some sort of encryption would just waste CPU cycles.

Now, integrating with keychain systems is legitimate, and would allow security-conscious users a better option, but in the common case, where there is no keychain, you have no authentication, so encryption wouldn't help.

In this example, setting 600 instead of 710, makes the file unsearchable for users of the same group (yyy).

"[...] in an open source app, encrypting stored passwords is wanking, because the decryption algorithm is necessarily documented in the source. (The same is, of course, true of closed source apps, just more painful to exploit: read machine code for source.)"

It is completely valid to document encryption and decryption. The trick is to construct a "one way ticket": You can encrypt a password, but you cannot decrypt it, or decryption has to require an impossible amount of time.

The usual way is using something working similar to crypt(): You can enter a phrase and get an encrypted phrase. To check a given phrase if it is the password, you encrypt it and compare it to the (still encrypted) password and see if they're equal - you do not decrypt the password itself.

bla ---crypt()--- qwzh(/63jhd&3487%&()(%H§&hfhw$

No other way round.

"To do some sort of encryption would just waste CPU cycles."

But I think we can affort this. Efficient conceptioning and implementing is no longer needed since we have CPUs that fast enough. No argument. :-)

"The usual way is using something working similar to crypt(): You can enter a phrase and get an encrypted phrase. To check a given phrase if it is the password, you encrypt it and compare it to the (still encrypted) password and see if they're equal - you do not decrypt the password itself."

Hashes only work if either you have complete control over the entire authentication process or the remote end happen to use the same hash algrithm that you do and is expecting you to send the hash.
Since Pidging is using closed protocols like IAM and MSN using a hash is most likely not possible, especially not if the protocol expects the client to send the actual unencrypted password.

You completely miss the point here. We're not talking about encrypting the password which is send to the IM login server, we're talking about encrypting the password which is saved in .pidgin/accounts.xml. I agree that storing the passwords unencrypted there IS a security hole. First, any malicious program could easily read all my ICQ passwords, and a "malicious user" could also easily open accounts.xml to read all my passwords, if he only finds 2 minutes to somehow get at my computer.

Pidgin NEEDS to be able to retrieve the plain text password. It doesn't matters what encryption method you use, it MUST be unencryptable, since you need to send the unencrypted password to the IM Server.

Doc Pain is suggesting that we hash the password, and then we ask the user to enter the password, hash it and check if it's similar to the hash in the configuration file. Yes, you can do this, but what's the stupid point of storing the password in the configuration file in order to automatically login in your IM account, if you ask the user to enter the password to check if the stored password is the rigth one???!? If you are going to ask the user the password, you may aswell _not_ store the password in the configuration file at all and ask it every time you want to login. Of course that's stupid aswell, most of people want automatic login.

It doesn't matter what you do, if your password is "foobar" you MUST send foobar to the IM server, so whatever encryption method you use is pointless because the application needs to unencrypt it _anyway_ and any hacker that finds a file will be able to steal it ANYWAY. What Pidgin does is just common sense.

You're completely right, I thought about this after I wrote my comment. This works for things like /etc/passwd, but it doesn't work when you for some reason need the unencrypted password for anything. Well sorry for being so harsh...

It is completely valid to document encryption and decryption. The trick is to construct a "one way ticket": You can encrypt a password, but you cannot decrypt it, or decryption has to require an impossible amount of time.

When I said "stored passwords" I meant the gaim case, not the passwd case. Here, hashing the password is not feasible, because we need the literal password to authenticate with the remote server.

Now, while we do have cycles to spare, unauthenticated encryption is still bad, not only on religious grounds, but because it gives the user a false belief that there password is secure, when it isn't.

(An aside on crypt(): the traditional implementation has been toast for some time, and md5 is dying too.)

"When I said "stored passwords" I meant the gaim case, not the passwd case. Here, hashing the password is not feasible, because we need the literal password to authenticate with the remote server."

Thank you for this correction, I see the main problem now. Transmitting passwords literally is a dangerous thing, just think about FTP and telnet...

Maybe other protocols offer higher security standards for user authentification? What about the Jabber protocol?

Could the protocol be changed, then? I think this could be really problematic...

"Now, while we do have cycles to spare, unauthenticated encryption is still bad, not only on religious grounds, but because it gives the user a false belief that there password is secure, when it isn't."

Maybe this is the nature of today's passwords... they are to simple (such as "password") or do not change often enough. Maybe it would be a solution to force the user to change the password from time to time, or it should contain a defined amount of lowercase and uppercase characters, along with numbers?

"(An aside on crypt(): the traditional implementation has been toast for some time, and md5 is dying too.)"

This is correct. I chose crypt() just as an example of a "one way ticket", because there's no uncrypt() that simply gives you the plain password from the encrypted string. Of course crypt() is no nonplusultra.

Actually in AIM/OSCAR the password is transmitted hashed, but to avoid replay attacks, the server sends a random salt, which is hashed with the password, and that hash is sent to authenticate. (If you think about it, an unsalted hash is really no better than a cleartext password.)

You don't have to send the password itself (hashed or otherwise) over the wire. You can use the password as a key to cryptographically prove that both sides know the password.

But, as I said before, you have to have the password in clear text which means that it cannot be encrypted with a one-way hash function. Sure, you could use the hash value to use as the key, but then the hash value itself _is_ the password.

I actually kind of agree that security through obscurity is valid _in addition_ to standard security methods. It's always possible that the one last step a hacker needs to take (ex a different name for the root user) might cause them to give up or even get caught in the act.

But in this case, it's some very different and you're setting a very bad precedent. Not only are you using absolutely NO real security, joe-user actually thinks that he's safe storing his password because of the claim of encryption.

Again, absolutely horrible practice... use a keychain or something. And why does everyone pretend that this is a useful feature anyway? It takes 5 seconds to type your password, and then you're done. This is wrong on so many levels...

Tell me, do you actually believe what you're saying? If Firefox or IE "encrypts" your stored passwords, would you trust your bank password saved? If so, I guess I misunderestimated you

At any given moment, you're either sitting in front of your computer, or you're not. If you're not, maybe you're logged in remotely. Regardless of what computer you're sitting in front of, when you get up and leave, log out. If someone might be looking over your shoulder, don't pick that moment to peruse your private accounts file. Problem solved. Logging out when you can't ensure the physical security of whatever computer you're using is just about the simplest security provision that exists. There are well-known programs, even amongst the relatively computer-illiterate, that require authentication after a period of inactivity.

I fully agree with the Pidgin developers. If Win9x doesn't provide the meager security features required to prevent unauthorized local access to private files, and if users cannot manage to log out, automatically or otherwise, when they leave their desks, then the entire idea of security is a moot point. If you absolutely have to use a system with a single user account shared by multiple users, then I would suggest choosing not to store your password and just type it each time.

Whether security through obscurity is better than nothing is a debatable issue. But above I described two incredibly simple ways to address the kinds of concerns you have. Is security through obscurity better than practicing the most basic user behaviors required for security? No, and may your deity of choice help us all if we raise more generations of computer users to be utterly clueless as to how to protect their data.

I think we can all agree that computer security is as much a social problem as it is a technical problem, if not more so. Particularly in the case of securing a system from local attacks, the buck stops at the user. The software developer cannot secure their software against insecure users.

"A quick look at Miranda and Trillian showed that both of these apps are encrypting their passwords"

So pray tell, where is the password you use for decrypting these passwords stored? Either it is also stored in plain text somewhere, stored encrypted with the key hard coded in the source or you get asked for the password every time you start them. If the answer is anything but the last there's no security.
We also don't know what algorithm they use so it might be ROT-13 (or equally useless) for all we know.

"ROT13 would be adequate."
It scares me that someone would seriously consider this an adequate option in 2007. It would add exactly zero in terms of security.

Open source has nothing to do with it.[1] Unauthenticated stored passwords are intrinsically insecure to local attack. No amount of fiddling can change that, and some sort of obfuscation only misleads the user into disbelieving the above truth.

[1] I will give you this: closed-source devs are often more willing to give the user a security feature s/he wants, even when the dev knows that it is useless. It's dubious, however, whether that is a good thing. (Actually, this doesn't just apply to security features, as Linus and Theo, inter alia, demonstrate.)

Some people around here should really come down from their open source horse

I fail to see where you want to land by taking this over into a FOSS debate. It has nothing to do with it whatsoever. And talking about high horses...

Local password storage is insecure by nature. As I said before, it's a comfort feature. You don't trust the OS, the machine's security settings, the other users of the machine, or yourself, then don't locally store the passwords.

Eugenia, you don't understand. This isn't a high horse. We are trying to explain that bad security IS worse than no security. Your statement that it is 'better than nothing at all' is provably false.

If someone wants to get ahold of your passwords, and has access to your computer and permissions on the file at hand, none of the methods listed will protect it at all. A keyring would, by removing the authentication step and placing it in that program, but that's your only choice.

Eugenia, you don't understand. This isn't a high horse. We are trying to explain that bad security IS worse than no security. Your statement that it is 'better than nothing at all' is provably false.

"Better" is a rather subjective term, and I as a result I suggest that "provably false" is [not particularly] meaningful.

Think of security in terms of automobiles. Automobiles tend to provide some measure of security against theft by incorporating key locks on the doors. However, this is not truly secure; windows may be broken, or locks picked. In many cases a thin piece of metal with a hook, commonly known in the US as a "slim jim" can be used by someone with modest skills to unlock the door without either damaging the car bypassing key lock altogether.

This could be considered "bad security". However, empirical evidence suggests that this security mechanism is effective at reducing the likelihood of someone stealing items in the passenger compartment (or the automobile itself) substantially.

To date, few would argue that this "bad security" should be eliminated altogether unless and until a better security technique is used.

Very true. Giving average users a false sense of security is the worst thing you can do. If someone would want real security in this issue, password storing should not be allowed so the user would need to explicitely authenticate him/herself before every and each login to the im network.

This whole issue is a non-issue really. Local passworsd storage is a comfort feature, not a necessity. If someone doesn't trust it, shouldn't use it.

Well, I disagree. You are talking high-level and philosophically, while I am talking practically. While a malware written by a CAPABLE hacker can break an encryption of an IM app, passwords won't snooped, neither they can be broken by Joe Users or less-capable script kiddies. It is FAR easier parsing an XML file rather than BREAKING an encryption. You like it or not, that's how it is.

But the fact is there is no breaking. The encryption key has to be included in the gaim source, or in one of those XML files. It's really as simple as a call into a standard encryption library.

Moreover, script kiddies are just that: _script_ kiddies. The script to circumvent any unauthenticated encryption scheme is pretty trivial.

The only gain in security is in keeping someone who doesn't want to know the password from learning it unintentionally, which seems unlikely, as there's no reason to go mucking around the gaim XML structure (usually).

No I don't. There are no worthy gains from implementing hair brained security schemes.

"passwords won't snooped, neither they can be broken by Joe Users"

The problem is not with Gaim storing unencrypted passwords, the problem is that Joe User has local access to your account. Windows has had multiuser for years now, there are no excuses for not using it.
If you let other people use your account you have bigger problems than them finding out your passwords for some IM services.

"less-capable script kiddies."

Less-capable script-kiddies just download and use the applications the more capable ones create.

"It is FAR easier parsing an XML file rather than BREAKING an encryption."

That depends on what encryption you are using. It is easier to make a program break ROT-13 than parse XML.

So what? As an application developer it's not *my* problem that you or your employer don't have enough sense to use your computer(s) securely.
If this is a big problem for you just don't save the passwords. That's even the default in Gaim/Pidgin.

So what? As an application developer it's not *my* problem that you or your employer don't have enough sense to use your computer(s) securely.
If this is a big problem for you just don't save the passwords. That's even the default in Gaim/Pidgin.

No, it is very much your problem.
You're supposed to accomodate your users as much as possible.
The fact is that vast majority of computers are not secure and not used securely.
And even more important fact is that people want to save passords so they don't have to reenter them every time.
It's also common to have, for example, one company email account used by several different employees.
Then you end up with either saving the password or posting it on a yellow sticky on the monitor.

And history shows what happened to the applications whose developers didn't listen to their users.
Example: Eudora was a featurefull and mature email program used by a lot of people.
But the devs were dead set against password protecting users profile and made it very hard to set up multiple users profiles.
Came Microsoft with Outlook Express. Gave users easy users profiles protected with passwords.
Good enough to keep family members or coworkers from reading each other's email.
Where is Eudora now? Extinct. Well, donating code to Mozilla last time I heard. Pfffhhh.

I simply have to disagree. Passwords are not stored somewhere that'd you'd stumble across them unintentionally (in another person's homedir, at that). If Daddy is seeing the stored passwords, then Daddy is doing it intentionally. If gaim implements unauthenticated encryption for stored passwords, I have no doubt someone will implement an online cracker for it. Daddy will not be stopped, because if Daddy has found where passwords are stored, he's probably able to google up a cracker.

Chances are that he won't. And it's not about daddy only. It's also about fellow workers and even admins. Besides, the person will need to install an app to run the cracker, while a quick snooping is much faster to do.

I have to agree with Eugenia.
Gee, you're not trying to protect the Fort Knox.
Just someone's password from snooping by a coworker.
Office staff are usually clueless and hiding the password would prevent people sharing the same computer from finding out each other's passwords.
Why does everything have to be such "hard-line" "everything or nothing" approach?
Yes, in 2007 it's absolutely inexcusable to have passwords in plain text.
For some things you don't need a bank safe, just a thin curtain which keeps others from peaking.

At work, my Windows system is owned by the company who has Administrator access. My domain account also has administrator access, so we essentially have multiple admins. While I mostly trust my company to not install keyloggers and not steal my password, it would be nice if this information can be moved off of the path of those who are just "curious".

You could create an account or profile that has access to the file containing the passwords and then remove admin or any other user access to that file. This way only the owner of the file could access it. The application accessing the file would need to request the credentials from you and authenticate with either GINA or ActiveDirectory to gain access. Or you could just run that application as the user that has access to the file.

A) The first time the user attempts to tell GAIM to remember a password, ask the user if they want to encrypt 'remembered' passwords for better security. if they answer no, do nothing, and keep storing passwords as they are now.

B) If the user answer yes, ask them for a secret phrase and then ask them again to verify it. The phrase will NOT be written or stored anywhere. This phrase is simply used to encrypt all of the passwords for all of the different IM accounts. In other words, we have one password/phrase to rule them all (kinda like the wallet on KDE - in fact, GAIM should use the wallet when running on KDE like Kopete does).

C) If the user has remembered passwords, when the application starts each time, ask for the secret phrase so the app can decrypt the passwords and then log the user in to the various IM accounts.

Note, the best way to encrypt the passwords will be to generate a hash from the secret phrase (say using SHA256), then use the output of the hash (a 32 character string) as the input into say 256 bit AES for encryption. To the best of my knowledge, SHA256 and AES are NOT hackable at this point in time.

This solution creates a very secure environment where multiple passwords can be stored and recovered using a single pass phrase.

Indeed, this is the only way this could be done "securely", the important part being that the "master password" should never ever be stored anywhere.
Whether the developers see any point in doing this is of course an entirely different matter.

B) If the user answer yes, ask them for a secret phrase and then ask them again to verify it. The phrase will NOT be written or stored anywhere. This phrase is simply used to encrypt all of the passwords for all of the different IM accounts. In other words, we have one password/phrase to rule them all (kinda like the wallet on KDE - in fact, GAIM should use the wallet when running on KDE like Kopete does).

This would work but...ummm, it nulls the whole point of remembering the passwords, you know? When a user checks the "remember password" box, he/she doesn't want the app to ask for any password. But in this case, he/she would still have to submit a password..

On a system with basic security, this is what already happens in practice. You cannot access another user's files unless you log in as the user (or some special super user). That's the whole point of file permissions on Unix: you can allow or disallow the user, the group, and "the world" to read any file you own. If you set your Pidgin password file to not be readable by anyone but the owner, you need to log in as the owner before reading it (in other words, you need to know the login password).

Besides that, if you already know the login password, there are more serious problems than IM account information being exposed.

Why not somehow use login password to encrypt the passwords stored by gaim?

This way unless you know the login password, there is no way to decrypt the passwords.

Yeah that's the point of a "keychain" application and exactly how it works with Adium on OSX (which uses the pidgin libs.) And it can be set to lock if you're away from the computer.

I'm amazed at all the resistance here to what is just common sense. You simply don't store passwords in clear text, especially in this age of desktop document indexers, it's insane. Imagine doing a beagle-search (or whatever the indexer du jour is on linux) for "password" and turning up all your passwords in clear text.

This way unless you know the login password, there is no way to decrypt the passwords.

Yeah that's the point of a "keychain" application and exactly how it works with Adium on OSX (which uses the pidgin libs.) And it can be set to lock if you're away from the computer.

I'm amazed at all the resistance here to what is just common sense. You simply don't store passwords in clear text, especially in this age of desktop document indexers, it's insane. Imagine doing a beagle-search (or whatever the indexer du jour is on linux) for "password" and turning up all your passwords in clear text.

Amen to that!
You are absolutely right.
Could it happne on Vista also that you just type the nickname and out pops out the highlighted nick/password line from the xml file.?
Can someone try it?
I don't have Vista/Pidgin combo available yet.:)

magine doing a beagle-search (or whatever the indexer du jour is on linux) for "password" and turning up all your passwords in clear text

No, I won't imagine such a nonsense. A desktop file indexer has no businness giving my file contents as responses for another user's queries. If it does that, it goes straight to hell and voila, there's no indexer to give back that information.

Other than that, believe it or not, we also use keychains, gpg, encrypted folders, kdewallet (my favourite) and whatnot.

The issue in this particular case is not about what we can or could or should use. It's about avoinding the false sense of security that a weakly encrypted password file would give to the average users and many of us just simply suggest that if the computer or the users can't be trusted than simply don't ever store your passwords locally, either in plain text or else.

I more and more feel this whole thread is just a waste of time. On one side, some people just don't get it that the only secure place for your passwords is in your head, and not on your hard drives, in whichever form. Blaming an IM application's developer for creating a comfort feature (wow, I think I've said this about 5 times today already) which is and should be optional. As he said, he's open for contribution, given specific constraints. So, either contribute in solving the issue which, mildly put, isn't everyone's problem, or just don't use that feature and input your password at each login, which is also more secure.

No, I won't imagine such a nonsense. A desktop file indexer has no businness giving my file contents as responses for another user's queries

How about another user that uses your pc while you're away? Anyway it shouldn't be stored in a format where it can easily be recognised for what it is and indexed/grepped/...

The issue in this particular case is not about what we can or could or should use. It's about avoinding the false sense of security that a weakly encrypted password file would give to the average users and many of us just simply suggest that if the computer or the users can't be trusted than simply don't ever store your passwords locally, either in plain text or else.

False sense of security ? You mean like locks on doors which are easily defeated by a cheap and fast brute force solution (crowbar) ? Minimal security is the first deterrant and a sign that this data/property is off limits and to proceed shows bad intentions.

On one side, some people just don't get it that the only secure place for your passwords is in your head

The point that was made, with another user working from my windows account is invalid. Because even if the password was stored encrypted in the accounts file, he would just have to start your Pidgin app and he would be able to login without any effort. So, again, false sense of security, and bad practice. Do as Mozilla does, let users know that stored passwords are not secure if other people have access to your computer and your account.

If you are ok with only some security (thin curtain), instead of good security, why are you not content with the current state of the things. The password never appears in clear text on your screen; the password is stored in an xml file (not nice to look at, compared to .ini for example); the file is in a directory that belongs to your user on the system, hard to navigate there and hit on the file by mistake (Eugenia said it was not easy to find it; in linux it's under .purple dir, hard to link to pidgin).
So there's your thin veil! Hope you are content...

Beside keyring they could use a master password like Mozilla does in Firefox/Thunderbird. I feel much safer with having a master password to keep all of my other email and website passwords from people's eyes.

It's not difficult to come to your computer for just a minute and look at the passwords.

Security may not be perfect in theory - if you want total security, of course there is nothing can be done here.

But programmers of Pidgin should protect users from simple cases like a look behind the shoulder, or from copying accounts.xml to a flash USB...

It's very naive from the author to put the comments on this issue to /dev/null. I know enough situations where it could be a risk:
- co-workers
- co-dorm people
- and what happens when someone has stolen your laptop?
Well luckily I use kopete which stores my password in the kde wallet.

Again, invalid argument. The password never appears on screen in plain text. Well except if you open the accounts file with an editor, and then it's mangled between lots of xml tags, and you can look over your shoulder to check that no one is looking when you open the file. Plus you should have no bussiness opening that file, or if you do, you take the risk of breaking your app, security breaches, etc.

you think that no security is better than "daddy security" , as eugenia put it.

really , you should get out of your geeky basement , and see that to 99 % of the population in the world , if you cant read in plain english the password , you simply give up. you see it encrypted, and give up , think its impossible !

if you think that everyone in the world , see an encrypted password and then goes " ... ohh .. let me just read the program source code , and try all the schemes ".... you are living in another world!

"really , you should get out of your geeky basement , and see that to 99 % of the population in the world , if you cant read in plain english the password , you simply give up. you see it encrypted, and give up , think its impossible ! "

This is exactly the kind of bad attitude that has given us the massive amount of insecure and badly written applications we have today. Hey, if Joe User can't tell why bother doing it correctly? Just lie and say it actually does what it says it does and everyone will be happy.

"its like an airbag .. i mean , its not like airbags make cars secure , right ?!"

This is more like an airbag made out of the kind of plastic bag you get in a convenience store. Sure, it's white and looks kinda like an airbag and maybe Joe Averag won't notice but when the shit hits the fan the airbag won't do him no good.

If another user that YOU DO NOT TRUST, has access to your account in any OS, THAT is the biggest security breach after him having administrator acces. If he wants to, he can install a keylogger in about two minutes (on linux, win32, osx, etc) and then he can have your passwords, no matter if you save them on disk or not, or if they are encrypted or not. Companies have policies against this kind of thing, and if you are working in a place that doesn't have such a policy, you should make your own.

If you are not allowed to have this kind of policy on your work computer, DO NOT store, use, or attempt any private exchange of information on that computer!

Uf, I'm stepping on someone's nerve here But I do agree: if you lost control over your network by too much glitz yo better obfuscate everything into oblivion and send the keys to ... wherever their HQ are

Since we are talking about an FOSS project we come to the worth of implementing a change. If someone thinks it's important to have ROT encrypted passwords they should invest their time/knowledge or money into implementing it. I doubt that it would be accepted in the Pidgin trunk, so a fork (and a maintainer) may be neccesary.
About the good implementation (yes it may exist and has been talked here), with SO keychains it won't be accepted if it doesn't work in a portable way (not Gnome, KDE, etc specific), so gather your hackers and start working, if you really think it's such a big deal.

1. Any user thats going to look into the config files and NOTICE their password is kept unencrypted is going to be knowledgeable enough to understand the consequences...hence why so many people suggest not to save passwords.

2. Now, the other user that is not going to investigate their config files...they will never open them up and hence no one is going to peep over their shoulder to see it. The only way they might expose their password is if they do a desktop search (see Tyr)

3. How about malware. What if your computer gets infected with malware and the malware reads your password and then spams your contact list? Well if the malware is gong to target pidgin config files in the first place, even if it had encryption, it would bypass it.

4. About the only real use case is if you let someone have access to your account (either a sys-admin, or you just leave it on for a while), and they browse to get your password. Once again, if they're looking for it, they will know how to crack even the encrypted password.

Would it hurt to have the encryption?
Well it might hurt case 1. They might browse, see an encrypted password and think its secure.

It would benefit case 4. They might not have enough time to copy/crack the password. Maybe they're just browsing your computer, and wouldn't bother really trying to hack anything, but if they see an unencrypted password...they might just make note of it.

It would benefit case 1,2 in terms of desktop search and other inadvertent displays of password.

Now of course this all assumes a simply encrpytion method, not a keychain type password, which would of course be one of the best methods.

2. Now, the other user that is not going to investigate their config files...they will never open them up and hence no one is going to peep over their shoulder to see it. The only way they might expose their password is if they do a desktop search (see Tyr)

Highly unlikely: if the desktop search starts indexing your apps' settings files, then there's something wrong with that desktop search. They're meant to search and index through regular files which the user would most likely want to have indexed, not some obscure settings for which a regular home user would have absolutely no interest in at all. AFAIK: Beagle nor the search app in Vista does index apps' settings files...

Would it hurt to have the encryption?

I think it would hurt more than it'd benefit. See my other post for explanation.

I really have to disagree with Eugenia on this whole issue...Sure, if the passwords were encrypted one way or another, it wouldn't be that easy to read them..But then on the other hand, if other users gain access to your accounts.xml file, it's YOU who's the security risk. If you let other users use your account then no encryption scheme will do you any good. The user could just copy the file to an USB disk and decrypt it at his/her own leisure any time later anyway. And well, if you worry about other users snooping over your shoulder: well, why the heck are you even opening the accounts.xml file when others are looking? Or why would you open it in the first case anyway? And think about it another way: a lot of computer illiterate people would think it is actually SAFE to store their passwords if they just hear the word "encrypted", so they wouldn't worry about other users accessing their files cos they'd think it's secure.. That's actually the way it would happen in real life. Still think security through obscurity is enough or even a good idea?

I've never quite understood why people simply give-up when a theoretical attacker has physical access. It's not even an uncommon scenario, since all external physical security measures can be defeated (door locks for example). Taken to the logical extremes that defeatists will go to, even encryption (with an unknown key) is worthless since every algorithm other than an OTP can be brute-forced given enough time. Sure, there is no (possible?) method of completely securing a computer from a physical attacker, but the point of security isn't to make something impregnable given infinite resources, it's to make the cost of gaining access prohibitive.

Encrypting the stored passwords with some random password stored in plaintext elsewhere won't stop a determined attacker with detailed knowledge of Gaim's security measures. But it will almost definitely stop a nosy college roommate. Full disk encryption and a screensaver might not stop the NSA, but it'll probably stop just about everybody else from gaining access to the data on a stolen (or seized) computer. "Everything or nothing" is a false ultimatum. After all, show me a security measure that you claim can never be defeated under any circumstances and I'll just point at you and laugh. (That's not to say one shouldn't strive for the best possible security, but no security is effectively the worst possbile security.)

The argument isn't that no security is better than having security. The argument is that _false_ security is worse than no security. A trivial encryption scheme will only lull you into believing you're safe when in fact you are not.

If you were to ride a motorcycle, would you put a bucket over your head in place of a proper helmet under the guise that something is better than nothing? I wouldn't. I just wouldn't ride.

The recommendation is to _not_ save your password on disk unless you're sure that the file that contains it is secure.

Oops, I wasn't intending to use a straw man, but since I don't see the merit in the opposing position I'm willing to assume that I've misinterpreted it. So I will address the argument that false security is worst than no security, as it applies to storing plaintext passwords in Gaim. As I understand it you are arguing that because pseudo-encryption can be easily defeated it provides no real protection, and encourages the user to naively engage in unsafe activities while believing themselves to be protected. If that is an incorrect assessment then feel free to ignore the rest of this post, and point out that I apparently have no idea of what I'm talking about. BTW, I'm also sorry to have responded to your short post with a long one, but I got bored waiting for a download to complete and as such became very verbose.

I see two falsehoods in your argument as I've interpreted it. The first is that pseudo-encryption (real encryption but with a key that is contained in plaintext elsewhere) offers no "real" security. As I tried to argue in my original post, all security can be eventually defeated, whether by bruteforce, physically breaking into someone's house to gain physical access, or by social engineering. The purpose of security is not to make cracking impossible, because such a security measure is impossible to create. The purpose of security is to make cracking too costly to be worthwhile, or impossible given the relevant timeframe. Plaintext does not slow down an attacker at all. Pseudo-encryption requires that an attacker learn how Gaim encrypts passwords, learn where the key is stored, and then decrypt the passwords. So, in other words, it adds a layer of obfuscation. This adds a fixed amount of time to the first attack (for learning), and an ignorably trivial amount of time to successive attacks. Essentially a speed-bump. Now, this won't stop a dedicated attacker, but it will probably stop a casual one (a roommate for example). Even if it only added 15 minutes to the required attack time, that might save you if you forget to lock your computer before leaving for lunch. Since this is an optional measure for a relatively unimportant service (which is very common on personal computers) then this should be enough, and serve in lieu of an impossible "real security" mechanism.

The second component of that argument which I disagree with is that it lulls the user into believing that they are secure. In this case I don't think that it would. First of all, this type of encryption is completely transparent to the user. Secondly, if the user is having Gaim "remember" passwords then they probably aren't trying to fend off a dedicated attacker. Thirdly, I would assume that Gaim warns you about the insecurity of "remembering" passwords. Since there isn't a claim of being secure, and the user wouldn't normally notice such a security measure, I don't think that it would affect behavior. I.e. I can't see how the average user (that wouldn't know better) would even know that this is happening. Also, as I mentioned before, if they cared greatly for strong security then they wouldn't have Gaim "remember" their passwords in the first place.

I agree that this would be worthless against a skilled and determined attacker, but I think that it would help in certain situations. I also don't think that all attacker are both skilled and determined. If there isn't a downside to implementing it (a false sense of security or a non-trivial CPU cycle requirement), then why not? It's not like such scenarios are unlikely or there isn't a demand. Thus the reason that I attribute to it is the false ultimatum caused by defeatism. There is no ultimatum because a measure such as this does not preclude superior security measures, and I do not think it would cause changes in user behavior, so in a worst case scenario it does nothing. You probably can't make a system impervious to a physically attacker, but that doesn't mean that you should make their job easy with plaintext passwords and such.

"Secure should be done in the system.", "On unix it's already secure enough"...

"It should be Daddy-proof", "something is better than nothing"...

It's all about who use it... Pidgin is not just an *nix IM anymore... It doesn't even needs to be installed (see the portable version for more info) anymore... I can't imagine how terrible it would be if you loose (or have it stolen) your portable drive (flash or whatever) and then anyone how can type into a writing program can "discover" you password...

...I don't think that your work computer will be secure enough from someone else who also works there... Forgetting your portable drive at your friends' home doesn't seem as a uncommon thing...

...Maybe something is better than nothing in the end...

...but I really think that tempting solutions as keyring for gnome and MacOS X builds should be no problem at all...

I'm not going into the subject if the story was the proper way to discuss that or not (after so many years it may be... but still...), but if the problem is already in discussion... maybe it's time to solve it for real...

People should understand that there are multiple levels of security and they each serve a specific purpose. And yes, there are multiple workarounds - like not storing passwords. With IM, we're broadcasting messages through an open protocol - we're not *that* concerned about security. But a little courtesy so that passwords aren't completely in the open isn't a bad thing... and it's probably literally a few lines of code.