Enhance password security

[Gregoo]

The problem with hashing multiple times is the output format.
Usually MD5 hashes are represented as 32 digits hexadecimal numbers.

If you happen to have a rainbow table with the MD5 hash of all 32 digits hexadecimal numbers (that's hypothetical, we all know people hacking in PT just press a button on a program they didn't make), you'll speed up the "dehashing" of all the successive hashes and it'll come down to cracking the first hash, the one you did on the clear password. Key-stretching is a good way to slow down the attacker but doing it on a static length with a static set of characters is rendered useless as soon as the attacker uses a dictionnary of precomputed hashes.

IMO hashing once is more than enough, especially if you use the SHA-2 family as suggested. You could even use the less power hungry SHA-1 or MD5 seriously, who's going to brute force a PT server ? An MD5 ASCII rainbow table with data as long as 9 characters already costs 1000USD if you don't want to spend years computing it yourself. Just enforce passwords longer than 10 on your registration page and you're set for a couple years .

While I'm at it, I'll add a few things.

First MD5 isn't unsafe in a way that you can magically find the plain text from a hash. By definition a hash is a destructive operation, you can't go back period.

What makes a hash function secure can be defined by how hard it is to generate collisions.
There are 2 types of collisions:
- the weak collision: if you have a hash result K, it's hard to generate a document M such that hash(M) = K
- the strong collision: it's hard to generate two documents M and M' such that hash(M) = hash(M')

If you use MD5 only to store your passwords in an obfuscated way, I think it's still valid. Nobody will find the plain password unless brute forcing for a long time, especially if you enforce a minimum length for your passwords.

However, MD5 is unsafe for signing certificates for instance, because from a valid certificate, with a valid signature (K), you can generate a rogue certificate M, with complex padding and sign it with the signature K. The certificate will appear valid to any client receiving it because hash(M) = K O:

Toodles.

 

[bobsobol]

Thanks Gregoo. I think you're more in the loop on this than I. I just read around these things so I have some idea what the DBMS guys are talking about. tt1:

Just enforce passwords longer than 10 on your registration page and you're set for a couple years .

Yea... earlier in this thread, I was worried about how many characters we can use, considering how limited the allowed character set is. I had asked this question before,

You must be registered to see links

. 24 characters. And a variation between 10 and 24 is quite sufficient for that to add to the complexity as well. (if anyone is reading and thinking of using an Asian character set, remember it's probably 24 bytes, and MBCS will produce more than 1 byte per character)

The limitation of characters usable, I'm fairly certain, is part of the client. The Korean client will accept Korean characters, but not Chinese or Japanese, the Japanese client will accept Japanese characters but not Korean or Chinese... and so on. Latin users seem to be very much handicap by their limited character set, and the restriction on using extended characters. Vormav says that mixed case is ignored too.

If different clients support different ranges of characters, then there should be some way to unlock extended characters in the client... and that will help security very much as well. (typing a plain text password always feels completely wrong to me)

Early Beta clients allowed spaces, hyphens and underscores (at least) for account and character names... but no longer. If the ability was in there, then it should be possible to re-enable it. But in such insecure areas, that's not so much of an issue.

 

[SheenBR]

well, anyone tested my method already to give me feedback?

 

[bobsobol]

Tried to.

When I build the Release solution I get compile failure. Debug build works but VisualStudio Debug is (IMHO) a waste of time, and I can't run the game on my development machine or the Debug DLL on my game machine. So just attaching the DLL makes the game crash. (considering creating a new project and copying your source into it as there seems to be some left over "template" garbage anyway [this is normal] XD)

1>md5.cpp(363): fatal error C1010: unexpected end of file while looking for precompiled header. Did you forget to add '#include "StdAfx.h"' to your source?

It originally winged that it couldn't find the precompiled security.cpp, but that went away after I did a debug build. (I presume it cached the debug and used that as a template)

Personally, I never use Debug builds, or StdAfx. But the project options all seem to be "missing" in VS 2010, so I can't see any sensible way to fix that other than throw out the project and solution and put the source into a new one.

Another "doubt" (concern) which I haven't even got to yet, is that I wouldn't be able to "log in" with this what-ever I did, because I wouldn't know what password to fill in in the SQL database. XD

--- EDIT ---
Okay, got it to build. Have attached my solution files. (only changed a couple of lines in order to dump some pointless empty template source files and do away with StdAfx ... edit2, yea, I also took out the hook files since you clearly aren't using those now, just CFF to patch it in Also attached modified QF1873 + built binary security.dll for it.

Result:-

• Doesn't crash. :
• Doesn't login :/:
• [strike]Doesn't seem to encrypt password in memory... but something must be changed because my server doesn't accept any password I type now. (correct or otherwise)[/strike]

--- Edit4---
Okay. Hoorey! For anyone wondering, the password 123456 is stored as 32decc444c068f8d38d2456 in SQL.

It works just fine Sheen. : Little fiddly to set up, but once working it works great.

 

[tnrh1]

Really nice work but I don't understand what is the point to enhance the login security if you can't even decrypt it right now (Speaking about the korean clients).

 

[bobsobol]

Hackers often steal passwords from the SQL database, then log in to accounts they don't own to take valuable items and generally rape your characters while you're off-line.

If you (as the server Admin) cannot look up a users password on the DB, then neither can a hacker.

Knowing the hash for a password doesn't tell you what the password was, and it would take a very long time (for each account) to find a password which matched that hash.

If the hash was done server side, then even if the packet was in plain text (it must be less complex on our current emulators) then hackers still wouldn't be able to generate the hash locally and we'd see them getting numerous failed logins to accounts trying to brute a password.

 

[tnrh1]

if the packet was in plain text then hackers still wouldn't be able to generate the hash locally

If they capture the plain text why does they ned to generate the hash?they will just login with the password they found.
Then it has to be done client sided I guess?

 

[SheenBR]

Yes, but first to get the plain text you would need to decrypt the packet.

 

[tnrh1]

Would you mind sharing with us what do you know about the login encryption?I found some usefull details in this link but it's not enough.

 

[SheenBR]

Sorry, I dunno : btw, thats not the thread's subject.

 

[bobsobol]

Yea, you could "sniff" a plain text password packet, but you'd (probably) need to have intruded the clients PC to do that, and then you could just read from their keyboard or out of the client memory. (if you are lucky enough to get into an ISP or major backbone router you can pick PT login packets out of the ether, but that's a lot of effort for something so trivial)

Getting into the SQL database (often quite easy) will give you the passwords to every account on the server in one go, not sniffing one or two passwords per machine you infiltrate.

 

[Jash]

I would recommend you to use PBKDF2 through the following steps :
1.1) Create a PBKDF2 instance.
1.2) Set password used for PBKDF2 as some bytes X.
1.3) Set salt used for same PBKDF2 as some bytes Y.
1.4) Run the key derivation function for a sufficiently long number of iterations. Note that the higher the number of iterations, the longer the time it requires to generate the outout (**1 i will explain why longer amounts of time is stronger)
1.5) Make the same key derivation function output a sufficiently high number of bytes (say, 128 bytes?) And store these bytes into database.

Then, to implement this, do as follows:
2.1) Whenever password is registered, set X as input password and Y as username. (Note: Y doesnt have to be the username, just make sure its stored somewhere accessible). Then, run the key derivation function for a desired number of iterations, and then produce and store the desired number of bytes into database.
2.2) Whenever a password is input to be checked, set X as input password and Y as the same Y you used in the step 2.1, number of iterations as the same number in step 2.1 and produce the same number of bytes as in step 2.1. Then, compare these bytes with bytes saved in databse from step 2.1. If all bytes matches, password is correct, else, incorrect.

**1: The time taken to complete step 2.2 depends on the number of iterations used. Lets say i've set a specific number of iterations such that each of step 2.2 require 0.2 seconds. This means that everytime i wanna check a input password it takes 0.2 seconds. Lets say there are 30 possible characters in a password and the length of password ranges from 8 to 12. How long would it take to brute force then? Roughly 3484210010 years if i didnt calculate wrongly. And the best part is, that only works if you are using the exact same number of iterations! So if the cracker doesnt know how many iterarions are used, good luck to him/her.

So to summarize :
3.1) This system lengthens the verification time, for a good cause.
3.2) The number of bytes produced from step 2.1 can be longer and this (im not sure though) reduces collisions.
3.3) The number of iterations adds as another factor that determines the output bytes.
3.4) As a result, it is theoratically possible, but practically impossible to break such a system.

Of course, its only a suggestion. Sorry for posting on an old thread though.

 

[lipinf]

Good idea Sheen, but you can improve password security without create a new Algorithm.

See this article, should help you:

You must be registered to see links

 

[bobsobol]

I changed Sheens released source to UUEncode (or Base64, one or the other and it makes little difference) and thereby fit the whole lot in without error or truncation. But really, anybody could do that, and everyone should go their own way for extra security.

Other than that (and salt, which I still disagree with in hashing) I think this solution is about as good as it gets. (don't forget the need for speed PT can refuse to log you in because it took to long to compare your password in plain, without any encryption and even when you are the only person logging in :scared