Linked by Eugenia Loli on Wed 23rd May 2007 00:46 UTC
Privacy, Security, Encryption 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.
Order by: Score:
rw access
by ciphernaut on Wed 23rd May 2007 02:27 UTC
ciphernaut
Member since:
2006-01-12

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.

Reply Score: 2

RE: rw access
by Spellcheck on Wed 23rd May 2007 02:41 UTC in reply to "rw access"
Spellcheck Member since:
2007-01-20

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

Reply Score: 3

RE[2]: rw access
by BluenoseJake on Wed 23rd May 2007 15:12 UTC in reply to "RE: rw access"
BluenoseJake Member since:
2005-08-11

Except that most people run as Administrativve accounts in Windows, so anyone can read it.

Reply Score: 4

RE[3]: rw access
by Spellcheck on Thu 24th May 2007 07:19 UTC in reply to "RE[2]: rw access"
Spellcheck Member since:
2007-01-20

No, that would mean "most accounts" could read it.

Reply Score: 0

RE[4]: rw access
by BluenoseJake on Thu 24th May 2007 09:57 UTC in reply to "RE[3]: rw access"
BluenoseJake Member since:
2005-08-11

I hope you language lawyers don't charge a retainer

Reply Score: 1

v Wow
by linuxh8r on Wed 23rd May 2007 02:28 UTC
VManOfMana
by VManOfMana on Wed 23rd May 2007 02:36 UTC
VManOfMana
Member since:
2006-11-01

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.

Reply Score: 5

RE: VManOfMana
by rhyder on Wed 23rd May 2007 06:41 UTC in reply to "VManOfMana"
rhyder Member since:
2005-09-28

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.

Reply Score: 3

Oh Noes
by AndrewW on Wed 23rd May 2007 02:45 UTC
AndrewW
Member since:
2006-09-13

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.

Reply Score: 5

Unsecure
by sdodson on Wed 23rd May 2007 02:46 UTC
sdodson
Member since:
2007-01-06

Me Fail English? That's Unpossible!

Reply Score: 5

RE: Unsecure
by Kroc on Wed 23rd May 2007 07:37 UTC in reply to "Unsecure"
Kroc Member since:
2005-11-10

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

Reply Score: 3

not a hole
by notabel on Wed 23rd May 2007 02:46 UTC
notabel
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.

Reply Score: 5

RE: not a hole
by Doc Pain on Wed 23rd May 2007 03:02 UTC in reply to "not a hole"
Doc Pain 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. :-)

Reply Score: 4

RE[2]: not a hole
by Soulbender on Wed 23rd May 2007 03:17 UTC in reply to "RE: not a hole"
Soulbender 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.

Reply Score: 4

RE[3]: not a hole
by el3ktro on Wed 23rd May 2007 08:51 UTC in reply to "RE[2]: not a hole"
el3ktro Member since:
2006-01-10

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.

Reply Score: 2

RE[4]: not a hole
by diegocg on Wed 23rd May 2007 10:23 UTC in reply to "RE[3]: not a hole"
diegocg Member since:
2005-07-08

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

Reply Score: 5

RE[5]: not a hole
by el3ktro on Wed 23rd May 2007 10:41 UTC in reply to "RE[4]: not a hole"
el3ktro Member since:
2006-01-10

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

Reply Score: 5

RE[2]: not a hole
by rajj on Wed 23rd May 2007 03:22 UTC in reply to "RE: not a hole"
rajj Member since:
2005-07-06

One way hashes are irrelevant in this case. The clear text password has be used to authenticate with the remote system.

Reply Score: 2

RE[2]: not a hole
by notabel on Wed 23rd May 2007 03:23 UTC in reply to "RE: not a hole"
notabel Member since:
2007-05-23

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

Reply Score: 2

RE[3]: not a hole
by Doc Pain on Wed 23rd May 2007 03:43 UTC in reply to "RE[2]: not a hole"
Doc Pain Member since:
2006-10-08

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

Reply Score: 3

RE[4]: not a hole
by notabel on Wed 23rd May 2007 03:47 UTC in reply to "RE[3]: not a hole"
notabel Member since:
2007-05-23

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

Reply Score: 3

RE[4]: not a hole
by rajj on Wed 23rd May 2007 04:11 UTC in reply to "RE[3]: not a hole"
rajj Member since:
2005-07-06

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.

Reply Score: 2

RE[5]: not a hole
by Doc Pain on Wed 23rd May 2007 17:36 UTC in reply to "RE[4]: not a hole"
Doc Pain Member since:
2006-10-08

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

Reply Score: 2

RE[6]: not a hole
by rajj on Wed 23rd May 2007 17:47 UTC in reply to "RE[5]: not a hole"
rajj Member since:
2005-07-06

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.

Reply Score: 1

RE[7]: not a hole
by Doc Pain on Wed 23rd May 2007 18:53 UTC in reply to "RE[6]: not a hole"
Doc Pain Member since:
2006-10-08

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

Reply Score: 2

RE[4]: not a hole
by intangible on Wed 23rd May 2007 16:17 UTC in reply to "RE[3]: not a hole"
intangible Member since:
2005-07-06

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?


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

Reply Score: 2

RE: not a hole
by Eugenia on Wed 23rd May 2007 03:12 UTC in reply to "not a hole"
Eugenia Member since:
2005-06-28

You can make a point that security through obscurity is not good, bu the point remains: it is better than nothing.

Reply Score: 1

RE[2]: not a hole
by AndrewW on Wed 23rd May 2007 04:14 UTC in reply to "RE: not a hole"
AndrewW 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 ;)

Reply Score: 4

RE[2]: not a hole
by butters on Wed 23rd May 2007 06:27 UTC in reply to "RE: not a hole"
butters 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.

Reply Score: 4

RE: not a hole
by netpython on Wed 23rd May 2007 04:01 UTC in reply to "not a hole"
netpython Member since:
2005-07-06

Im glad though we have shadowed passwords these days.

Reply Score: 4

Non-issue
by Soulbender on Wed 23rd May 2007 03:14 UTC
Soulbender
Member since:
2005-08-18

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

Reply Score: 4

RE: Non-issue
by Eugenia on Wed 23rd May 2007 03:18 UTC in reply to "Non-issue"
Eugenia Member since:
2005-06-28

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

Reply Score: 1

RE[2]: Non-issue
by rajj on Wed 23rd May 2007 03:23 UTC in reply to "RE: Non-issue"
rajj Member since:
2005-07-06

No. Bad security is worse than no security.

Reply Score: 5

RE[3]: Non-issue
by Eugenia on Wed 23rd May 2007 03:25 UTC in reply to "RE[2]: Non-issue"
Eugenia Member since:
2005-06-28

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.

Reply Score: 1

RE[4]: Non-issue
by notabel on Wed 23rd May 2007 03:33 UTC in reply to "RE[3]: Non-issue"
notabel Member since:
2007-05-23

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

Reply Score: 3

RE[4]: Non-issue
by rajj on Wed 23rd May 2007 03:36 UTC in reply to "RE[3]: Non-issue"
rajj Member since:
2005-07-06

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.

Reply Score: 5

RE[4]: Non-issue
by l3v1 on Wed 23rd May 2007 06:22 UTC in reply to "RE[3]: Non-issue"
l3v1 Member since:
2005-07-06

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.

Reply Score: 5

RE[4]: Non-issue
by clydemaxwell on Wed 23rd May 2007 12:37 UTC in reply to "RE[3]: Non-issue"
clydemaxwell Member since:
2007-04-02

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.

Reply Score: 2

RE[5]: Non-issue
by james_parker on Wed 23rd May 2007 22:15 UTC in reply to "RE[4]: Non-issue"
james_parker Member since:
2005-06-29

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.

[edited to include "not particularly" above].

Edited 2007-05-23 22:16

Reply Score: 3

RE[3]: Non-issue
by l3v1 on Wed 23rd May 2007 06:18 UTC in reply to "RE[2]: Non-issue"
l3v1 Member since:
2005-07-06

Bad security is worse than no security.


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.

Reply Score: 5

RE[2]: Non-issue
by Soulbender on Wed 23rd May 2007 03:27 UTC in reply to "RE: Non-issue"
Soulbender Member since:
2005-08-18

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

Reply Score: 5

RE[3]: Non-issue
by Eugenia on Wed 23rd May 2007 03:31 UTC in reply to "RE[2]: Non-issue"
Eugenia Member since:
2005-06-28

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.

Reply Score: 1

RE[4]: Non-issue
by notabel on Wed 23rd May 2007 03:37 UTC in reply to "RE[3]: Non-issue"
notabel Member since:
2007-05-23

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

Reply Score: 2

RE[4]: Non-issue
by Soulbender on Wed 23rd May 2007 04:20 UTC in reply to "RE[3]: Non-issue"
Soulbender Member since:
2005-08-18

"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

Reply Score: 5

RE[5]: Non-issue
by Eugenia on Wed 23rd May 2007 04:22 UTC in reply to "RE[4]: Non-issue"
Eugenia Member since:
2005-06-28

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

Reply Score: 1

RE[6]: Non-issue
by Soulbender on Wed 23rd May 2007 04:30 UTC in reply to "RE[5]: Non-issue"
Soulbender Member since:
2005-08-18

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

Reply Score: 5

RE[7]: Non-issue
by shapeshifter on Wed 23rd May 2007 10:34 UTC in reply to "RE[6]: Non-issue"
shapeshifter Member since:
2006-09-19

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.

Reply Score: 1

RE[2]: Non-issue
by notabel on Wed 23rd May 2007 03:28 UTC in reply to "RE: Non-issue"
notabel Member since:
2007-05-23

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.

Reply Score: 2

RE[3]: Non-issue
by Eugenia on Wed 23rd May 2007 03:33 UTC in reply to "RE[2]: Non-issue"
Eugenia Member since:
2005-06-28

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.

Reply Score: 1

RE[4]: Non-issue
by notabel on Wed 23rd May 2007 03:41 UTC in reply to "RE[3]: Non-issue"
notabel Member since:
2007-05-23

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

Reply Score: 2

RE[2]: Non-issue
by mikelward on Wed 23rd May 2007 04:14 UTC in reply to "RE: Non-issue"
mikelward Member since:
2007-03-22

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

Reply Score: 4

RE[3]: Non-issue
by rain on Wed 23rd May 2007 08:29 UTC in reply to "RE[2]: Non-issue"
rain Member since:
2005-07-09

afaik, the "show passwords" button only shows the domain name and username so you can manage the passwords.

Reply Score: 1

RE[4]: Non-issue
by StephenBeDoper on Wed 23rd May 2007 16:54 UTC in reply to "RE[3]: Non-issue"
StephenBeDoper Member since:
2005-07-06

Tools > Options > Security > Show Passwords > Show Passwords > "Are you sure" dialog > yes

Reply Score: 4

RE: Non-issue
by shapeshifter on Wed 23rd May 2007 10:10 UTC in reply to "Non-issue"
shapeshifter Member since:
2006-09-19

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.

Reply Score: 4

RE[2]: Non-issue
by Eugenia on Wed 23rd May 2007 10:18 UTC in reply to "RE: Non-issue"
Eugenia Member since:
2005-06-28

Exactly! Well said!

Reply Score: 1

RE[2]: Non-issue
by Soulbender on Wed 23rd May 2007 11:54 UTC in reply to "RE: Non-issue"
Soulbender Member since:
2005-08-18

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

Reply Score: 3

One other way
by adkilla on Wed 23rd May 2007 05:00 UTC
adkilla
Member since:
2005-07-07

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

Reply Score: 1

Here's another scenario.
by frank on Wed 23rd May 2007 05:16 UTC
frank
Member since:
2005-07-08

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

Reply Score: 1

RE: Here's another scenario.
by adkilla on Wed 23rd May 2007 05:50 UTC in reply to "Here's another scenario."
adkilla Member since:
2005-07-07

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

Reply Score: 1

RE: Here's another scenario.
by monodeldiablo on Wed 23rd May 2007 16:32 UTC in reply to "Here's another scenario."
monodeldiablo Member since:
2005-07-06

Then here's a crazy idea: don't ask Gaim (or any other program) to remember your passwords.

Reply Score: 3

A simple approach
by Nycran on Wed 23rd May 2007 06:04 UTC
Nycran
Member since:
2006-02-06

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?

Reply Score: 5

RE: A simple approach
by Soulbender on Wed 23rd May 2007 06:11 UTC in reply to "A simple approach"
Soulbender Member since:
2005-08-18

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

Reply Score: 3

RE: A simple approach
by WereCatf on Wed 23rd May 2007 14:01 UTC in reply to "A simple approach"
WereCatf Member since:
2006-02-15

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

Reply Score: 2

RE: A simple approach
by silicon on Fri 25th May 2007 16:53 UTC in reply to "A simple approach"
silicon Member since:
2005-07-30

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.

Reply Score: 1

Login Password
by CrazyDude0 on Wed 23rd May 2007 06:48 UTC
CrazyDude0
Member since:
2005-07-10

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.

Reply Score: 2

RE: Login Password
by w-ber on Wed 23rd May 2007 06:57 UTC in reply to "Login Password"
w-ber Member since:
2005-08-21

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.

Reply Score: 2

RE: Login Password
by Tyr. on Wed 23rd May 2007 10:32 UTC in reply to "Login Password"
Tyr. Member since:
2005-07-06

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.

Reply Score: 5

RE[2]: Login Password
by shapeshifter on Wed 23rd May 2007 10:45 UTC in reply to "RE: Login Password"
shapeshifter Member since:
2006-09-19

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.:)

Reply Score: 1

RE[3]: Login Password
by Soulbender on Wed 23rd May 2007 11:59 UTC in reply to "RE[2]: Login Password"
Soulbender Member since:
2005-08-18

<removed>

Edited 2007-05-23 12:00

Reply Score: 2

RE[3]: Login Password
by l3v1 on Wed 23rd May 2007 12:54 UTC in reply to "RE[2]: Login Password"
l3v1 Member since:
2005-07-06

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.

I'm tired of this. Could we just move along, please ? ...

Reply Score: 4

RE[4]: Login Password
by Tyr. on Wed 23rd May 2007 19:57 UTC in reply to "RE[3]: Login Password"
Tyr. Member since:
2005-07-06

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


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

Reply Score: 4

RE[2]: Login Password
by dax592 on Wed 23rd May 2007 19:08 UTC in reply to "RE: Login Password"
dax592 Member since:
2005-11-12

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.

Reply Score: 5

Good thing yet
by Manuel FLURY on Wed 23rd May 2007 08:06 UTC
Manuel FLURY
Member since:
2005-07-05

This save me my IM account lot of times !

Even if it's insecure, having complicated password makes it harder to remind them.

Reply Score: 1

It's good!
by Mukunda on Wed 23rd May 2007 08:45 UTC
Mukunda
Member since:
2006-11-05

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.

Reply Score: 1

v Eugenia
by marafaka on Wed 23rd May 2007 09:12 UTC
No point
by acid_head on Wed 23rd May 2007 10:08 UTC
acid_head
Member since:
2007-05-23

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.

Reply Score: 4

Better than no security
by acid_head on Wed 23rd May 2007 10:19 UTC
acid_head
Member since:
2007-05-23

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

Reply Score: 3

timothyha
Member since:
2005-11-10

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

Reply Score: 3

crappy author
by handy on Wed 23rd May 2007 10:21 UTC
handy
Member since:
2005-07-06

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!

Reply Score: 3

RE: crappy author
by kiddo on Wed 23rd May 2007 14:08 UTC in reply to "crappy author"
kiddo Member since:
2005-07-23

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.

Reply Score: 1

acid_head
Member since:
2007-05-23

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.

Reply Score: 1

you know you are a geek when
by Yagami on Wed 23rd May 2007 10:31 UTC
Yagami
Member since:
2006-07-15

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!

Reply Score: 4

RE: you know you are a geek when
by Soulbender on Wed 23rd May 2007 12:24 UTC in reply to "you know you are a geek when"
Soulbender Member since:
2005-08-18

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

Reply Score: 3

RE[2]: you know you are a geek when
by Yagami on Wed 23rd May 2007 12:39 UTC in reply to "RE: you know you are a geek when"
Yagami Member since:
2006-07-15

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 ?!

Reply Score: 3

Soulbender Member since:
2005-08-18

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

Reply Score: 3

Spellcheck Member since:
2007-01-20

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

Reply Score: 2

Nope, doesn't make sense
by acid_head on Wed 23rd May 2007 11:04 UTC
acid_head
Member since:
2007-05-23

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

Reply Score: 2

v Re: Eugenia
by marafaka on Wed 23rd May 2007 11:05 UTC
Soulbender is right
by acid_head on Wed 23rd May 2007 12:02 UTC
acid_head
Member since:
2007-05-23

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.

Reply Score: 2

Lets look at the cases
by Yamin on Wed 23rd May 2007 14:43 UTC
Yamin
Member since:
2006-01-10

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.

Reply Score: 2

RE: Lets look at the cases
by WereCatf on Wed 23rd May 2007 14:49 UTC in reply to "Lets look at the cases"
WereCatf Member since:
2006-02-15

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.

Reply Score: 2

Security or security through obscurity?
by WereCatf on Wed 23rd May 2007 14:44 UTC
WereCatf
Member since:
2006-02-15

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?

Reply Score: 2

v Nothing to see here
by sappyvcv on Wed 23rd May 2007 16:02 UTC
RE: Nothing to see here
by StephenBeDoper on Wed 23rd May 2007 17:12 UTC in reply to "Nothing to see here"
StephenBeDoper Member since:
2005-07-06

Classy.

Reply Score: 1

Not a security hole...
by Marty on Wed 23rd May 2007 17:06 UTC
Marty
Member since:
2006-01-10

... until you combine it with another exploit (in a web browser, for example) that allows reading of local files.

Reply Score: 2

Lately....
by ccchips on Wed 23rd May 2007 17:25 UTC
ccchips
Member since:
2006-05-24

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

Reply Score: 1

Defeatism
by izomiac on Wed 23rd May 2007 20:59 UTC
izomiac
Member since:
2006-07-26

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

Reply Score: 4

RE: Defeatism
by rajj on Wed 23rd May 2007 21:42 UTC in reply to "Defeatism"
rajj Member since:
2005-07-06

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.

Reply Score: 3

RE[2]: Defeatism
by izomiac on Thu 24th May 2007 06:20 UTC in reply to "RE: Defeatism"
izomiac Member since:
2006-07-26

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.

Reply Score: 2

aliquis
Member since:
2005-07-23

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.

Reply Score: 1

wow
by JrezIN on Wed 23rd May 2007 22:51 UTC
JrezIN
Member since:
2005-06-29

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

Reply Score: 3

different types of security.
by frank on Wed 23rd May 2007 23:47 UTC
frank
Member since:
2005-07-08

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.

Reply Score: 3