26.06.2013, 17:59
Excellently said.
Furthermore the responsibility in password safety is fully on the server operator and fully on the user. If a server requires an e-mail address to register, I get extra cautious right away. Using the same e-mail address(es) for personal, work-related and miscellaneous Internet-doings is often a bad idea to begin with, so make sure to have plenty. Having an e-mail address which does not hint to your real identity is a good idea. Using different passwords for different identities is a must, though.
For servers that store relatively small amounts of data per player (a.k.a no e-mail address is stored), I think a simple Whirlpool hash will do. Clever salting will give whoever tries to crack the hashes a serious headache, should Whirlpool ever become vulnerable to this (I'm not familiar with its current status). But what's more important is that you should look out for vulnerabilities in your own system including those possibly introduced by the specifics of your storage method (never throw invalidated user AND ADMINS input into a SQL query for example).
And another thing is what people often don't consider is when working with your script debugging enabled or if you have queries printed by default, make sure passwords don't get logged. If you do log raw-text passwords, it'll make the life of your dear hacker a lot more easier.
Furthermore the responsibility in password safety is fully on the server operator and fully on the user. If a server requires an e-mail address to register, I get extra cautious right away. Using the same e-mail address(es) for personal, work-related and miscellaneous Internet-doings is often a bad idea to begin with, so make sure to have plenty. Having an e-mail address which does not hint to your real identity is a good idea. Using different passwords for different identities is a must, though.
For servers that store relatively small amounts of data per player (a.k.a no e-mail address is stored), I think a simple Whirlpool hash will do. Clever salting will give whoever tries to crack the hashes a serious headache, should Whirlpool ever become vulnerable to this (I'm not familiar with its current status). But what's more important is that you should look out for vulnerabilities in your own system including those possibly introduced by the specifics of your storage method (never throw invalidated user AND ADMINS input into a SQL query for example).
And another thing is what people often don't consider is when working with your script debugging enabled or if you have queries printed by default, make sure passwords don't get logged. If you do log raw-text passwords, it'll make the life of your dear hacker a lot more easier.