Password stored in EL.INI

[The_Piper]

The client allows to store account/password in EL.INI for a more comfortable login.

 

Unfortunately this is like writing it on a piece of paper and pinning it at your monitor, which i would call a huge security hole.

 

So i suggest to get rid of that feature ASAP, because the client should not support ppl to store their passwords in an unsafe place. And EL.INI on a computer, multiple ppl use, *IS* an unsafe place.

 

Piper

[Wytter]

It's up to the people to decide if they wish to have their password stored in their el.ini... Giving them the opportunity to is not a bad thing imho.

[Aislinn]

I have to agree with Pip on this one. Soooo many of our abuse reports about their character getting hacked/used/stolen/cleaned out is because of this.

 

For adults who actually have control over their own computer, I agree that it is an issue of personal responsibility. But we have many kids who have to share a computer with brothers/sisters/cats/dogs/neighbors walking by/etc...

 

We would cut down on a LOT of problems if we eliminated this. I mean really now, how long does it really take to type in a name and pw?

[Ravenod]

If someone is smart enough to find/open/edit/save their password information into el.ini, then they are smart enough to know whether or not other people could get their password. And smart enough to take measures to make sure other people can't see their password.

 

They don't think about other people getting their passwords? Hows that our problem to fix? We can't start thinking for people...It doesn't work.

[Aislinn]

I disagree. As one of the people who have to answer these people and their endless abuse reports because of this problem, I would like to see it removed. We seem to think for them in almost every other area of the game, why not this one too?

[Ghrae]

Just put a message above the password section

 

# Placing your password here will allow anyone who uses this computer to log in with your character and could result in loss of items, attributes or even the character itself.

 

I don't think removing the feature is the answer. I'm sorry, but I don't think we need to be babysitters of those without common sense. It's like #ignore. How many messages do we get throughout the day where someone tells us that PlayerX is PMing him with bad stuff? Tons! But we're not going to get rid of PMs. We suggest to them to use the #ignore.

 

And in this case we can suggest to them to stop storing their password.

[Aislinn]

We could remove an awful lot of headaches for 5 seconds worth of laziness. Sorry, I think this is totally unnecessary. <_<

[gadai]

I don't think that the password storing feature us a problem - it even warns people in the .ini not to use the feature if it's a shared computer. Anyone with enough knowledge to edit the .ini to take advantage of the feature should be considered 'warned' and the consequences their own. If someone has physical access to your machine a .ini is the least of your problems.

[The_Piper]

We can't start thinking for people...It doesn't work.

186191[/snapback]

 

Wrong. That we *expect* that ppl think wont work. But we should not make it too easy that other ppl can get your password. And storing it in clear ASCII text in EL.INI is way too easy to get abused.

 

So, if we see that ppl cant deal with that option, and we know they cant, we should get rid of it. Because *WE* have the trouble.

 

And that is something we should take care off, because its a feature of the client, so ppl can blame the client if they get rid of their password. Again, the EL client offers an option where ppl can easy lose their password. And that IS a serious bug.

 

Think what ppl would say, if Windows for example offers the userid/password of the last user logged in so that you only have to click "O.K." to log into her/his account.

 

Piper

[Wytter]

If people are hacked because of this feature it is entirely their own fault and not ours. If a person with access to your computer hacks your account, you'll of course also have access to that person, hence you can get revenge if that's what you're after.

[Aislinn]

Yes it's their own fault.

 

However, the troubles it causes FAR outweighs the benefit.

[The_Piper]

If people are hacked because of this feature it is entirely their own fault and not ours.

186205[/snapback]

 

If a software offers such a feature and ppl get hacked because of this, the answer cant be "well, why do you use it?".

 

Thats not how to talk about security issues.

 

Piper

[ttlanhil]

Wrong. That we *expect* that ppl think wont work. But we should not make it too easy that other ppl can get your password. And storing it in clear ASCII text in EL.INI is way too easy to get abused.

well... encrypting it would be possible

Think what ppl would say, if Windows for example offers the userid/password of the last user logged in so that you only have to click "O.K." to log into her/his account.

186203[/snapback]

what about where you don't even get the login screen, it logs in automatically for you? mine does that. because I used that option, and because I'm smart enough to now how to do it, I'm smart enough to now the security risks

 

and this is only a problem for windows users you realise, *nix puts this in the users' home directory... which we should do on WinNT (including 2000 and XP) as well. it can't be that difficult, and will probably half the problem, with other bonuses, without havin the negative of making people type in every time the connect (which would be highly annoying for people like me, some days I fire up test server client a dozen times)

 

however, if you really want to do away with this... make it undocumented. it's not noted in el.ini, but will work if present (might have to rename it for all those already using it though)

 

then they require mroe work and more thought before they can use this feature

[toba]

Okay... I'm a newbie but hey I'll chime in.

 

It is a security risk no matter how you slice it. The password could be there for all to see... in plain text.

-- Ehh, so what. It already says in the el.ini file, that it can be a security problem. And it's not used by default, so the person would have to purposely put it in there. IF the client was storing the username and/or password by default then I think this would be much more of an issue.

 

Having a Username and Password defined can be a security problem. Use if you are comfortable

in people that can get to you machine knowing this information

 

Now, for the packagers... how bout maybe a little fix. For the Linux package anyway, just:

chmod 600 el.ini

in the new package build.

 

For the Windows... I'm not sure. Is there an actual installer? If so, can the Windows installer set permissions on files (NTFS perms??).

 

If not, could that actually be done on a first run of the client to set "sane" file (NTFS/Unix) permissions on specific files (el.ini, [home]/.elc/ tree, etc.), when they're created or checked? I know it's just using the default creation perms (umask on *nix) right now, but if something may be able to have a password in it, then it should only be accessible to the user running the app.

 

-J

[Aislinn]

then they require mroe work and more thought before they can use this feature

186216[/snapback]

I'll ask again, what possible benefit does it have other than saving 5 seconds of time? Why is that worth all the problems?

 

I would hardly call it a "feature" if it causes more problems than benefits.

[Ghrae]

People mess with their ini file, they can do a lot of things that mess themselves up. I've screwed up the F2 function and the AFK function before.

 

I'm sorry, but put a disclaimer in the file or above the feature. We're developers and moderators, not babysitters.

[crusadingknight]

I'll ask again, what possible benefit does it have other than saving 5 seconds of time?  Why is that worth all the problems?

 

I would hardly call it a "feature" if it causes more problems than benefits.

186219[/snapback]

What you are saying is as if you were saying Nautilus (or Windows Explorer) shouldn't have the delete function, because people can delete things.

 

If someone does it, it's their use of a feature. We don't force them to. Anyway, if you're thinking that way, it can still be grabbed by keyloggers, packet filters and whatnot on a shared computer. (Hint: Never use any password you value on a shared computer). Not having it stored in the .ini file also opens up the possibility of keylogging every login. The threat is there, but if you're worried about security, you have to use a private computer.

 

Sticking a note to the monitor is a good analogy - just because you can, do you?

Edited August 7, 2005 by crusadingknight

[toba]

I'll ask again, what possible benefit does it have other than saving 5 seconds of time?  Why is that worth all the problems?

 

I would hardly call it a "feature" if it causes more problems than benefits.

186219[/snapback]

 

My guess is this.... I personally have about 30 different passwords that I use for different accounts. A lot of times, say if the website will store the login/pass in a cookie for a while, I'll jump on it, so I don't have to remember what I used for that specific website constantly.

 

It's a convienience thing, but it's also my workstation, my login/password. If I want to put it in a little cookie for any possible XSS to steal, then hey, it's my choice.

 

I make sure that no other users on my workstation can access the directory that my web cookies are stored in, but that still doesn't mitigate the problem of a possible XSS. It a risk, but the benifit outweighs the risk (for me), in most of the casses like this.

 

-J

[ttlanhil]

-- Ehh, so what. It already says in the el.ini file, that it can be a security problem. And it's not used by default, so the person would have to purposely put it in there. IF the client was storing the username and/or password by default then I think this would be much more of an issue.

exactly. but there are people who use this without thought who are apparently ruining it for those few of us who know how to use our brains

Now, for the packagers... how bout maybe a little fix. For the Linux package anyway, just:

chmod 600 el.ini

in the new package build.

if it's in their home directory, wouldn't it be impossible for anyone else but root to get to anyway? I suppose that depends on distro and such...

For the Windows... I'm not sure. Is there an actual installer? If so, can the Windows installer set permissions on files (NTFS perms??).

probably, if it was saved in the users' home directory. which it isn't, and it a better place to fix things

If not, could that actually be done on a first run of the client to set "sane" file (NTFS/Unix) permissions on specific files (el.ini, [home]/.elc/ tree, etc.), when they're created or checked? I know it's just using the default creation perms (umask on *nix) right now, but if something may be able to have a password in it, then it should only be accessible to the user running the app.

 

-J

186217[/snapback]

 

 

I'll ask again, what possible benefit does it have other than saving 5 seconds of time?  Why is that worth all the problems?

 

I would hardly call it a "feature" if it causes more problems than benefits.

186219[/snapback]

eh, if you have a complex password saved (hard for a random attack, and hard to remember, but you trust your computer) then it could be more than 5 sec, and 10sec here and there adds up pretty fast. especially when you're making changes and relogging every few minutes. though in that I'm probably an extreme case

[toba]

if it's in their home directory, wouldn't it be impossible for anyone else but root to get to anyway? I suppose that depends on distro and such...

186227[/snapback]

 

Yeah, it's pretty distro dependent. For example what I'm running creates new home directories with perms 711 (custom adduser script, straight useradd is 755). Those perms are sane, as it allow anyone to pass through the users $HOME (say, to get to a public_html), but other users cannot use 'ls' to read the contents of the users homedir.

 

IIRC, Fedora, Deb, etc.. create the users $HOME at 700, in which case, this is moot unelss they don't have root on the box they installed EL on, or someone gets root on the box.

 

-J

[Aislinn]

exactly. but there are people who use this without thought who are apparently ruining it for those few of us who know how to use our brains

186227[/snapback]

Well every rule that limits something, or every "feature" that has gotten removed before, has and has had people saying that same thing. You wouldn't be the first case of that in EL.

[The_Piper]

This discussion goes absolutely the wrong way.

 

We are talking about passwords which gives ppl access to the game and items of other ppl, at least items, they bought with *REAL* money.

 

What would you guess? If your credit card offers a little writeable square labeled "Write down your password here", who would be blamed in court? The customer, if he got scammed, or the credit card company?

 

If we dont care about passwords and even offer a feature to store them in an unsafe place, like EL.INI, we should better get rid of passwords, because they are now WORTHLESS!

 

At least, the client shouldnt make it easy to expose the password to public...

 

Piper

[crusadingknight]

This discussion goes absolutely the wrong way.

 

We are talking about passwords which gives ppl access to the game and items of other ppl, at least items, they bought with *REAL* money.

 

What would you guess? If your credit card offers a little writeable square labeled "Write down your password here", who would be blamed in court? The customer, if he got scammed, or the credit card company?

 

If we dont care about passwords and even offer a feature to store them in an unsafe place, like EL.INI, we should better get rid of passwords, because they are now WORTHLESS!

 

At least, the client shouldnt make it easy to expose the password to public...

 

Piper

186238[/snapback]

Great, let's great a program to make their computer explode and burn all their paper and can't write it down too.

 

There is already a warning there, as a disclaimer.

Having a Username and Password defined can be a security problem. Use if you are comfortable

in people that can get to you machine knowing this information

Seeking a security problem because people make excuses for others using their accounts when they give out passwords is not the way to go.

[Aislinn]

Ugh.

The point here is that by having that option, we are enabling bad security. Whether or not the people who use it are geniuses or idiots.

 

Edit:

My side problem is this: The amount of "help me I've been scammed/hacked/blahblahblah"s that we get is tremendous. And half of those are because of this "feature". To all the programming people who think this "feature" is so nifty...the mods and NH's will send all the players who have had problems because of this to YOU. YOU can all talk for hours per player trying to explain to them "too bad, you're an idiot".

[Sistema]

What I think is, that if people find it risky, they won't type it in, but if they know they are safe, then there's no problem...

 

but then you're going to say "it's not worth the trouble", if people come up and say someone stole my password from el.ini, all you have to say is "you should've thought twice before writing it there" or "you should've been more careful keeping it safe"...

 

Get what I mean?

 

Well, at least I know I'm safe, I also use teh password in el.ini thingy.

(sees everyone gazing),

*puts teh uber firewall on*

Edited August 7, 2005 by sisteMa`