Google SAS Search

Add to Google

Tuesday, June 12, 2012

Rainbow Table Salt

DISCLAIMER: I am not an expert at cryptology.  But I generally understand the industry best practices and have implemented this stuff on several sites.  That said, read on at your own risk :)


There's been a lot of talk about LinkedIN passwords getting stolen.  It's an interesting read and it made me think it would make for a good blog post.

If you read the link above you will see them referring to hashed passwords. First of all, nobody should be storing passwords in a data base as clear text.  Never, ever, nope.  You want to store the password after it's been hashed with a one-way hashing algorithm.  One-way just means it's computationally impractical on todays computers to go the reverse direction from hashed string back to password.


So now that you've got your hashed password, you can rest assured that your passwords are super-safe, right?  Well, almost.  You are still vulnerable to a dictionary attack.  A dictionary attack is where an attacker tries to guess your password using a set of likely candidates.

<rant>
Strict password requirements create bad passwords.
You know those password requirements like:
Must be at least 8 characters long and contain
at least one upper-case character
at least one punctuation character (_., etc
at least one number.

It _seems_ like those requirements should force people to create nice secure passwords that are hard to guess. But the reality is exactly opposite.
Those requirements practically force you to use a date.  I would bet good money that at least a quarter of you reading this has a favorite date password to satisfy those requirements.  Let's see, I was born in april of 1974. I can capitalize April put a comma in there and voila: April,1974. Requirements met!
Dictionaries invariably start with a bunch of variations of [month] [punctuation] [2 or 4 digit number].  Secure password fail.
</rant>

Ok, back to the discussion.  Your passwords are stored in your db as hashed strings.  So all an attacker has to do is pre-compute their dictionary and compare those hashes to the hashes they grabbed out of your db using an SQL injection (another topic for another time).  Yes, they would have to know which hashing algorithm you used, but there aren't too many in everyday use (MD5and SHA1 spring to mind).  And these pre-hashed tables exist.  They are called Rainbow Tables.
I have no idea why?

What would be better is to add something to the password before we hash it. Then the attacker can't use a pre-computed Rainbow Table.  The "something you add to a password before you hash it" is called salt. So now they would have to have stolen the salt along with the hashed passwords. And then create a Rainbow Table from scratch.

This is all sounding much better.  Add salt to the password and then hash it.  Got it?  Good.

Actually, there's one more little step we can take to make our passwords even more secure.  We can make sure the salt is unique for each password. This is usually accomplished using a unique identifier for the user (usually the primary key) and a simple random number to create the salt.  As long as the unique salts are stored securely, you can feel pretty confident that you've got things locked down.

I do this type of thing quite often in other languages, but I've neveractually had the need to implement it in SAS.  I will write a subsequent post that has some example SAS code to make the ideas a little more concrete.

Wednesday, June 06, 2012

Comparing Macro Values

I was working on some SAS macro code today that I hadn't touched in quite a while. Actually, I haven't even been working on much SAS code for a while. So it was nice to get my mind back to the language I am most familiar with. I spent a good thirty minutes staring at a problem that was so simple that it should not have taken me long to figure it out.

A funny thing happens when you spend your development time hopping from language to language. You learn lots of techniques and ways of thinking, but you lose out on some of the day-to-day habits that coding in one language can instill in you.

I had a macro variable named &PATH that I was checking to see if it had a value of NULL. This path variable contained the fully-qualified name of a file (all the directory info). But I needed to assign it a default value (NULL) and check if anything was truly assigned.

%if &path ne NULL %then %do.....

I kept getting ERROR: A character operand was found in the %EVAL function of %IF condition where a numeric operand is required. The condition was: &path ne NULL

What the hell? That's about as straightforward a line of code as you could write! Well, since I've been hacking away on everything but SAS this last month, I immediately start questioning the language. Can I not use a mnemonic operator? Does it have to be "not ="?Is it something else in the code that's throwing it off? Is NULL a SAS keyword or something? Am I going senile? Blah blah blah.

And then it hit me. &PATH is a variable that's resolving to a value during execution. The value contains special characters (/var/path/more/path/etc) that are being evaluated badly. I needed to escape the value (or on SAS Macro parlance: quote the value) to hide it from the macro processor.

EDIT: Oops, I even used the wrong quoting function (sigh).

%if %nrstr(&name) ne NULL ...

Should be:
%if %quote(&name) ne NULL ...

So the SAS Macro day-to-day habit that I temporarily forgot: Do not trust the values of macro variables during execution. Unless you explicitly want the value to be processed, always wrap it with an appropriate quoting function.

Maybe my 30 minute loss will be your 30 minute gain. :)