OSNews

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

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.

Stop using those silly Americanisms, the word is "Depossible"!

"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

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.

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.

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.

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

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.

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.

"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.

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.