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.
To read all comments associated with this story, please click here.
Member since:2006-10-08
"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. :-)
Member since:2005-08-18
"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.
Member since:2005-07-06
Member since:2007-05-23
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.)
Member since:2005-06-28
Member since:2006-09-13
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 
Member since:2005-07-08
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.
Member since:2005-07-06
Member since:
2007-05-23
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.