WUSS 2012 Long Beach Paper

I have posted my paper (An Introduction to Git Version Control...) at my sas-resources.com site:
http://www.sas-resources.com/recipes/an-introduction-to-git-version-control-for-sas-programmers

Thanks to everyone at WUSS who attended, everyone who asked questions and everyone who has given feedback! -s

I Git Busy

While I was on vacation, I got a friendly email reminding me that my WUSS 2012 paper was due July 30th.  Yikes!  I had exactly one week to get home and write it.  My mother calls it procrastinating.  I prefer to think of it as Lazy Loading.

So I was a bit busy last week.

But I finished it.  And I think it's good.  At least, I hope it's good.

It is an Introduction to Git Version Control for SAS Programmers.

You see, back in March I wrote this blog post asking about the version control you use while developing SAS programs:
http://datasteps.blogspot.com/2012/03/version-control.html

Based on the _underwhelming_ response, I assumed most SAS programmers were like me and didn't use a version control system because version control is an enterprise thing and I was doing programming on my own or in small teams.  That was until I discovered Git.  Now version control is mine.  It belongs to me and is part of my workflow.  I'm enthusiastic about how it's helped me as a coder.  Hopefully my presentation and paper will share that enthusiasm with you.

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.