Photo by joyosity

Hashes, Encryption, Salt, oh my. What does it all mean? What should you be using? How do you implement them in WX? Read on my dear visitor, read on….

No not that kind of hash. Hashing is a one way translation, meaning that even if you know the algorithm and salt phrase used to generate a hash, you still can not covert it back to the original string. Encryption, on the other hand, is a two way function, if you know the algorithm used you can convert it back to the original string. If you are storing documents or information that you will need to use again, encryption is the correct method. However all you want to do with a password is verify that the user has entered the correct password. So if you store the Hash of a password, then when the use tries to log in, all you need to do is compare the Hash of the password they type in to the Hash stored in your database.

I know that sounds the same as encryption, but if you read close, the difference comes into play if you have a security breach. Say you become the target of your friendly neighbor hood hacker and they manage to get a portion of you user list including their passwords. You say no problem they are encrypted, but guess what will a few hundred dollars worth of GPUs a good hacker will have that encryption reversed in a few hours and have your users actual passwords. Still no problem you say, you will reset everyone’s passwords and all will be fine. Yes that will take care of your site, but unfortunately most people use one password for everything, so now that hacker takes your users emails, and passwords and uses them to get into other sites such as their email, banks, etc. And when the lawyers track it all back to you, its going to be a really bad day.

Had you stored those passwords as Hashes then the hacker would not have been able to unencrypt them and get the actual password. But you are still not completely out of the woods. It is conceivable for two different strings to generate the same Hash, this is know as a collision. So that same hacker, if he spends a few thousand dollars on GPUs and what is called a rainbow table,  will be able to hammer away until it comes up with a second string that generated the same Hash and now he is off to the races once more.

So how about a little Salt for your Hash? To combat collisions and rainbow tables you use Salt, which is a phrase that is used to “Salt” the Hashing algorithm. If you are using a Salt phrase then the hacker can not generate a match collision because the Hash will be different on your system than on his. It goes without saying that you need to be careful with how you store your Salt phrase so that the hacker can’t get a hold of that as well. At the end of the day all we can do is make it as difficult a process as possible and try to stay one step ahead of the hackers.

What this got to do with WX?

Fortunately the good folks at pcSoft have made it easier for you to use Hashes than it will ever be to understand them. There is a set of function specifically for using Hashes. So lets take a look at the “Create Account” code from theTaxCure.com.

HReset(Member)
Member.EmailAddress = EDT_Email
Member.Password = HashString(HA_HMAC_SHA_512,EDT_Password,"*Salt*") 
HAdd(Member)

I told you it was easy! HReset is just clearing the record so we start with a new record. When creating an account, I am only asking for two pieces of information, their email address and their password. So the email gets assigned and then the magic happens with the HashString function. This function will generate a Hash for the supplied string. There are a number of different algorithms that you can chose from. This code is using a 512K SHA Hash.  There are two forms of the function, be sure to use the constants that include HMAC which use the Salt phrase as part of the Hash.  The 512K SHA algorithm will always generated a 64 character string, so Password is defined as a 64 character string in the database.

And as you can see the Hash is not something readable.

Checking the User’s Log in.

Verifying the users log in is just as simple. Here is the code behind the Log in button of theTaxCure.com

HReadSeekFirst(Member,EmailAddress,EDT_Email,hLockNo)
IF HFound(Member) = True AND HashCheckString(HA_HMAC_SHA_512,EDT_Password,Member.Password,"*Salt*")
   PageDisplay(PAGE_Welcome)
ELSE
   STC_LoginNotFound..Visible = True
END

The first line retrieve the Member record by Email address, if HFound() returns a false then its a bad log in. Otherwise the HashCheckString function is used. This function is very similar to the HashString function. You pass it the string to compare, the Hash, and the Salt phrase. It returns a True if the string generates the same Hash.

And that is all there is to it. User validation without ever storing the password. One side effect is that you will have to implement a method to allow the user to reset their password if they forget it, because you could tell them what their password is even if you wanted to, which of course is the point! I will be covering that in a future article.

So you may be wondering after reading this, why the heck there is a new story everyday about sites getting hacked and passwords leaked. First remember not everyone has easy to use tools like WebDev and we should thank our lucky stars everyday that we do. But sadly the truth is many of them are from lax to down right lazy programming and procedures, from not protecting the salt phrase, to using encryption instead of a Hash, to believe it or not storing the passwords in plain text! I hope this article encouraged you to review your security procedures and make any changes required, please don’t be the next lead story on twitter!

[suffusion-the-author display=’author’]

[suffusion-the-author display=’description’]

 

• WINDEV