Password on server in plaintext
Moderator: Board moderators
-
Darax The Good
- Luser
- Posts: 10
- Joined: Sun Jun 26, 2005 7:31 pm
Password on server in plaintext
Why is the password stored in the playerfile as plaintext. Couldn't the password be a hash?
-
Darax The Good
- Luser
- Posts: 10
- Joined: Sun Jun 26, 2005 7:31 pm
-
Darax The Good
- Luser
- Posts: 10
- Joined: Sun Jun 26, 2005 7:31 pm
Yes, It is in C. One issue with changing the behavoir in the windows server though, is that when a windows server tries to update, all of the passwords for users would be messed up. It would be easy to make a utility so the server admins could convert the passwords, however there would be thats one more thing for server admins to worry about when upgrading the version of the server.
This reminds me, currently the passwords from the client to the server are in plaintext when going over the network. Perhaps it should be set up so the client sends the password in hash, but the server accepts both hashed and plaintext passwords from clients for backwards compatability. Fixing this though, would mean that windows servers would need hashing capability in order deal with the new clients.
This reminds me, currently the passwords from the client to the server are in plaintext when going over the network. Perhaps it should be set up so the client sends the password in hash, but the server accepts both hashed and plaintext passwords from clients for backwards compatability. Fixing this though, would mean that windows servers would need hashing capability in order deal with the new clients.
-
Darax The Good
- Luser
- Posts: 10
- Joined: Sun Jun 26, 2005 7:31 pm
You should't send the hashed password across the wire-otherwise it will be easier to spoof someone (or just as easy compared to today). I truly hope the linux version doesn't do this-but I suspect that it doesn't. The client has to have consistent behavior regardless of the server.
Sending it encrypted would be better, but I don't think that is a trivial thing to do-would you be prepared to install SSL? For something like this I wouldn't be.
I understand the problem with the update. A possible design would be to put a new field in the user file for windows 'using hash' and if it doesn't exist, update the password to use a hash and create the field.
Sending it encrypted would be better, but I don't think that is a trivial thing to do-would you be prepared to install SSL? For something like this I wouldn't be.
I understand the problem with the update. A possible design would be to put a new field in the user file for windows 'using hash' and if it doesn't exist, update the password to use a hash and create the field.
Sending a hashed password across the wire is much better than the current situation of sending plaintexts across the wire when using a good hash such as MD5 or SHA1. Are you rerfering to replay attack, because then one needs to use encryption/hashing that changes based upon the time and/or number of connects etc. and the problem with that is that that would lock out people with the clock set wrong or would lock them out from using multiple clients. And doing something like ssh/ssl with all of the keys on both ends is too much effort really considering it's not credit card number going across the wire. I don't think that replay attacks are a big thing to worry about comparatively speaking, and since encryption is two-way, that is a bad thing for passwords, so if encryption were to be used, it would be best to do a hash and encrypt that.
EDIT: If you're really worried about replay attacks, then I just devised a system that should effectively morph the hash such that replay attacks should prove futile:
1) Client hashes the password (MD5 or SHA1 or other good hash)
2) Server sends the client a random 32 bit value
3) Client appends that 32 bit value and the servername (and possibly version) as sent by the server to the first hash that the client just generated.
4) Client sends the hash of (passwordhash+random32bits+servername+serverversion) to the server
5) Server generates a hash of (storedpasswordhash+random32bits+servername+serverversion) and compares that to the one that the client sent
And under this system though, the client would still need to send just plaintext or a simple hash of the password to the server when origionally setting the password.
Under that system I propose, the risk of replay attacks is eliminated provided that the hash used is strong and that the replay attack doesn't happen upon initial player creation. Though this system may sound rather elaborate and complex for crossfire which has nothing like credit card numbers, I think it's simpler than using ssl for this and it being more secure is always good if it doesn't cause too much hassle. I might try coding this hash system some time if nobody has any objections.
In terms of dealing with the update from storing plaintext to storing hashes on windows, creating a new field just for a single (and reletively less used for the server) platform doesn't seem like the best way to do it, though I can't think of any better solution atm.
EDIT: If you're really worried about replay attacks, then I just devised a system that should effectively morph the hash such that replay attacks should prove futile:
1) Client hashes the password (MD5 or SHA1 or other good hash)
2) Server sends the client a random 32 bit value
3) Client appends that 32 bit value and the servername (and possibly version) as sent by the server to the first hash that the client just generated.
4) Client sends the hash of (passwordhash+random32bits+servername+serverversion) to the server
5) Server generates a hash of (storedpasswordhash+random32bits+servername+serverversion) and compares that to the one that the client sent
And under this system though, the client would still need to send just plaintext or a simple hash of the password to the server when origionally setting the password.
Under that system I propose, the risk of replay attacks is eliminated provided that the hash used is strong and that the replay attack doesn't happen upon initial player creation. Though this system may sound rather elaborate and complex for crossfire which has nothing like credit card numbers, I think it's simpler than using ssl for this and it being more secure is always good if it doesn't cause too much hassle. I might try coding this hash system some time if nobody has any objections.
In terms of dealing with the update from storing plaintext to storing hashes on windows, creating a new field just for a single (and reletively less used for the server) platform doesn't seem like the best way to do it, though I can't think of any better solution atm.
mmm, AFAIK the client is open source, so anybody could hack it to make it possible to sent the hash as plaintext password. He could even use an older client which uses plaintext passwords...
hence 'secured' servers should check the client version and only accept connections from updated clients.
hence 'secured' servers should check the client version and only accept connections from updated clients.
Bibendi ergo sum
or rather: sum ergo bibendi
or rather: sum ergo bibendi
I don't see what's wrong with an old client connecting using plaintext passwords. The point of hashing is to protect the user's passwords and I don't see anything wrong with them deciding not to if they don't feel they need to. I think that 'secured' servers should definitaly still be backwards compatible.Mith wrote:hence 'secured' servers should check the client version and only accept connections from updated clients.