Encrypt passwords in accounts.adm?

[Xuri]

Not sure how big a thing this really is, but perhaps UOX3 should save all passwords in encrypted form instead of as normal text? Any thoughts?

[giwo]

This is something I've considered for a while, and should definately be implemented. The discussion at this point should be what format to use for encryption and the best way in which to implement it.

[Grimson]

This is something I've considered for a while, and should definately be implemented. The discussion at this point should be what format to use for encryption and the best way in which to implement it.

I haven't done this in C++ before, but how about saving them as a SHA1 hash? A more complex encryption wouldn't make any sense to me.

[Sydius]

Considering the passwords will most likely be stored on the same machine as the open-source piece of software that can decrypt them, encryption could never be more than a slight annoyance – perhaps enough of an annoyance to stop some people, but if you really wanted to know the passwords, it would be trivial to decrypt them, considering you have the software to do so right there… Therefore, I do not see any reason to use a complex encryption system, and would be more in favor of something simple, and optional.

[giwo]

I honestly don't know much about encryption, but aren't there encryption routines that are one-way? (IE You can encrypt but not decrypt).

[giwo]

Ahh, a quick google search found what I was thinking of.

MD5 Hashing would allow us to encrypt the password (toggleable via the uox.ini), and would be irreversable. Now you can still break it, all you have to do is guess every possible combination of letters and numbers the user could have used and compare it to the MD5 hash that was generated when they created the password, if it matches, you know their password!

Anyhow, that would be my thought for the best option of secure password storage.

[giwo]

Upon further investigation, I'd have to agree with Grimson on using an SHA1 hash. Both should be irreversable, but the MD5 has been proven unreliable (and possibly breakable), where SHA1 shows a greater degree of security (at least enough to secure passwords to the degree we want to).

[Xuri]

There's still a question of how exactly to implement encryption of passwords. At what point do we encrypt them? Will it still be possible to enter new accounts/passwords manually? What happens if a user forgets his password? How do we reset/change it? etc.

[giwo]

Here is how I would envision the system.

1) Admin manually creates an account.
2) On read-in, a text-only password is converted into a hash, and on next save the accounts file is altered as such.
3) On login, a hash of what the user entered for password is compared to the hash we have stored, if they match, login successful.


1) Admin enables auto-account creation
2) User creates a new account, password is automatically made into a hash, and stored on next save
3) On login, a hash of what the user entered for password is compared to the hash we have stored, if the match, login successful.

Now, as for forgotten passwords, I would say the best bet is to attach an email address to every account. When the user forgets the password, they can request a reset at which time the admin changes it to something random and emails the change to the email addy on file. If the email address is no longer active, the user would have to pass a knowledge test (naming all the characters on the account, etc).

[Grimson]

Here is how I would envision the system.

1) Admin manually creates an account.
2) On read-in, a text-only password is converted into a hash, and on next save the accounts file is altered as such.
3) On login, a hash of what the user entered for password is compared to the hash we have stored, if they match, login successful.


1) Admin enables auto-account creation
2) User creates a new account, password is automatically made into a hash, and stored on next save
3) On login, a hash of what the user entered for password is compared to the hash we have stored, if the match, login successful.

Now, as for forgotten passwords, I would say the best bet is to attach an email address to every account. When the user forgets the password, they can request a reset at which time the admin changes it to something random and emails the change to the email addy on file. If the email address is no longer active, the user would have to pass a knowledge test (naming all the characters on the account, etc).

Sounds good.

[Maarc]

There's 2 different schemes, by and large. Authentication, and verification. We only need verification, authentication is more complex.

Essentially, it's a trivial matter. Bung the password through a one way hash, and compare the end results. At no stage do you actually need to care what the password is

*IF* you want to let an admin create an account manually, then I would suggest a different tag. Like, MANUALPASS or something. Because, while unlikely, a hash might actually turn out a real text result. And even then, you'd have to try and detect if it's a word or not. Simplest would be separate tags. I think it would be a relatively trivial thing to do.

If people forget their passwords, aren't they silly? But then, isn't that half the point of a call centre, to reset such things?

Sounds like you've given it a lot of thought, and don't see too many pitfalls.

[Xuri]

It's the "HOW to reset" it I'm wondering about =)

[Maarc]

Few solutions

1) Manual, rip it out of the admin file
2) Player command - if they're logged in, already authenticated, so a simple change
3) GM command - reset for another user, make it something simple (like username + month or something)
4) Third party / web server sort of jazz

[ShadowBranch]

I think MD5 hashing would be fine. Although it has been proven to be unreliable, it is very simple to implement. Now as far as when to implement the encryption, when the person first sends their password, preferably in the packet handling file, but maybe just in the login check, encrypt it, then it will just work it's self out so only one call to encrypt!

new as far as admin stuff, just put a new password in the accounts file as a new variable. That way we check to see if a password is in there, if there is, override the users password and use the manual. Then allow the user to change it and remove whats in the manual password variable.

I do a lot of programming and find that MD5 hashing works good enough for this system. In any event, it someone really wants a password, they will get it.

[Sydius]

MD5 and even SHA-1 have had some issues brought forth about their security, but either should be far more than enough for UOX3. You could always go with SHA-2, if you really care, though.

I still do not see it as being worth the effort though -- it is an open-source software project, and even if it were not, it would be exceedingly easy to get every password as soon as someone logs in with something as simple as a packet monitor.

The only scenario where I see it as being any more secure than it is now is if, for some reason, the shard's hard drive is stolen or the files taken… and only if nobody logs into it or changes their password from that point on. I suppose that is something, but is it worth all these other considerations (especially reset issues, etc.)?

[Xuri]

Well - there's possibly another side to this issue though, admin ethics, or something. It's a given fact that people re-use their passwords from one place to another. Some may have a few they pick from, but generally the password-reuse is very high. So in theory, a rogue admin (or anyone else with access to the server) could absuse this by taking the passwords and getting access to other stuff, like e-mail or other services which the players use regulary. Like normal UO.

With a strong enough password encryption the chance of this happening (albeit already very low) could lower.

*shrug*

EDIT: Of course, this would depend on auto-creation of accounts or some other method which wouldn't make it necessary for the admins to actually see the plain-text-passwords in the first place.

[giwo]

Well, Syd makes a good point in that if an admin really wants the passwords he can get them. Unfortunately this is unavoidable as we strip encryption from the client, and thus it sends the packets containing the username/password in plain text.

However, just because you can't stop someone from breaking a window doesn't mean you shouldn't lock the doors.

Any of the ir-reversable encrypters should work fine. This would prevent hackers and other such malicious people from obtaining the passwords once they are written to the accounts.adm files, at least not without a significant amount of work.

Ultimately it is in the users hands to be careful about his password usage. Using a common password for, say, your email as an Emulator login is a bad idea regardless of the server or the emulator. I tend to have one common login for all emulator servers I use and then seperate passwords (scaling upwards in security) for each step (for instance I don't use the same one on these forums that I do to get into my online bank account).

With all that said, eventually I do hope to implement this feature, but I have a much bigger concern at the moment, which I may document in another thread....

[punt]

Not that it really matters, but ask one to consider this:

The current state of UOX3.
The miminal state necessary for a online active shard.
The state where one is beyond the minimum.
The state where it is the deemed as the leader (in some form).


Now, consider where account encryption falls, in reference to the above. I believe that is how users would look at it. One of the major complaints in the past, from users, is focus on getting to some set capability that makes UOX meet some standard of desirement for a shard.


Ok, now for my opinon, password encryption isn't in the gap where UOX3 is now, and the first two. So if I where a user (which I am not, so this thought can be ignored), I would wonder why time was spent on this versus the other stuff.

As a shard operator, I would object ot having to use the emu to create accounts (should be able to do outside the emu). If the concept is to allow cleartext passwords, that are converted on emu startup, what does that buy (for those cleartext passwords could be sitting around for a long time perhaps). Point is, a nice feature, but to get a "cOmplete" shard solution, more then a trival amount effort. So back to the "ranking question".