Page 1 of 2

tmwserv Password Encryption Patch

Posted: 22 Mar 2008, 19:59
by leeor_net
I don't know if the dev's have considered using an encryption algorithim instead of sending and storing passwords in plain text so I took the liberty of creating a patch that addresses just that.
tmw_md5.zip
(9.55 KiB) Downloaded 121 times

Re: tmwserv Password Encryption Patch

Posted: 22 Mar 2008, 21:08
by Jaxad0127
This is also being discussed in Mantis 92. This is being looked at the for the new server (doing it under the current server would be troublesome).

Re: tmwserv Password Encryption Patch

Posted: 22 Mar 2008, 21:40
by trapdoor
MD5 is not even close to being sufficient.

I would suggest using SHA-1 (used in SSL) or maybe even SHA-2 (SHA-224, SHA-256, SHA-384, SHA-512).

--
trapdoor

Re: tmwserv Password Encryption Patch

Posted: 22 Mar 2008, 23:46
by leeor_net
This is a patch for the new tmwserve (SVN revision 3997, client and server trunk). I don't dare touch eathena.

As for the MD5 security, it's, at the very least, a start. It's certainly a lot better than the plain-text transmission and storage that's currently implemented. And yes, I'm aware that I could use a randomly generated sha-1 salt which I could then attach to the MD5 checksum in some way. I've seen a variety of ways to do this.

I was hoping that this patch would be useful in some way but if the dev's are already working on something this may be a waste of time.

Re: tmwserv Password Encryption Patch

Posted: 24 Mar 2008, 17:18
by Crush
leeor_net wrote:And yes, I'm aware that I could use a randomly generated sha-1 salt which I could then attach to the MD5 checksum in some way.
I think you misunderstood something. SHA-1 is an alternative for MD5, not a supplement.

Re: tmwserv Password Encryption Patch

Posted: 24 Mar 2008, 17:23
by leeor_net
I know.

A common way of salting passwords that I've seen is to get an MD5 hash from the password, randomly generate a salt and get an sha-1 hash from the salt. Then it's just a matter of tacking each one together.

I have a few ideas I'm going to persue including using the whirlpool hashing functions so I'll get those working whenever I have a bit of time to actually do it.

Re: tmwserv Password Encryption Patch

Posted: 24 Mar 2008, 17:29
by Crush
When you have seen it a lot then maybe there are already precalculated rainbow tables for this method.

It is also not really a critical improvement. When you want to brute force a password which is salted by its own hash you just need twice as much time. Not really a critical security improvement.

When you use a salt to avert rainbow table attacks it should be something that has nothing to do with the password. My idea was to use the username as a salt. I can imagine rainbow tables for common passwords but not for common password- and username combinations.

Re: tmwserv Password Encryption Patch

Posted: 26 Mar 2008, 22:17
by Rotonen
Also SHA-1 has been compromised lately to provide a significantly smaller subset of guesses for the bruteforce attempt.

From decent modern-ish encryption standards, I'd go for some SHA-2 variant, blowfish/twofish or AES. Favoring blowfish out of these for the lightness, though.

Re: tmwserv Password Encryption Patch

Posted: 26 Mar 2008, 23:45
by Crush
Blowfish, Twofish and AES are symmetric key encryption algorithmns, not hash algorithmns. That's something completely different (symmetric key encryption is supposed to be decryptable with the same key used for encryption while hash functions include loss of information and thus can not be reversed).

The SHA2 family is currently the state of the art regarding hash functions.

Re: tmwserv Password Encryption Patch

Posted: 27 Mar 2008, 00:39
by Rotonen
This will soon offtopic into "hashing the data versus encrypting the data". :roll:

http://searchsqlserver.techtarget.com/t ... 99,00.html

Re: tmwserv Password Encryption Patch

Posted: 27 Mar 2008, 12:43
by Crush
I don't think so. The only confidential data in our database are the passwords and regarding passwords hashing is more intelligent than encrypting.

When you can hack our server to steal the encrypted passwords you can also steal our encryption key and decrypt the database.

When passwords are hashed, on the other hand, there is no way to get the clear text passwords from the database, not even by a rogue administrator or sophisticated social engineering.

Re: tmwserv Password Encryption Patch

Posted: 27 Mar 2008, 12:56
by Rotonen
Can still think of grid configurations in which it could come useful, but I guess the implementation is not our headache.

Re: tmwserv Password Encryption Patch

Posted: 27 Mar 2008, 13:24
by Jaxad0127
Where is the hashing going to occur, client, server, or both?
Crush wrote:I don't think so. The only confidential data in our database are the passwords and regarding passwords hashing is more intelligent than encrypting.

When you can hack our server to steal the encrypted passwords you can also steal our encryption key and decrypt the database.
If it's just the client, hacking the database would give them every account. Using two different algorithms, one for the client and one for the server, would be an idea.

Re: tmwserv Password Encryption Patch

Posted: 27 Mar 2008, 22:45
by leeor_net
My implementation is exclusively through the Client as sending any plain-text data over the internet is a security nightmare. Doing all of the hashing/encryption client side makes it entirely the responsibility of the client.

The problem at this point comes in creating a secure hashing scheme that is not vulnerable to what are called rainbow attacks. Personally I hate that people have actually developed these tables -- at the same time, they are a blessing in disguise because they show just how vulnerable hashing functions are, particularly MD5 (havn't done any research into vulnerabilities and rainbow attacks with other hashes).

Anyway, there are various ways to defeat these tables but they are so effective because so many people use really simple, easy to remember passwords.

Passwords and various methods of securing them is a discussion that could easily fill several books and an entire college semester. For the purposes of TMW and my project, basic security is sufficient. My current implementation does indeed need work though but for now the basic MD5 hash is good enough for testing purposes.

Went on a bit of tangent, didn't I? :oops:

Re: tmwserv Password Encryption Patch

Posted: 28 Mar 2008, 01:58
by Crush
Rainbow tables aren't hard to beat.

You just have to append a salt string to the password which is unique for your application before hashing and a rainbow table has to be created especially for your application (and unless your application is very widely used this is not worth doing).

When you also have some mechanism which allows to add a different salt to each password rainbow tables become completely unuseable.

For TMW we could create the password hash (client-sided) by concatenating Password + Username + Server hostname and hashing then. This would also make sure that the server admin can't use your hash to log in on a different server where you have the same username and password. The only problem is that when the server changes its hostname all passwords become invalid.