how do you hash a string using md5

#21 You're welcome. I'm glad I could help, but most of the credit should go the original author of this resource :)

#22 Of course! However you took the time out to help me out, so you'll get a mention in the two packs that use this resource. Credit where credit is due.

#23 FYI, MD5 is not an encryption algorithm, it's a hashing algorithm. You can calculate the MD5 of a string, but you cannot convert the MD5 back to the original string (unless you have a MD5 dictionary which contains the string - which is one of the weakness of the MD5 algorithm).

#24 updated title to reflect this. This is good for communicating with php md5 when passwords are hashed in a database. Thanks for the info Manoel. True encryption would involve pass phrases/public/private keys.

#25 You could take a peek at my resource on how to integrate openSSL into torque, and use it's high level encryption functions.

I wouldn't really recommend using openSSL for public key generation as it does generate bad RSA keys often.

I'm currently re-doing my auth system in the Crypto++ library, and it's about 80% - 85% done on the C++ side with working public/private key generation.

As mentioned, I'll post it when done, It contains SHA1 and Whirlpool, which are both better than MD5 to start with...

#26 Hey Robert - that sounds really good. Please update me when you're done as I'd like to take a look at this.

#27 If you're wanting to stick with MD5, an "easy" solution is to mimic the route taken by a lot of other services...send down a pass key from the server to client, then the client sends the MD5 of the combined passkey+password back up, this way the password itself is never sent as a hash, and as long as the server dynamically generates the passkey it sends down it's much more secure than STRICTLY MD5ing the password.

#28 Bryan - yes, that would work. Essentially it's just authentication. At some point I'd like to be able to create a system where the pass key changes based on time from the server and giving the key to the client for a set time before expiring.

#29 While the method above is nice and easy, it really isn't all that secure:

http://en.wikipedia.org/wiki/MD5

MD5 is very vulnerable to what is known as a "collision attack", where your hash value can be used to regenerate the original output.

If you want to use this method, feel free to do so, but please use a stronger algorithm (SHA1, SHA256, Whirlpool), the worst thing you can see happen to a game is watching your authentication system break right in front of you.

#30 Agreed. I will apply an algorythm on my pack that I'm creating, and the php scripts are also encrypted. My game is encrypted within a virtual file structure using strong algorithms.

#31 Yes I agree with Robert. MD5 is known to have many collisions compared to the others so it would better to use one of those he listed above.

#32 And pass the salt!

Adding some unique string for each system makes it so a list of pre-generated SHA256 passwords won't work everywhere.

#33 Whilst MD5 has it's issues it is still widely used without issues in many systems, sites and even databases and really is adequate for encrypting passwords for most game scenarios, especially if you're salting and keeping the hashes server side, we're not NASA here and the majority aren't developing the next billion dollar hit!

Sure there are better hashing and encryption algorithms out there but simplicity is key too, don't always need the sledgehammer to crack the nut

#34 While this is true Andy, I still believe you should provide a decent security whenever account details are involved.

Let's take this scenario for example:

I am a hacker, and I want to find out Player A's details, when the game is loader, I fire up a program that read's the memory of said game client, I perform data checkups when I log in, and determine that the game is using MD5. From there, I can back track the hash using multiple login sessions to determine how the salt is being calculated (if one is implied), because it is MD5, I can begin a collision attack on the original hash. Once I back track my own details, I run a packet trace on Player A, to determine his own details.

So, true, you don't need a super powerful auth. system, but you don't want a basic one either, Stick with SHA1/SHA2/Whirlpool, and you should be fine with a system mentioned above with a salt/nonce pair.

#35 Oh I know how you can go about hacking but what you've written is beyond 99.9% of peoples level of comprehension and so even md5 leaves you pretty secure.

If there are payment/card details involved or a game with millions of players I can understand going the extra step to make it even more secure but otherwise I'd still maintain for your average indie game an md5 hash is sufficient.

Overall it boils down to what you consider acceptable risk.

#36 SSL with HTTPS for websites/payment gateways use 128/256 bit encyrption depending on your cert would be enough at domain level. It's if you are passing information that you would like to keep secure without giving the keys to the kingdom in your games that would probably only need MD5, or even low level encryption algorythms.

#37 @Robert - how does OpenSSL work in Torque, using a domain level certificate or key files?

#38 @Robert,

I'm not an expert in security but if the password is sent to the php server via HTTPS request (with openssl & libcurl for example), that might be an enough level of security (as all the commercial site do).
Then you can compare the md5 code on the server side <= to avoid storing clear password in your db.

Now I'm not sure whether sending the password hashed or not add some security or failure in the system.

Does that make sense?

#39 @Elvince -

HTTPS protects against transport level sniffs - hackers enroute to the server.

Sending password hashed lowers exposure to hackers that have established a presence on your machine without compromising the actual program, and is preferable - that is, hackers that are able to inject into the protocol stack on your local computer to get at your password. No gain against direct hacking, or keylogging. This hash can be static (embedded in client) or dynamic, coming from the server - ideally client should request updated hash at every attempt.

Since that hashing must be equal both at client and server (meaning a direct hacker can get at it), its preferable that the stored password has a second level hash/salt/keystrengthening that is performed server side on password updates and comparisons, to frustrate direct hackers that gain access to the DB, as you mention. Preferably, this data is per instance (fixed information such as userkey, or userdata - plus key not available in database!), so that the pattern of 'subscribe, know my own password, use in attack' is not useable.

Also, not using other instance data to protect data means that a direct hacker that gained access to your db, and a subscription, merely would need to update any account's password with the value from the hackers own account's password to gain access to all. At that point, all the encryption in the world of the users data would be pointless.

#40 If you want to keep your accounts secure, a high level hashing function would be sufficient (SHA1, SHA2, Whirlpool).

Just take a peek at my Crypto++ implementation resource, you can really easily implement those algorithms in torque (I provided my SHA1 Example).

However, if you are going to be transmitting passwords between the server and client, you will need to take an additional step. Use a symmetric encryption cipher, such as AES with a tamper proof mode (CBC) to encrypt the client's data before sending it. I would recommend using UTC time as a salt, and hash it with SHA1, that can be your encryption key. you then send up to the server the encrypted string, as well as the UTC time string used, then in PHP, decrypt the string and store that in whatever account storage system you plan on using.

Or, hang on a few days, I'm currently working on the apparent "last" issue in my account system which would be the ultimate to use because you remove the need for a 24/7 account server, as well as provide a very high level of security to accounts, through RSA-1024 keys.

Either way, you don't want to make it easy for a hacker to come in. Make sure your servers are protected using these encryption standards, they are there for a reason.