- Joined
- May 26, 2007
- Messages
- 5,545
- Reaction score
- 1,315
Hey Ron, LTNS. :
So the number of possible passwords is relatively small.
This is a major downfall in any password encryption in todays' fast CPU environment.
As for Client side or Server Side... I say Server side for the same reason as Ron. The server may be leaked with the database, but the client is certainly already leaked.
One solution to the problem of giving away the encryption may be a Private / Public key system. ie, the client combines a known server public key with it's private key to send. The server needs to use it's private key with the clients public key. So neither end has the ability to decrypt what it encrypted, only what was encrypted by the other. (see PGP, or even RSA)
That was my point. The PT client and protocol already enforces that users cannot type any character which isn't a-z, A-Z, 0-9. (unless it's a Korean character, but most of our keyboards can't produce those in game) and that the password not be more than 7 characters.As long as you enforce strict password rules (ex; requiring MixEDcaSe and $yMb0Ls) then the chances your hashed passwords will be guessed are very slim, even if a hacker obtains your password salt.
So the number of possible passwords is relatively small.
This is a major downfall in any password encryption in todays' fast CPU environment.
As for Client side or Server Side... I say Server side for the same reason as Ron. The server may be leaked with the database, but the client is certainly already leaked.
One solution to the problem of giving away the encryption may be a Private / Public key system. ie, the client combines a known server public key with it's private key to send. The server needs to use it's private key with the clients public key. So neither end has the ability to decrypt what it encrypted, only what was encrypted by the other. (see PGP, or even RSA)