New server

[AF]

rehashing with a salt is better than rehashing a hash, I say we do what tobi says and salt using something else stored about the user, though not the username, as that would pose the problem of what happens on a rename?

[lurker]

How is having a salt per account better than using "A907CE83D93C4E92FE023BC312049A90"?

[det]

Salting doesn't stop dictionary attacks, it stops precomputed dictionary attacks, these include rainbow tables. It also means you have to attack each password 1-by-1 when using a dictionary attack. Note that strong passwords (long, random) are not vulnerable to dictionary attacks (unless the hash is broken).

Some algorithms, such as "md5cypt" try to go the CPU-intensive algorithm route by hashing the salt/password with md5 1000 times. This makes a dictionary attack take much longer.

I'm not sure what you mean by "And as far as I know rehashing without a salt could be enough"

SRP is probably the best authentication technology. Using SRP, you can verify your identity using a memorized password, just like the current system. But you never transmit your password to the server. So even the server would need to perform a dictionary attack in order to get your password. This means you could use the same password everywhere without risking 1 compromised server compromising your password everywhere. SRP also verifies that the server is who it says it is. It cant simply say "Your password is correct". It must actually have the secret that you originally established when you set your password.

[lurker]

Basically, do rainbow tables exist for double-round md5? If not, then you're reasonably safe from the simple attacks that can be mounted without them. Unless your attacker has a supercomputer.

[AF]

I would agree that SRP is the way to go but how do we implement this in the server/clients?

[det]

Basically, do rainbow tables exist for double-round md5? If not, then you're reasonably safe from the simple attacks that can be mounted without them. Unless your attacker has a supercomputer.

They might. But even if not, you could easily build a rainbow table for this scheme. Also, this scheme means that if you obtain accounts.txt, you can attack all accounts at once using a dictionary attack, rather than 1-by-1.

[lurker]

Building a rainbow table to use once isn't any faster than going without rainbow tables.
Yes, it lets you attack all passwords at once. Is that factor of improvement significant? And it's useful to check if two accounts have the same password.

[det]

Building a rainbow table to use once isn't any faster than going without rainbow tables.
Yes, it lets you attack all passwords at once. Is that factor of improvement significant? And it's useful to check if two accounts have the same password.

But you can build a rainbow table in advance, whereas you cant start a direct dictionary attack until you have accounts.txt.

[AF]

You forget, those MD5 hashes, aren't hashes of the passwords, they ARE the passwords.

The lobby does the hashing, therefore one could bypass the hashing if they know the hash by simply disabling the hashing on the lobby side.

Currently if I don't hash and put the word 'password' into the login command, 'password' will appear in the accounts.txt file.

I would say even if the lobbies continue to use MD5, we should make the server hash them using something more secure, theres no reason not to use SHA-1 or better

Also if you acquire accounts.txt and then people change their passwords and you re-acquire accounts.txt, you wont have such a long time to wait before you get passwords..