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.Sean Egan, primary developer of Gaim/Pidgin replied:
“Here is the official response: basically if people are snooping around your personal configuration files, you probably have bigger problems than your IM passwords.
That said, there have been a few mailing list threads and even patches about it, which you can find with some Googlng.. You may additionally add that we have no problems at all accepting a patch that would encrypt passwords with a keyring, but are very much against tying to any one particular keyring implementation, a requirement nobody has managed yet to meet.
This is the beginning of the most recent thread on the issue. If you want a quote from me, please quote me from there, especially the “Certainly, if done right, nobody objects to this feature,” line :)”
While on Linux this might not be a major concern as there isn’t enough malware (even if Pidgin does not use the Gnome keychain to authenticate as it’s available at least on Ubuntu), this can be a huge problem in the Windows world. Now, this is not necessarily worse than malware reading cookies just about as easily from web browsers, but still, some encryption should be present to at least protect us from the less… capable malware or even admins who snoop on their user’s PCs, or users who allow fellow-workers to use their PC under the same user account (this happens rather often for a variety of reasons, especially in marketing environments where companies don’t have enough licenses for expensive graphics software for all their PCs). A quick look at Miranda and Trillian showed that both of these apps are encrypting their passwords.
Jabber enthusiast and hacker Robert Quattlebaum (also known for Synfig) tells us that “I agree that some minimal encoding should be performed to prevent shoulder snooping if the contents of those files were displayed. ROT13 would be adequate. [But] adding something more complicated that still doesn’t authenticate the user is just going to give you a false sense of security.”
We can only hope that at least for the Unix version Sean will accept the Gnome-Keyring patch, and for Windows he will at least employ some form of encryption in the next version of Pidgin.
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).
Except that most people run as Administrativve accounts in Windows, so anyone can read it.
No, that would mean “most accounts” could read it.
I hope you language lawyers don’t charge a retainer
I thought since this was an open source application it would be so much more secure.
I thought since the code was available for all to see and security flaws would be found and plugged immediately.
How could this happen? I thought open source development was supposed to find and fix these vulnerabilities quickly. According to the article this has been around for a while.
Given that this is such a simple application (compared to say the linux kernel), I can only imagine how many stupid security flaws exist in the Linux kernel, or Samba, or X.Org, etc…
I guess it goes to show that open source software isn’t as safe as we’ve been led (brainwashed) to believe.
I don’t really see what is the point you are trying to bring in here.
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.
Me Fail English? That’s Unpossible!
Stop using those silly Americanisms, the word is “Depossible”!
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.
“ESR addressed this in CatB, in re fetchmail: […]”
Just as a side note (and maybe I’m going off topic): If fetchmail regocnizes the user’s setup file to have insufficient protection, it gives a warning, such as this:
% ll .fetchmailrc
-rw-r–r– 1 xxx yyy 791 Nov 25 19:05 .fetchmailrc
% fetchmail
File /home/xxx/.fetchmailrc must have no more than -rwx–x— (0710) permissions.
% chmod 600 .fetchmailrc
% ll .fetchmailrc
-rw——- 1 xxx yyy 791 Nov 25 19:05 .fetchmailrc*
% fetchmail
fetchmail: No mail for blah at bli.blu.blo
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.
You just don’t get it.
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.
Edited 2007-05-23 10:25
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…
Tom
One way hashes are irrelevant in this case. The clear text password has be used to authenticate with the remote system.
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.
“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.”
Encapsulating the whole comm protocol in an SSL would not help… I see.
“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.”
So the only secure way would be not to have the password stored in a file. Everything stored in a file can be accessed, at least with the user’s standard / minimal permission (u=r).
Encapsulating the whole comm protocol in an SSL would not help… I see.
Actually that will work, but it’s sort of a variation on the salted hash (albeit a far more sophisticated one). It’s still better to just not send the password at all.
“It’s still better to just not send the password at all.”
To extend security, it seems to be better not to save the password in a local file. But this would be bad for user friendliness – users want the computer to remember their passwords.
Every jabber server I connect to, including gtalk, uses SSL for encryption, so your password isn’t sent in plaintext.
Edited 2007-05-23 16:18
You can make a point that security through obscurity is not good, bu the point remains: it is better than nothing.
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.
I´m glad though we have shadowed passwords these days.
“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.
None of you around here get it.
Even if a solution is not 100% hacker proof, at least it’s DADDY proof. It is better to have SOMETHING, than having what we have now, which is one big fat *nothing*.
No. Bad security is worse than no security.
Local encryption is not bad security, it is simply not as strong as it can be. And it is well better than nothing at all.
Some people around here should really come down from their open source horse and understand that there is a problem that needs solution.
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.)
The only thing that would fix the problem is to not store the password on the disk. Anything else would only make you _feel_ safer.
The only patch I would accept would be one that issued a warning dialog that make it exceedingly clear that storing the password was at your own peril.
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.
“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.
[edited to include “not particularly” above].
Edited 2007-05-23 22:16
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.
“None of you around here get it. ”
The problem is that you don’t get security.
“Even if a solution is not 100% hacker proof, at least it’s DADDY proof.”
Instead of having applications implement hair brained (in)security schemes you should just secure your computer from daddy.
“It is better to have SOMETHING, than having what we have now, which is one big fat *nothing*.”
No it isn’t. A false sense of security (be it daddy-proof or whatever) is not better than knowing you don’t have any security.
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).
Edited 2007-05-23 03:38
“You are talking high-level and philosophically”
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.
Edited 2007-05-23 04:22
> the problem is that Joe User has local access to your account.
Yes, but it HAPPENS. I even gave an example on how this can happen, and it did happen when I was working in UK.
“Yes, but it HAPPENS”
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.
Sometimes a little bit goes a long way.
“No, it is very much your problem. ”
No, sorry, it very well isn’t.
“You’re supposed to accomodate your users as much as possible. ”
Only if they pay me or I really feel like it.
“The fact is that vast majority of computers are not secure and not used securely.”
No news here but it is still not my job to secure your computer. Some people use passwordless logins so should we expect every single application to encrypt any content it stores? There’s information far more important stored on many computers than IM passwords. Where’s my Notepad.exe encryption feature?
Either you properly protect the stored password (no ROT-13 or homebrew crap) or you don’t do it at all.
Using a key storage applicaton like kdewallet or gnome-keyring is a pretty good solution but storing plain-text passwords in the config file isn’t nearly as big an issue as some people here is making it out to be,
> isn’t nearly as big an issue as some people here is making it out to be,
Well, according to our experiences, it is. While I agree with you that a keyring solution is the best, you should also give us the benefit of the doubt regarding plain text encrypted passwords. Bend, like we do.
Ok, I rest my case.
Those are the kind of garbage arguments that give people a bad impression about oss.
Fortunately most devs take pride in their work and also put their credibility on the line when they release their work onto the world.
But there is definitely a few oss projects that have a bad reputation for having “hard line”, unaccomodating developers.
Guess where are those projects going? Nowhere!
“Those are the kind of garbage arguments that give people a bad impression about oss. ”
OSS has nothing to do with it. My argument would be the same even if it was in regards to closed-source free application. My time, my project, my rules.
“Fortunately most devs take pride in their work and also put their credibility on the line when they release their work onto the world. ”
It is exactly *because* I take pride in my work that I wouldn’t just implement any old feature random user X wants. Especially not if I thought it was a bad idea.
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 think that’s a bit of a straw man. For one, I’d expect a web based cracker to appear (hell, such things exist even for decently strong hashes).
“It is better to have SOMETHING, than having what we have now, which is one big fat *nothing*”.
Not true, you have file system permissions.
The feature is only used when you tick “Remember password”, and then it can only be viewed by users with read permissions on your profile directory (usually only you and the system administrator).
Firefox even has a “Show Passwords” button in the options window to show all saved passwords. Is that also a security bug?
afaik, the “show passwords” button only shows the domain name and username so you can manage the passwords.
Tools > Options > Security > Show Passwords > Show Passwords > “Are you sure” dialog > yes
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.
Exactly! Well said!
“Why does everything have to be such “hard-line” “everything or nothing” approach? ”
If something is worth doing then it is worth doing right. Either you use real security for the stored passwords or you don’t use any at all.
The easiest security implementation for this kind of software would be to use PAM to request the user to enter ‘sudo’ credentials to be able to access the file containing the passwords.
This would be most practical on systems like ubuntu.
-Ad
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.
-Ad
Then here’s a crazy idea: don’t ask Gaim (or any other program) to remember your passwords.
My solution to this would be as follows:
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.
Any thoughts on that?
“B) …”
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..
I beleive gnome-keyring already does that so the solution in this case would be to make pidgin use gnome-keyring in the same way kopete uses kwallet.
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.
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.
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.:)
<removed>
Edited 2007-05-23 12:00
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.
I’m tired of this. Could we just move along, please ? …
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/…
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.
Yeah right. You’re forgetting about rubber-hose cryptanalysis ( http://en.wikipedia.org/wiki/Rubber-hose_cryptanalysis ). The human is the weakest link in any security situation. Not mention human memory is leaky and lossy.
Edited 2007-05-23 20:07
I just now tried typing in “password” into Vista’s indexed Search, and sure enough, the accounts.xml file shows up as a result. Open up the file, and there will be all the stored passwords.
This save me my IM account lot of times !
Even if it’s insecure, having complicated password makes it harder to remind them.
For things like Jabber it’s good, my ex had set up a jabber account and had forgotten the password she used, we just had to open the file to get it, which was really good.
Gee, where are the times when everybody here sympathized with Eugenia. It looks like people really start loosing the edge when they get their first Apple fuskcget. Oh, is this a dirty word?
)
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.
Cheers!
I would need to be convinced that KDEWallet or gnome-keyring are safe against someone who would physically steal your computer.
If it has been crypted, it can be decrypted. No? I don’t think any wallet is that tamper-resistant? Please enlighten me.
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.
sure , i can see your point…
but the correct thing to do is like kde’s wallet : encrypt it , but say “hey , this is encrypted but not secure ”
the thing is that this “false security” will actually evade most problems !
its like an airbag .. i mean , its not like airbags make cars secure , right ?!
“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.
“This is exactly the kind of bad attitude that has given us the massive amount of insecure and badly written applications we have today.”
QFT, since I only can mod it up once.
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!
Edited 2007-05-23 11:07
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?
It’s not insecure when an open-source project does it.
Classy.
… until you combine it with another exploit (in a web browser, for example) that allows reading of local files.
…my copy of Gaim has been refusing to log me in without a manual password, eve though I requested it to remember. I believe they have disabled the feature (or my copy is broke.)
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.)
Straw man.
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.
I guess storing them in an gpg encrypted file is quite good, but it’s not “safe”. Just make sure noone else can use your account and you’re fine.
wow… this turned up into a big geek vs non-geek thing…
“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.