From: Mark D. <ma...@ki...> - 2004-04-29 02:39:35
|
Since everyone else is discussing Gaim development on gaim-devel, I thought I'd raise the "obfuscated password" issue. Hopefully this won't turn into some all-out mud slinging contest where people state the same reasons a hojillion times. Everyone who matters should, by now, know the arguments for why most Gaim devels are against any sort of password hashing in the accounts.xml file. If not, you can read ALL about it here: http://gaim.sourceforge.net/plaintextpasswords.txt The argument I used to give against password obscuring was to just point people to Eric S. Raymond's argument about .fetchmailrc. See everything after #16 at http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s09.html However, I don't feel that this applies to Gaim perfectly. With fetchmail, the .fetchmailrc file is created by the user. By hand. The user therefore knows that their password is sitting in a plain text file. With Gaim the password is entered as a bunch of asterisks in a dialog box. The user doesn't know and doesn't care how it's stored. Sean has occasionally pointed out that Gaim now runs on operating systems without a concept of multiple users (or, personal and secure files, anyway). Namely Windows 98. To this I'm sure Ethan is enraged, but it doesn't make it any less true. So what is there to gain by some sort of minimalistic password masking? It means people without brains (ie. the majority of people snooping around looking for someone's AIM password) will not be able to find anything of value. Basically, it wouldn't hurt Gaim (much), and it would help a tiny bit. So... I see 4 options: 1. Don't change a damn thing. Plain text passwords are perfectly fine, you twit. 2. Let's just show a warning message the first time someone saves a password to their accounts.xml file. 3. Let's show a warning message every time someone saves a password to their accounts.xml file. 4. Let's weakly modify the password in a way that stops casually onlookers from seeing anything meaningful (base64, rot8, etc). I vote for #2. -Mark -- O O Mark Doliner \ | ma...@ki... \ | www.kingant.net "There needs to be a better word for weird." |
From: Kevin M S. <ke...@si...> - 2004-04-29 02:53:39
|
I kind of tend to think we ought not to care much about Windows 98 clients, as Win 98 is about at end of life, and is probably not going to be supported for much longer by much of anything. In other words, I like option #1.... However, I am okay with option #2. Option #3 is obnoxious. Dialogs that won't go stop appearing are very mean things to do to users. (That was my complaint with the TOC thing, if you recall). Option #4 is argued well enough against in plaintextpasswords.txt, and I really don't see any need for it. If you're really that worried about someone getting your AIM password, a combination of a BIOS password and screen saver password is probably enough to keep the casual viewer from grabbing a peek anyway, even on Windows 98/Me.... Kevin Mark Doliner wrote: > Since everyone else is discussing Gaim development on gaim-devel, I thought > I'd raise the "obfuscated password" issue. Hopefully this won't turn into > some all-out mud slinging contest where people state the same reasons a > hojillion times. > > Everyone who matters should, by now, know the arguments for why most Gaim > devels are against any sort of password hashing in the accounts.xml file. If > not, you can read ALL about it here: > http://gaim.sourceforge.net/plaintextpasswords.txt > > The argument I used to give against password obscuring was to just point > people to Eric S. Raymond's argument about .fetchmailrc. See everything after > #16 at > http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s09.html > > However, I don't feel that this applies to Gaim perfectly. With fetchmail, > the .fetchmailrc file is created by the user. By hand. The user therefore > knows that their password is sitting in a plain text file. With Gaim the > password is entered as a bunch of asterisks in a dialog box. The user doesn't > know and doesn't care how it's stored. > > Sean has occasionally pointed out that Gaim now runs on operating systems > without a concept of multiple users (or, personal and secure files, anyway). > Namely Windows 98. To this I'm sure Ethan is enraged, but it doesn't make it > any less true. > > So what is there to gain by some sort of minimalistic password masking? It > means people without brains (ie. the majority of people snooping around > looking for someone's AIM password) will not be able to find anything of > value. Basically, it wouldn't hurt Gaim (much), and it would help a tiny bit. > > So... I see 4 options: > > 1. Don't change a damn thing. Plain text passwords are perfectly fine, you twit. > > 2. Let's just show a warning message the first time someone saves a password > to their accounts.xml file. > > 3. Let's show a warning message every time someone saves a password to their > accounts.xml file. > > 4. Let's weakly modify the password in a way that stops casually onlookers > from seeing anything meaningful (base64, rot8, etc). > > I vote for #2. > -Mark > > > -- > O O Mark Doliner > \ | ma...@ki... > \ | www.kingant.net > "There needs to be a better word for weird." > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: Oracle 10g > Get certified on the hottest thing ever to hit the market... Oracle 10g. > Take an Oracle 10g class now, and we'll give you the exam FREE. > http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click > _______________________________________________ > Gaim-devel mailing list > Gai...@li... > https://lists.sourceforge.net/lists/listinfo/gaim-devel |
From: Gary K. <gr...@re...> - 2004-04-29 02:55:58
|
Personally I think it wouldn't hurt to encrypt them.. Of course in some sort of 2 way hash. The one that strikes me as the easiest is ICE. It's a 2 way hash this is designed to be at least as strong as DES. A prpl I'm working on actually uses this for transfering messages. It's public domain so there are no licensing conflicts. Anyways heres the link http://www.darkside.com.au/ice/ Gary |
From: Scott L. <sl...@sl...> - 2004-04-29 03:21:53
|
On Apr 28, 2004, at 9:55 PM, Gary Kramlich wrote: > Personally I think it wouldn't hurt to encrypt them.. Of course in some > sort of 2 way hash. The one that strikes me as the easiest is ICE. > It's a 2 way hash this is designed to be at least as strong as DES. Who cares how strong the encryption algorithm is? When the key is stored in the same place as the passwords, you don't need to brute-force it; you just decrypt in the same way gaim does. So this is still #4. I like #2 or #3; more programs should let users know about potential security problems. (Or a hybrid of the two; one of those "Tell me again next time" checkboxes.) Putting #4 on top of that wouldn't hurt (except for the extra effort, of course). But please, no delusions about what it is. Scott |
From: Vince <lo...@in...> - 2004-04-29 05:36:48
|
On Apr 28, 2004, at 9:55 PM, Gary Kramlich wrote: > >Personally I think it wouldn't hurt to encrypt them.. Of course in some > >sort of 2 way hash. The one that strikes me as the easiest is ICE. > >It's a 2 way hash this is designed to be at least as strong as DES. Um, isn't the whole point of a hash that it's one way? :) A simple encryption is fine and I personally lean towards it, it's not security by obscurity but simply so that people can't open up the file and copy+paste the password out of it. No, it won't stop anyone who applies brains to the matter, but it's like having a locked door. A locked door doesn't stop people who really want to get into your house, but it does stop people casually walking in and grabbing stuff just because they get tempted one time. On Wed, Apr 28, 2004 at 10:21:43PM -0500, Scott Lamb wrote: > Who cares how strong the encryption algorithm is? When the key is > stored in the same place as the passwords, you don't need to > brute-force it; you just decrypt in the same way gaim does. So this is > still #4. If it's hashing we're talking about, there is no key? You don't recover the plaintext, the user enters a new plaintext and you hash it to see if the end result is the same as the stored hash result. What is being discussed is some sort of encryption, which doesn't have to be powerful. I think base64 may well be sufficient, or to be super l33t and efficient, base64 then rot13 ;) I'm in favour of #4 - I've read the plaintextpasswords.txt file and while I understand the viewpoint, I think the reasoning is flawed. Naive users are going to be duped either way, we're not going to successfully educate them. Encrypting makes it that tiny bit safer if they do end up being duped into sharing their accounts.xml. Gaim makes no promises about being a secure app; neither does any other IM program. Adding some trivial encryption won't change that, but it will make it that tiny bit safer, like having a lock on the front door. It is there partly so people know they're not supposed to just walk in anytime and copy/paste the password. -- Vincent Ho loki /at/ internode.on.net Every complex problem is a simple hierarchy of simple problems. |
From: Luke S. <lsc...@us...> - 2004-04-29 05:45:36
|
On Thu, Apr 29, 2004 at 03:37:07PM +1000, Vince wrote: > On Apr 28, 2004, at 9:55 PM, Gary Kramlich wrote: > > > >Personally I think it wouldn't hurt to encrypt them.. Of course in some > > >sort of 2 way hash. The one that strikes me as the easiest is ICE. > > >It's a 2 way hash this is designed to be at least as strong as DES. > > Um, isn't the whole point of a hash that it's one way? :) A simple > encryption is fine and I personally lean towards it, it's not security > by obscurity but simply so that people can't open up the file and > copy+paste the password out of it. if you put any true encryption in, you have to either ask for the passphrase or store it. see the plaintextpasswords.txt for details. > > No, it won't stop anyone who applies brains to the matter, but it's like > having a locked door. A locked door doesn't stop people who really want > to get into your house, but it does stop people casually walking in and > grabbing stuff just because they get tempted one time. > how locked is a door with the key taped to it with scotch tape? > > On Wed, Apr 28, 2004 at 10:21:43PM -0500, Scott Lamb wrote: > > > Who cares how strong the encryption algorithm is? When the key is > > stored in the same place as the passwords, you don't need to > > brute-force it; you just decrypt in the same way gaim does. So this is > > still #4. > > If it's hashing we're talking about, there is no key? You don't recover > the plaintext, the user enters a new plaintext and you hash it to see if > the end result is the same as the stored hash result. > if the key is hard coded into gaim, its security by obscurity, and is bad. see plaintextpasswords.txt for details. if you ask for the key, see above (ie see plaintextpasswords.txt for details) > What is being discussed is some sort of encryption, which doesn't have > to be powerful. I think base64 may well be sufficient, or to be super > l33t and efficient, base64 then rot13 ;) > > I'm in favour of #4 - I've read the plaintextpasswords.txt file and > while I understand the viewpoint, I think the reasoning is flawed. > Naive users are going to be duped either way, we're not going to > successfully educate them. Encrypting makes it that tiny bit safer if > they do end up being duped into sharing their accounts.xml. > you apparently did not understand, it doesn't make them any safer unless we force them to type in a passphrase. in which case we might as well just not offer to store their passwords at all. > Gaim makes no promises about being a secure app; neither does any other > IM program. Adding some trivial encryption won't change that, but it > will make it that tiny bit safer, like having a lock on the front door. > It is there partly so people know they're not supposed to just walk in > anytime and copy/paste the password. a lock with the key taped to it with scotch tape. as you might be able to tell from my reaction to the above stupidity, the MOST i'm in favor of is stating somewhere in the ui that any saved passwords are unencrypted. luke |
From: Vince <lo...@in...> - 2004-04-29 06:50:09
|
On Thu, Apr 29, 2004 at 01:45:11AM -0400, Luke Schierer wrote: > if you put any true encryption in, you have to either ask for the > passphrase or store it. see the plaintextpasswords.txt for details. I canvassed using something as trivial as base64. There is no key. It's simply an encoding. Calling it encryption is actually glorifying it really, but it's a valid substitution cipher, just as rot13 is. There is no key. There will be no key in the Gaim source. There will be no prompting the user for a passphrase, because there is no key. > how locked is a door with the key taped to it with scotch tape? I don't feel you read what I said at all. It is not to stop people recovering your password if they genuinely wish to put in the effort. As I said, the locked door is NOT to stop people opening it. It's to make people spend more effort and think longer if they actually want to open it. Similarly, the "encryption" here is not to prevent people from ever being able to recover the keys (since that is, as we all know, not possible) but to increase the difficulty from simply "open the file and copy/paste". Similarly, nothing short of a one-time pad encryption can guarantee that a would-be cryptanalyst has no better option than brute force. But that doesn't stop people using other forms of encryption. > as you might be able to tell from my reaction to the above stupidity, Well that's charming, but your reply doesn't actually address the points I said in my post. > the MOST i'm in favor of is stating somewhere in the ui that any saved > passwords are unencrypted. Fair enough, it's good to hear the option you favour. Vince -- Vincent Ho loki /at/ internode.on.net Every complex problem is a simple hierarchy of simple problems. |
From: Jesse F. <far...@uc...> - 2004-04-29 03:01:17
|
On Wed, 2004-04-28 at 21:39, Mark Doliner wrote: <snippity snip> > > So... I see 4 options: > > 1. Don't change a damn thing. Plain text passwords are perfectly fine, you twit. > > 2. Let's just show a warning message the first time someone saves a password > to their accounts.xml file. > > 3. Let's show a warning message every time someone saves a password to their > accounts.xml file. > > 4. Let's weakly modify the password in a way that stops casually onlookers > from seeing anything meaningful (base64, rot8, etc). > > I vote for #2. > -Mark I agree. #1 is fine, except that people now use Gaim in single-user environments where their data is more insecure. People who use single-user operating systems as if they were multiple-user operating systems should know that their data is vulnerable, but a warning message stating as much will do no harm and a modicum of real good. #3 would just be annoying. Imagine people who add / remove accounts for testing purposes, or for whatever reason. #4 does no real good, and invests people with a false sense of security (as said a million times by a million different people). I believe 1,2,3 are better options than this. Even if one argues, with respect to #2, that Gaim is not responsible for people misusing their OS, that Gaim is no more responsible for people using Windows 98 as a multiple-users OS than it is for people deciding to make their home directory world readable, I see no harm done with this option. Nobody would be annoyed by it, and at best it might prevent someone from saving their passwords when they shouldn't. -- Jesse Farmer <far...@uc...> University of Chicago |
From: Ka-Hing C. <ja...@ja...> - 2004-04-29 03:09:22
|
On Wed, Apr 28, 2004 at 09:39:20PM -0500, Mark Doliner wrote: > 1. Don't change a damn thing. Plain text passwords are perfectly fine, you twit. > > 2. Let's just show a warning message the first time someone saves a password > to their accounts.xml file. > > 3. Let's show a warning message every time someone saves a password to their > accounts.xml file. > > 4. Let's weakly modify the password in a way that stops casually onlookers > from seeing anything meaningful (base64, rot8, etc). > > I vote for #2. 5. weakly modify the password and tell the user that it's still possible for others to discover the password? I don't know how much I would like that, but it satisfies people who want to have their password "encrypted", and still don't spread a sense of false security too much. Re SymGuy, maybe gaim can show the dialog only when the user click on the save password checkbox, so #3 won't be that obnoxious. -khc |
From: Christian H. <ch...@gn...> - 2004-04-29 03:47:50
|
On Wed, Apr 28, 2004 at 09:39:20PM -0500, Mark Doliner wrote: > 1. Don't change a damn thing. Plain text passwords are perfectly fine, y= ou twit. >=20 > 2. Let's just show a warning message the first time someone saves a passw= ord > to their accounts.xml file. >=20 > 3. Let's show a warning message every time someone saves a password to th= eir > accounts.xml file. >=20 > 4. Let's weakly modify the password in a way that stops casually onlookers > from seeing anything meaningful (base64, rot8, etc). How about #2, but let's just place some small descriptive text in grey in an appropriate place in that dialog indicating that the password is stored in plaintext? (But in a way that the typical user can understand). Christian =20 --=20 Christian Hammond <> The GNUpdate Project ch...@gn... <> http://www.gnupdate.org/ The one who says it cannot be done should never interrupt the one who is doing it. |
From: Stuart C. <stuart.clark@Jahingo.com> - 2004-04-29 12:01:36
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mark Doliner wrote: > > So... I see 4 options: > > 1. Don't change a damn thing. Plain text passwords are perfectly fine, you twit. > > 2. Let's just show a warning message the first time someone saves a password > to their accounts.xml file. > > 3. Let's show a warning message every time someone saves a password to their > accounts.xml file. > > 4. Let's weakly modify the password in a way that stops casually onlookers > from seeing anything meaningful (base64, rot8, etc). > Or how about having the ability of "true" encryption, but making using it optional (not using it = plaintext passwords, using it = encrypted passwords with a master password to type to use anything). That would be similar to Mozilla at password storing (optional master password). I wouldn't use it personally, as I like the ability to see my passwords for my account when I forget what they are (for logging into Yahoo!'s website or when I'm using a different IM client on a different PC) - -- Stuart Clark mailto:stuart.clark@Jahingo.com http://www.Jahingo.com/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFAkO6R8fzjqiF3TCIRAl6zAJ9ck4uR0QGPKoPFtssece86O0DbMwCfZ6TD 8Lg7gZvD+ewFyL983m6+8Vo= =wTTB -----END PGP SIGNATURE----- |
From: Luke S. <lsc...@us...> - 2004-04-29 16:43:11
|
On Thu, Apr 29, 2004 at 01:01:21PM +0100, Stuart Clark wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Mark Doliner wrote: > > > > So... I see 4 options: > > > > 1. Don't change a damn thing. Plain text passwords are perfectly > fine, you twit. > > > > 2. Let's just show a warning message the first time someone saves a > password > > to their accounts.xml file. > > > > 3. Let's show a warning message every time someone saves a password to > their > > accounts.xml file. > > > > 4. Let's weakly modify the password in a way that stops casually onlookers > > from seeing anything meaningful (base64, rot8, etc). > > > > Or how about having the ability of "true" encryption, but making using > it optional (not using it = plaintext passwords, using it = encrypted > passwords with a master password to type to use anything). > > That would be similar to Mozilla at password storing (optional master > password). > > I wouldn't use it personally, as I like the ability to see my passwords > for my account when I forget what they are (for logging into Yahoo!'s > website or when I'm using a different IM client on a different PC) from gaim.sf.net/plaintextpasswords.txt "2) There are basically 4 approaches to password storage. A) Store a password(s) behind a password. Basically this means that we require you to type in some passphrase as Gaim starts in order to read the accounts.xml file, and, to be truely secure, require you to type it again if you write to it. Winicq does something very similar to this if you set it to its highest security settings. B) Obscure a password. This means we do something to store the password in some format other than plain text, but we automatically convert it for you. This is security by obscurity, and is a VERY Bad Thing(tm) in that it gives users a false sense of security; a false sense that we (as Gaim developers) believe would be worse to have than to let informed users deal with the password issue themselves. (Consider that a naive user might think that it is safe to share his or her accounts.xml, because the passwords are "encrypted".) C) Store the password in plain text and control access to the file. This is what Gaim does: the password is in accounts.xml in plain text, but the file itself is only readable by its owner. We allow the user to determine under what conditions sensitive files should be opened (if at all), and what constitutes a breach of security (for instance opening the file before you realize what's up with it), and to react accordingly. ICQ is the only protocol that will allow the account to be completely taken over by surprise, and that only because of flaws in the server that allow accounts to be highjacked _at the server_ w/out the use of a client at all. D) Lastly, you can not store passwords at all. This is Gaim's default, and by far the most secure of all of the options." Stuart here is advocating 2A, Vince 2B. the problem with 2b is that its deceptive, the problem with 2a is that you still end up typing in a password, so what is the overall benifit over 2d? also, when randomgaimuser enables 2a, then forgets his passphrase he looses all his settings, whereas when randomgaimuser forgets an aim or yahoo password he can get it back. and on top of that is the complexity or handling enabling and, more, disabling that option on top of that. its asking for trouble, trouble that could all be avoided by users simply using 2d if they don't feel the .gaim directory is sufficiently protected. luke > > - -- > Stuart Clark > mailto:stuart.clark@Jahingo.com > http://www.Jahingo.com/ > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.1 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org > > iD8DBQFAkO6R8fzjqiF3TCIRAl6zAJ9ck4uR0QGPKoPFtssece86O0DbMwCfZ6TD > 8Lg7gZvD+ewFyL983m6+8Vo= > =wTTB > -----END PGP SIGNATURE----- > > > ------------------------------------------------------- > This SF.Net email is sponsored by: Oracle 10g > Get certified on the hottest thing ever to hit the market... Oracle 10g. > Take an Oracle 10g class now, and we'll give you the exam FREE. > http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click > _______________________________________________ > Gaim-devel mailing list > Gai...@li... > https://lists.sourceforge.net/lists/listinfo/gaim-devel |
From: Stuart C. <stuart.clark@Jahingo.com> - 2004-04-29 17:02:02
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Luke Schierer wrote: > >> Stuart here is advocating 2A, Vince 2B. the problem with 2b is that its >> deceptive, the problem with 2a is that you still end up typing in a >> password, so what is the overall benifit over 2d? also, when >> randomgaimuser enables 2a, then forgets his passphrase he looses all his >> settings, whereas when randomgaimuser forgets an aim or yahoo password >> he can get it back. and on top of that is the complexity or handling >> enabling and, more, disabling that option on top of that. its asking for >> trouble, trouble that could all be avoided by users simply using 2d if >> they don't feel the .gaim directory is sufficiently protected. > I'm not really advocating anything, but just suggesting that if some type of password 'obfuscation' it may be better to do it 'properly' rather than just ROT13 or something. I realise the support issue it could create, but remember losing the password doesn't stop you from starting from scratch with the individual im passwords (which can be found using their own methods). I suppose it would be a balance between the problem of losing the main password (having to reented the lot) agains the false sense of security some may have with simple encoding (which probably causes less actual support, but more potential problems). Having said all that, I'm happy how things are, and where things to change, I would want a way to keep the current plaintext passwords. :-) - -- Stuart Clark mailto:stuart.clark@Jahingo.com http://www.Jahingo.com/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFAkTUD8fzjqiF3TCIRAjucAJwPKpfhAW1wiHulD8m0E+FFzQg41QCfYwWc VN997NMKr8AVOEBigxSE5CI= =ICzn -----END PGP SIGNATURE----- |
From: Luke S. <lsc...@us...> - 2004-04-29 17:13:50
|
On Thu, Apr 29, 2004 at 06:01:55PM +0100, Stuart Clark wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Luke Schierer wrote: > > > >> Stuart here is advocating 2A, Vince 2B. the problem with 2b is that its > >> deceptive, the problem with 2a is that you still end up typing in a > >> password, so what is the overall benifit over 2d? also, when > >> randomgaimuser enables 2a, then forgets his passphrase he looses all his > >> settings, whereas when randomgaimuser forgets an aim or yahoo password > >> he can get it back. and on top of that is the complexity or handling > >> enabling and, more, disabling that option on top of that. its asking for > >> trouble, trouble that could all be avoided by users simply using 2d if > >> they don't feel the .gaim directory is sufficiently protected. > > > > I'm not really advocating anything, but just suggesting that if some > type of password 'obfuscation' it may be better to do it 'properly' > rather than just ROT13 or something. > > I realise the support issue it could create, but remember losing the > password doesn't stop you from starting from scratch with the individual > im passwords (which can be found using their own methods). > > I suppose it would be a balance between the problem of losing the main > password (having to reented the lot) agains the false sense of security > some may have with simple encoding (which probably causes less actual > support, but more potential problems). > > Having said all that, I'm happy how things are, and where things to > change, I would want a way to keep the current plaintext passwords. to be safe you'd have to re-enter it every time the .gaim/accounts.xml is read or written. this would lead thus break the ability to have yourself automatically reconnected, it would make the ability to change accounts more painful, it would add a step to starting up, and it would be a support nightmare when i have to tell users that they have to delete all their accounts and start over. please tell me who in their right mind really wants this, but isn't willing to not store their passwords at all. i HATE the idea of obscuring the password. i HATE the idea of providing a false sense of security. i think this falsehood is WORSE than having plain text passwords in the file. for one thing it is a FALSE sense of security, and for a second it is contributing to computer user ignorance and stupidity. luke |
From: Nathan C. <co...@bu...> - 2004-04-29 17:31:10
|
I think that the best choice would be to integrate gaim with something like gnome-keyring and let it handle the password storage. But, because few computers have gnome-keyring installed, it would have to be made a runtime option for gaim (maybe a plugin?) and have gaim fallback to the current method of password storage if the gnome-keyring support is not enabled. -Nathan On Thu, Apr 29, 2004 at 01:13:29PM -0400, Luke Schierer wrote: > On Thu, Apr 29, 2004 at 06:01:55PM +0100, Stuart Clark wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > >=20 > > Luke Schierer wrote: > > > > > >> Stuart here is advocating 2A, Vince 2B. the problem with 2b is that= its > > >> deceptive, the problem with 2a is that you still end up typing in a > > >> password, so what is the overall benifit over 2d? also, when > > >> randomgaimuser enables 2a, then forgets his passphrase he looses all= his > > >> settings, whereas when randomgaimuser forgets an aim or yahoo passwo= rd > > >> he can get it back. and on top of that is the complexity or handling > > >> enabling and, more, disabling that option on top of that. its asking= for > > >> trouble, trouble that could all be avoided by users simply using 2d = if > > >> they don't feel the .gaim directory is sufficiently protected. > > > > >=20 > > I'm not really advocating anything, but just suggesting that if some > > type of password 'obfuscation' it may be better to do it 'properly' > > rather than just ROT13 or something. > >=20 > > I realise the support issue it could create, but remember losing the > > password doesn't stop you from starting from scratch with the individual > > im passwords (which can be found using their own methods). > >=20 > > I suppose it would be a balance between the problem of losing the main > > password (having to reented the lot) agains the false sense of security > > some may have with simple encoding (which probably causes less actual > > support, but more potential problems). > >=20 > > Having said all that, I'm happy how things are, and where things to > > change, I would want a way to keep the current plaintext passwords. >=20 > to be safe you'd have to re-enter it every time the .gaim/accounts.xml > is read or written. this would lead thus break the ability to have > yourself automatically reconnected, it would make the ability to change > accounts more painful, it would add a step to starting up, and it would > be a support nightmare when i have to tell users that they have to > delete all their accounts and start over. please tell me who in their > right mind really wants this, but isn't willing to not store their > passwords at all. >=20 >=20 > i HATE the idea of obscuring the password. i HATE the idea of providing > a false sense of security. i think this falsehood is WORSE than having > plain text passwords in the file. for one thing it is a FALSE sense of > security, and for a second it is contributing to computer user > ignorance and stupidity. >=20 > luke |
From: Luke S. <lsc...@us...> - 2004-04-29 17:53:35
|
except that gnome-keyring would not be good for our kde users, our macosx users, the people who have no particular environment, the win32 users, so on and so forth. the best choice woudl be not to encrypt the passwords and let you all use your brains to store them. luke On Thu, Apr 29, 2004 at 01:31:02PM -0400, Nathan Conrad wrote: > I think that the best choice would be to integrate gaim with > something like gnome-keyring and let it handle the password > storage. But, because few computers have gnome-keyring installed, it > would have to be made a runtime option for gaim (maybe a plugin?) and > have gaim fallback to the current method of password storage if the > gnome-keyring support is not enabled. > > -Nathan > > On Thu, Apr 29, 2004 at 01:13:29PM -0400, Luke Schierer wrote: > > On Thu, Apr 29, 2004 at 06:01:55PM +0100, Stuart Clark wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > > Hash: SHA1 > > > > > > Luke Schierer wrote: > > > > > > > >> Stuart here is advocating 2A, Vince 2B. the problem with 2b is that its > > > >> deceptive, the problem with 2a is that you still end up typing in a > > > >> password, so what is the overall benifit over 2d? also, when > > > >> randomgaimuser enables 2a, then forgets his passphrase he looses all his > > > >> settings, whereas when randomgaimuser forgets an aim or yahoo password > > > >> he can get it back. and on top of that is the complexity or handling > > > >> enabling and, more, disabling that option on top of that. its asking for > > > >> trouble, trouble that could all be avoided by users simply using 2d if > > > >> they don't feel the .gaim directory is sufficiently protected. > > > > > > > > > > I'm not really advocating anything, but just suggesting that if some > > > type of password 'obfuscation' it may be better to do it 'properly' > > > rather than just ROT13 or something. > > > > > > I realise the support issue it could create, but remember losing the > > > password doesn't stop you from starting from scratch with the individual > > > im passwords (which can be found using their own methods). > > > > > > I suppose it would be a balance between the problem of losing the main > > > password (having to reented the lot) agains the false sense of security > > > some may have with simple encoding (which probably causes less actual > > > support, but more potential problems). > > > > > > Having said all that, I'm happy how things are, and where things to > > > change, I would want a way to keep the current plaintext passwords. > > > > to be safe you'd have to re-enter it every time the .gaim/accounts.xml > > is read or written. this would lead thus break the ability to have > > yourself automatically reconnected, it would make the ability to change > > accounts more painful, it would add a step to starting up, and it would > > be a support nightmare when i have to tell users that they have to > > delete all their accounts and start over. please tell me who in their > > right mind really wants this, but isn't willing to not store their > > passwords at all. > > > > > > i HATE the idea of obscuring the password. i HATE the idea of providing > > a false sense of security. i think this falsehood is WORSE than having > > plain text passwords in the file. for one thing it is a FALSE sense of > > security, and for a second it is contributing to computer user > > ignorance and stupidity. > > > > luke |
From: Nathan C. <co...@bu...> - 2004-04-29 18:14:30
|
This is the reason that I suggested it to be _optional_. The GNOME 2.6 users have their nice password encryption while the GNOME 2.4 and KDE users have the same option that the do now: don't store the password or put it in a plaintext file. I suggested it to be a plugin so that there can be multiple ways to store the password. If there is some keychain program for KDE, there could be a KDE password encryption plugin too. -Nathan On Thu, Apr 29, 2004 at 01:53:13PM -0400, Luke Schierer wrote: > except that gnome-keyring would not be good for our kde users, our > macosx users, the people who have no particular environment, the win32 > users, so on and so forth. >=20 > the best choice woudl be not to encrypt the passwords and let you all > use your brains to store them. >=20 > luke >=20 > On Thu, Apr 29, 2004 at 01:31:02PM -0400, Nathan Conrad wrote: > > I think that the best choice would be to integrate gaim with > > something like gnome-keyring and let it handle the password > > storage. But, because few computers have gnome-keyring installed, it > > would have to be made a runtime option for gaim (maybe a plugin?) and > > have gaim fallback to the current method of password storage if the > > gnome-keyring support is not enabled. > >=20 > > -Nathan > >=20 > > On Thu, Apr 29, 2004 at 01:13:29PM -0400, Luke Schierer wrote: > > > On Thu, Apr 29, 2004 at 06:01:55PM +0100, Stuart Clark wrote: > > > > -----BEGIN PGP SIGNED MESSAGE----- > > > > Hash: SHA1 > > > >=20 > > > > Luke Schierer wrote: > > > > > > > > > >> Stuart here is advocating 2A, Vince 2B. the problem with 2b is = that its > > > > >> deceptive, the problem with 2a is that you still end up typing i= n a > > > > >> password, so what is the overall benifit over 2d? also, when > > > > >> randomgaimuser enables 2a, then forgets his passphrase he looses= all his > > > > >> settings, whereas when randomgaimuser forgets an aim or yahoo pa= ssword > > > > >> he can get it back. and on top of that is the complexity or han= dling > > > > >> enabling and, more, disabling that option on top of that. its as= king for > > > > >> trouble, trouble that could all be avoided by users simply using= 2d if > > > > >> they don't feel the .gaim directory is sufficiently protected. > > > > > > > > >=20 > > > > I'm not really advocating anything, but just suggesting that if some > > > > type of password 'obfuscation' it may be better to do it 'properly' > > > > rather than just ROT13 or something. > > > >=20 > > > > I realise the support issue it could create, but remember losing the > > > > password doesn't stop you from starting from scratch with the indiv= idual > > > > im passwords (which can be found using their own methods). > > > >=20 > > > > I suppose it would be a balance between the problem of losing the m= ain > > > > password (having to reented the lot) agains the false sense of secu= rity > > > > some may have with simple encoding (which probably causes less actu= al > > > > support, but more potential problems). > > > >=20 > > > > Having said all that, I'm happy how things are, and where things to > > > > change, I would want a way to keep the current plaintext passwords. > > >=20 > > > to be safe you'd have to re-enter it every time the .gaim/accounts.xml > > > is read or written. this would lead thus break the ability to have > > > yourself automatically reconnected, it would make the ability to chan= ge > > > accounts more painful, it would add a step to starting up, and it wou= ld > > > be a support nightmare when i have to tell users that they have to > > > delete all their accounts and start over. please tell me who in their > > > right mind really wants this, but isn't willing to not store their > > > passwords at all. > > >=20 > > >=20 > > > i HATE the idea of obscuring the password. i HATE the idea of providi= ng > > > a false sense of security. i think this falsehood is WORSE than having > > > plain text passwords in the file. for one thing it is a FALSE sense of > > > security, and for a second it is contributing to computer user > > > ignorance and stupidity. > > >=20 > > > luke >=20 >=20 >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by: Oracle 10g > Get certified on the hottest thing ever to hit the market... Oracle 10g.= =20 > Take an Oracle 10g class now, and we'll give you the exam FREE. > http://ads.osdn.com/?ad_id=3D3149&alloc_id=3D8166&op=3Dclick > _______________________________________________ > Gaim-devel mailing list > Gai...@li... > https://lists.sourceforge.net/lists/listinfo/gaim-devel >=20 --=20 Nathan J. Conrad Campus phone #5930 301 Scott hall, UNC Charlotte http://bungled.net GPG: F4FC 7E25 9308 ECE1 735C 0798 CE86 DA45 9170 3112 |
From: Brian J. T. <bj...@co...> - 2004-04-29 17:40:11
|
On Thu, 29 Apr 2004, Luke Schierer wrote: > i HATE the idea of obscuring the password. i HATE the idea of providing > a false sense of security. i think this falsehood is WORSE than having > plain text passwords in the file. for one thing it is a FALSE sense of > security, and for a second it is contributing to computer user > ignorance and stupidity. i think you're missing the point on the user ignorance front. the part that many users are ignorant about is that the more common types of password-obscuring are easily reversible. leaving the password as plaintext doesn't change that. the user that was originally stupid is still stupid. i'd argue that gaim is actually doing the uninformed user a disservice - you're just protecting them from that stupidity, since hopefully the user would notice the password there in plaintext, and think "oh, i shouldn't share that." they remain ignorant of weak password-obscuring methods. the only argument in favor here is that, if a user is annoyed about it being plaintext, and then complains, you (or someone else) can point them to gaim's password-rationale document, and then they'll learn that obscuring a password is just that - obscuring, and it isn't safe or encrypted. that is, assuming they read and understand it. however, i think this takes more initiative than you can ascribe to the average user. personally, i think obscuring the password is good simply because it prevents someone from discovering your password from a casual glance. say you have the file open for some unknown reason, and you have a friend there looking over your shoulder. if you want, when you're writing out the accounts.xml file, stick an XML comment right above where each password is stored, such as: <!-- NOTE: THIS PASSWORD IS ONLY WEAKLY OBSCURED, AND CAN BE EASILY CONVERTED BACK INTO YOUR PLAINTEXT PASSWORD. DO NOT SHARE THIS FILE WITH ANYONE. FOR FURTHER INFO, SEE http://... --> (hopefully whatever XML parser/generator gaim is using supports injecting comments in that manner.) you get pretty much the same effect. a user that is ignorant enough to still share the file with someone else after reading that (or, looking at the file and failing to read that) deserves what he/she gets. perhaps i'm a pessimist, but i consider someone like that too far gone for any amount of user education to do any good. personally, i guess i don't care all that much. i don't believe i've ever opened my accounts.xml file in a text editor, and the file has the default 0600 permissions on it, so if the passwords were to remain plaintext, it really wouldn't affect me. on a side note, i think the option of having a master password to encrypt all the account passwords is a waste of time. anyone that concerned with security probably just doesn't let gaim save the passwords anyway, and probably doesn't mind entering each one on login. -brian |
From: Luke S. <lsc...@us...> - 2004-04-29 18:08:43
|
On Thu, Apr 29, 2004 at 01:40:09PM -0400, Brian J. Tarricone wrote: > On Thu, 29 Apr 2004, Luke Schierer wrote: > > > i HATE the idea of obscuring the password. i HATE the idea of providing > > a false sense of security. i think this falsehood is WORSE than having > > plain text passwords in the file. for one thing it is a FALSE sense of > > security, and for a second it is contributing to computer user > > ignorance and stupidity. > > i think you're missing the point on the user ignorance front. the part > that many users are ignorant about is that the more common types of > password-obscuring are easily reversible. leaving the password as > plaintext doesn't change that. the user that was originally stupid is > still stupid. i'd argue that gaim is actually doing the uninformed user > a disservice - you're just protecting them from that stupidity, since > hopefully the user would notice the password there in plaintext, and > think "oh, i shouldn't share that." they remain ignorant of weak > password-obscuring methods. > > the only argument in favor here is that, if a user is annoyed about > it being plaintext, and then complains, you (or someone else) can point > them to gaim's password-rationale document, and then they'll learn that > obscuring a password is just that - obscuring, and it isn't safe or > encrypted. that is, assuming they read and understand it. however, i > think this takes more initiative than you can ascribe to the average > user. > > personally, i think obscuring the password is good simply because it > prevents someone from discovering your password from a casual glance. > say you have the file open for some unknown reason, and you have a > friend there looking over your shoulder. why in the world are you opening this file? because you want to break things? > > if you want, when you're writing out the accounts.xml file, stick an > XML comment right above where each password is stored, such as: > <!-- NOTE: THIS PASSWORD IS ONLY WEAKLY OBSCURED, AND CAN BE EASILY > CONVERTED BACK INTO YOUR PLAINTEXT PASSWORD. DO NOT SHARE THIS > FILE WITH ANYONE. FOR FURTHER INFO, SEE http://... > --> how about we just remove saved passwords entirely? i'm leaning towards that increasingly as this thread continues. > (hopefully whatever XML parser/generator gaim is using supports > injecting comments in that manner.) > > you get pretty much the same effect. a user that is ignorant enough to > still share the file with someone else after reading that (or, looking > at the file and failing to read that) deserves what he/she gets. > perhaps i'm a pessimist, but i consider someone like that too far gone > for any amount of user education to do any good. > how about we just tell them in the inteface that its not safe and assume no one is opening a file they have no reason to? > personally, i guess i don't care all that much. i don't believe i've > ever opened my accounts.xml file in a text editor, and the file has the > default 0600 permissions on it, so if the passwords were to remain > plaintext, it really wouldn't affect me. > exactly, the file is protected already, and protected adequately unless you actually do something fairly unusual. > on a side note, i think the option of having a master password to > encrypt all the account passwords is a waste of time. anyone that > concerned with security probably just doesn't let gaim save the > passwords anyway, and probably doesn't mind entering each one on login. > i've been saying that ;-) |
From: Rob F. <ga...@ro...> - 2004-04-29 18:29:56
|
We'll do a weak encryption. sure, its false security, but just some random joe schmoe that stumbles by isnt going to be able to see it. it should shut everyone up, if not, then screw'em. ;) |
From: Luke S. <lsc...@us...> - 2004-04-29 18:05:00
|
On Thu, Apr 29, 2004 at 12:31:11PM -0500, Rick Romero wrote: > On Thu, 2004-04-29 at 12:13, Luke Schierer wrote: > > On Thu, Apr 29, 2004 at 06:01:55PM +0100, Stuart Clark wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > > Hash: SHA1 > > > > > > Luke Schierer wrote: > > > > > > > >> Stuart here is advocating 2A, Vince 2B. the problem with 2b is that its > > > >> deceptive, the problem with 2a is that you still end up typing in a > > > >> password, so what is the overall benifit over 2d? also, when > > > >> randomgaimuser enables 2a, then forgets his passphrase he looses all his > > > >> settings, whereas when randomgaimuser forgets an aim or yahoo password > > > >> he can get it back. and on top of that is the complexity or handling > > > >> enabling and, more, disabling that option on top of that. its asking for > > > >> trouble, trouble that could all be avoided by users simply using 2d if > > > >> they don't feel the .gaim directory is sufficiently protected. > > > > > > > > > > I'm not really advocating anything, but just suggesting that if some > > > type of password 'obfuscation' it may be better to do it 'properly' > > > rather than just ROT13 or something. > > > > > > I realise the support issue it could create, but remember losing the > > > password doesn't stop you from starting from scratch with the individual > > > im passwords (which can be found using their own methods). > > > > > > I suppose it would be a balance between the problem of losing the main > > > password (having to reented the lot) agains the false sense of security > > > some may have with simple encoding (which probably causes less actual > > > support, but more potential problems). > > > > > > Having said all that, I'm happy how things are, and where things to > > > change, I would want a way to keep the current plaintext passwords. > > > > to be safe you'd have to re-enter it every time the .gaim/accounts.xml > > is read or written. this would lead thus break the ability to have > > yourself automatically reconnected, it would make the ability to change > > accounts more painful, it would add a step to starting up, and it would > > be a support nightmare when i have to tell users that they have to > > delete all their accounts and start over. please tell me who in their > > right mind really wants this, but isn't willing to not store their > > passwords at all. > > > > > > i HATE the idea of obscuring the password. i HATE the idea of providing > > a false sense of security. i think this falsehood is WORSE than having > > plain text passwords in the file. for one thing it is a FALSE sense of > > security, and for a second it is contributing to computer user > > ignorance and stupidity. > > (jumping in - I'm with ya in principle, but..): > > So passwords are plain text to prevent randomgaimuser from having a > false sense of security, yet the password entry box is obfuscated. > > 1 EVERYONE will see the password entry box. > 2 Few will view the stored file with the password in it. > 3 Even fewer will read the source. > > 1 is ok to obfuscate, but 2 and 3 aren't? for the popup dialogs that ask for a password that isn't stored it has to be **ed out since everyone walking by will also see it. for the account editor its much the same. the file itself though is different. you'd have to be in a pretty unusal situation to be legitimately opening it anyway, now at first this seems like an arguement that it doesn't matter, BUT, if you are hand editing it, chances are its because something has gone wrong and you want as little going on in that file as possible. encryption is more going on and thus more place for the error to be occuring. not encrypting is the same as editing a .fetchmailrc file. further. if you do go through the trouble of finding and hand editing an accounts.xml file and you see that the passwords are garbledygook, you aren't going to think about how simple it must be to break them. you, as an uniformed computer user, are going to think they are safe. your lack of understanding of the difference between encrypting and obscuring will lead to an increased complacency. on the other hand, if you see plaintext, you will (maybe) realize they aren't that safe and be motivated to start thinking, and thus to educate yourself. users who never notice this whole issue are still just as safe as the file permissions on their operating system of choice. with any obscuration scheme it really wouldn't take thought at all to open and steal these accounts: it would just take the ability to copy the file and run gaim. on a side note, someone brought up the idea of using a 1 way hash. that person apparently forgot that we have to read that password back out of the file and send it to the server. a 1 way hash is great for signing documents. its no good when you have to regenerate the orginal from the output. luke > > Rick > > > luke > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by: Oracle 10g > > Get certified on the hottest thing ever to hit the market... Oracle 10g. > > Take an Oracle 10g class now, and we'll give you the exam FREE. > > http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click > > _______________________________________________ > > Gaim-devel mailing list > > Gai...@li... > > https://lists.sourceforge.net/lists/listinfo/gaim-devel > |
From: Rick R. <ri...@ha...> - 2004-04-29 18:16:16
|
On Thu, 2004-04-29 at 13:04, Luke Schierer wrote: > On Thu, Apr 29, 2004 at 12:31:11PM -0500, Rick Romero wrote: > > On Thu, 2004-04-29 at 12:13, Luke Schierer wrote: > > > On Thu, Apr 29, 2004 at 06:01:55PM +0100, Stuart Clark wrote: > > > > -----BEGIN PGP SIGNED MESSAGE----- > > > > Hash: SHA1 > > > > > > > > Luke Schierer wrote: > > > > > > > > > >> Stuart here is advocating 2A, Vince 2B. the problem with 2b is that its > > > > >> deceptive, the problem with 2a is that you still end up typing in a > > > > >> password, so what is the overall benifit over 2d? also, when > > > > >> randomgaimuser enables 2a, then forgets his passphrase he looses all his > > > > >> settings, whereas when randomgaimuser forgets an aim or yahoo password > > > > >> he can get it back. and on top of that is the complexity or handling > > > > >> enabling and, more, disabling that option on top of that. its asking for > > > > >> trouble, trouble that could all be avoided by users simply using 2d if > > > > >> they don't feel the .gaim directory is sufficiently protected. > > > > > > > > > > > > > I'm not really advocating anything, but just suggesting that if some > > > > type of password 'obfuscation' it may be better to do it 'properly' > > > > rather than just ROT13 or something. > > > <snip> > > > i HATE the idea of obscuring the password. i HATE the idea of providing > > > a false sense of security. i think this falsehood is WORSE than having > > > plain text passwords in the file. for one thing it is a FALSE sense of > > > security, and for a second it is contributing to computer user > > > ignorance and stupidity. > > > > (jumping in - I'm with ya in principle, but..): > > > > So passwords are plain text to prevent randomgaimuser from having a > > false sense of security, yet the password entry box is obfuscated. > > > > 1 EVERYONE will see the password entry box. > > 2 Few will view the stored file with the password in it. > > 3 Even fewer will read the source. > > > > 1 is ok to obfuscate, but 2 and 3 aren't? > > for the popup dialogs that ask for a password that isn't stored it has > to be **ed out since everyone walking by will also see it. for the > account editor its much the same. Sure. I agree with that, but only _YOU_ know it's that way. > the file itself though is different. you'd have to be in a pretty > unusal situation to be legitimately opening it anyway, now at first this > seems like an arguement that it doesn't matter, BUT, if you are hand > editing it, chances are its because something has gone wrong and you > want as little going on in that file as possible. encryption is more > going on and thus more place for the error to be occuring. not > encrypting is the same as editing a .fetchmailrc file. You mean if the person manually editing it screws something up, Gaim may not work right? That's a given either way, isn't it? > further. if you do go through the trouble of finding and hand editing an > accounts.xml file and you see that the passwords are garbledygook, you > aren't going to think about how simple it must be to break them. you, as > an uniformed computer user, are going to think they are safe. your > lack of understanding of the difference between encrypting and > obscuring will lead to an increased complacency. on the other hand, if > you see plaintext, you will (maybe) realize they aren't that safe and be > motivated to start thinking, and thus to educate yourself. Except that, as an end user, I can say I didn't expect the passwords to be in plain text when I saw they were **ed in the form. > users who never notice this whole issue are still just as safe as the > file permissions on their operating system of choice. with any > obscuration scheme it really wouldn't take thought at all to open and > steal these accounts: it would just take the ability to copy the file > and run gaim. That's true now - but your argument is based on the assumption that an end user knows that a **ed password in a form is completely different from how that data is stored. > on a side note, someone brought up the idea of using a 1 way hash. that > person apparently forgot that we have to read that password back out of > the file and send it to the server. a 1 way hash is great for signing > documents. its no good when you have to regenerate the orginal from the > output. Right. That was actually part of my original reply - but I guess I forgot to cut/paste it into rev 2 ;) Rick > luke > > > > > Rick > > > > > luke > > > > > > > > > ------------------------------------------------------- > > > This SF.Net email is sponsored by: Oracle 10g > > > Get certified on the hottest thing ever to hit the market... Oracle 10g. > > > Take an Oracle 10g class now, and we'll give you the exam FREE. > > > http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click > > > _______________________________________________ > > > Gaim-devel mailing list > > > Gai...@li... > > > https://lists.sourceforge.net/lists/listinfo/gaim-devel > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: Oracle 10g > Get certified on the hottest thing ever to hit the market... Oracle 10g. > Take an Oracle 10g class now, and we'll give you the exam FREE. > http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click > _______________________________________________ > Gaim-devel mailing list > Gai...@li... > https://lists.sourceforge.net/lists/listinfo/gaim-devel |
From: Luke S. <lsc...@us...> - 2004-04-29 18:32:10
|
On Thu, Apr 29, 2004 at 01:16:12PM -0500, Rick Romero wrote: > On Thu, 2004-04-29 at 13:04, Luke Schierer wrote: > > On Thu, Apr 29, 2004 at 12:31:11PM -0500, Rick Romero wrote: > > > On Thu, 2004-04-29 at 12:13, Luke Schierer wrote: > > > > On Thu, Apr 29, 2004 at 06:01:55PM +0100, Stuart Clark wrote: > > > > > -----BEGIN PGP SIGNED MESSAGE----- > > > > > Hash: SHA1 > > > > > > > > > > Luke Schierer wrote: > > > > > > > > > > > >> Stuart here is advocating 2A, Vince 2B. the problem with 2b is that its > > > > > >> deceptive, the problem with 2a is that you still end up typing in a > > > > > >> password, so what is the overall benifit over 2d? also, when > > > > > >> randomgaimuser enables 2a, then forgets his passphrase he looses all his > > > > > >> settings, whereas when randomgaimuser forgets an aim or yahoo password > > > > > >> he can get it back. and on top of that is the complexity or handling > > > > > >> enabling and, more, disabling that option on top of that. its asking for > > > > > >> trouble, trouble that could all be avoided by users simply using 2d if > > > > > >> they don't feel the .gaim directory is sufficiently protected. > > > > > > > > > > > > > > > > I'm not really advocating anything, but just suggesting that if some > > > > > type of password 'obfuscation' it may be better to do it 'properly' > > > > > rather than just ROT13 or something. > > > > > <snip> > > > > i HATE the idea of obscuring the password. i HATE the idea of providing > > > > a false sense of security. i think this falsehood is WORSE than having > > > > plain text passwords in the file. for one thing it is a FALSE sense of > > > > security, and for a second it is contributing to computer user > > > > ignorance and stupidity. > > > > > > (jumping in - I'm with ya in principle, but..): > > > > > > So passwords are plain text to prevent randomgaimuser from having a > > > false sense of security, yet the password entry box is obfuscated. > > > > > > 1 EVERYONE will see the password entry box. > > > 2 Few will view the stored file with the password in it. > > > 3 Even fewer will read the source. > > > > > > 1 is ok to obfuscate, but 2 and 3 aren't? > > > > for the popup dialogs that ask for a password that isn't stored it has > > to be **ed out since everyone walking by will also see it. for the > > account editor its much the same. > > Sure. I agree with that, but only _YOU_ know it's that way. > > > the file itself though is different. you'd have to be in a pretty > > unusal situation to be legitimately opening it anyway, now at first this > > seems like an arguement that it doesn't matter, BUT, if you are hand > > editing it, chances are its because something has gone wrong and you > > want as little going on in that file as possible. encryption is more > > going on and thus more place for the error to be occuring. not > > encrypting is the same as editing a .fetchmailrc file. > > You mean if the person manually editing it screws something up, Gaim may > not work right? That's a given either way, isn't it? it'd probly erase the file. > > > further. if you do go through the trouble of finding and hand editing an > > accounts.xml file and you see that the passwords are garbledygook, you > > aren't going to think about how simple it must be to break them. you, as > > an uniformed computer user, are going to think they are safe. your > > lack of understanding of the difference between encrypting and > > obscuring will lead to an increased complacency. on the other hand, if > > you see plaintext, you will (maybe) realize they aren't that safe and be > > motivated to start thinking, and thus to educate yourself. > > Except that, as an end user, I can say I didn't expect the passwords to > be in plain text when I saw they were **ed in the form. > Mark and i pretty much agree we should modify the dialog to mention that its storing in plain text. you'll note i have not objected to doing this at all anywhere in this thread. thus the user WILL know that the **ed password isn't stored hidden. > > users who never notice this whole issue are still just as safe as the > > file permissions on their operating system of choice. with any > > obscuration scheme it really wouldn't take thought at all to open and > > steal these accounts: it would just take the ability to copy the file > > and run gaim. > > That's true now - but your argument is based on the assumption that an > end user knows that a **ed password in a form is completely different > from how that data is stored. > see above. > > on a side note, someone brought up the idea of using a 1 way hash. that > > person apparently forgot that we have to read that password back out of > > the file and send it to the server. a 1 way hash is great for signing > > documents. its no good when you have to regenerate the orginal from the > > output. > > Right. That was actually part of my original reply - but I guess I > forgot to cut/paste it into rev 2 ;) > > Rick > > > luke > > > > > > > > Rick > > > > > > > luke > > > > > > > > > > > > ------------------------------------------------------- > > > > This SF.Net email is sponsored by: Oracle 10g > > > > Get certified on the hottest thing ever to hit the market... Oracle 10g. > > > > Take an Oracle 10g class now, and we'll give you the exam FREE. > > > > http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click > > > > _______________________________________________ > > > > Gaim-devel mailing list > > > > Gai...@li... > > > > https://lists.sourceforge.net/lists/listinfo/gaim-devel > > > > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by: Oracle 10g > > Get certified on the hottest thing ever to hit the market... Oracle 10g. > > Take an Oracle 10g class now, and we'll give you the exam FREE. > > http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click > > _______________________________________________ > > Gaim-devel mailing list > > Gai...@li... > > https://lists.sourceforge.net/lists/listinfo/gaim-devel > |
From: Jon O. <jo...@fo...> - 2004-04-29 18:25:03
|
On Thu, 2004-04-29 at 14:04, Luke Schierer wrote: [snip] > on a side note, someone brought up the idea of using a 1 way hash. that > person apparently forgot that we have to read that password back out of > the file and send it to the server. a 1 way hash is great for signing > documents. its no good when you have to regenerate the orginal from the > output. >=20 > luke A one-way hash would work effectively with certain protocols such as oscar, since oscar using the following authentication: MD5(key + MD5(password) + AIM_MD5_STRING) In this scenario, a user's saved password could be hashed and stored in the accounts.xml safely AND still be used in authenticating without requiring a master password or other user intervention. While this doesn't protect you from someone swiping your accounts.xml file, it does prevent them from obtaining your plaintext password.=20 Obviously, by this method, the password storage technique would have to vary depending on the protocol. Regards, Jon Oberheide jo...@fo... |
From: Jeremy B. <je...@br...> - 2004-04-29 18:41:49
|
Jon Oberheide wrote: >On Thu, 2004-04-29 at 14:04, Luke Schierer wrote: >[snip] > > >>on a side note, someone brought up the idea of using a 1 way hash. that >>person apparently forgot that we have to read that password back out of >>the file and send it to the server. a 1 way hash is great for signing >>documents. its no good when you have to regenerate the orginal from the >>output. >> >>luke >> >> > >A one-way hash would work effectively with certain protocols such as >oscar, since oscar using the following authentication: > >MD5(key + MD5(password) + AIM_MD5_STRING) > >In this scenario, a user's saved password could be hashed and stored in >the accounts.xml safely AND still be used in authenticating without >requiring a master password or other user intervention. > > You could still swipe the MD5'd password though, put it in your accounts.xml file, and log on as that user. Isn't that almost as bad as having the plaintext password? I don't see any way to add *any* level of security here without storing a key someplace else (e.g. the user's brain). It's just not possible. If gaim can log in solely from the info in "accounts.xml", then so can anyone else. Jeremy |