Security Best Practices

by Dave Sweeton

Before we begin, I need to mention a caveat. These are my recommendations and current understanding of best practices, but I want to be clear that I’m not a security expert. What I am is a developer, which means that I’m on the front lines of actually implementing security solutions. I’m always trying to stay on top of evolving threats and best practices so that I’m implementing security barriers instead of security holes! If you have better ideas or find flaws with mine, please share. It’s the only way we as developers will get better at security—and let’s face it we have a pretty bad track record.

STORING PASSWORDS IN DATABASES

A lot of security breaches you hear about involve loss of data, like financial information, but what’s even worse are breaches where clear text passwords are exposed. Sure this is bad for the site where the passwords originated, but it’s also a chain reaction of bad since most users use the same passwords amongst many sites. So if a cracker gets the usernames and passwords from CuteKittens.com, then suddenly they also have complete logins for FaceBook, Amazon.com, email systems, etc. Sure I blame the users for bad password practices, but this kind of thing is easy for developers to avoid.

It boils down to this: Never store users’ password! It’s not enough to only encrypt the passwords. You need to hash them.

ENCRYPTION VERSUS HASHING

What exactly is the difference? Both encryption and hash algorithms turn secrets into obscured bytes of data. Encrypted data can be decrypted with the right key, but there is no way to reverse a hash. A hash is a one-way algorithm. A hash algorithm also produces wildly different output with even small changes to the inputs. So “Hello” might hash to 0x261A, but “hello” might hash to 0x9FC0. MD5 is one example of a hash algorithm, though it has some flaws. Generally the SHA-1 family of algorithms is recommended instead.

PLEASE PASS THE SALT

So I’ve hashed my passwords and I’m now storing the output of the hash in my database instead of the plain text. I’m all good, right? Unfortunately not.

A hash cannot be reversed, but it can be broken. The way it’s broken is pretty simple. You pre-compute the hashes for every possible password ahead of time. Then you take the hash value, look it up in your table and viola, you have the plain text. This giant lookup, called a “Rainbow Table,” used to be beyond the capabilities of computers, both due to the length of time needed to calculate hashes and the massive storage requirements of the resulting output. You could hash tens of thousands of passwords, but it would take a week and fill up your hard drive. Now, with huge storage and massively parallel computing (including the math capabilities of high-end video cards), rainbow tables are easy to compute. Or you could be lazy and just download a multi-gigabyte rainbow table from the Internet. (I’m not kidding, I googled and found freerainbowtables.com.)

As simple as rainbow tables are, there’s an equally simple way to render them moot; add salt to the hash. A salt is a suitably long chunk of random bytes that are appended to the password before it’s hashed. Because the password has extra data, it will now hash to a different value. This effectively means that each random salt value will need its own giga-sized rainbow table.

NOW SLOW THINGS DOWN

At this point, with a salted and hashed password you are pretty safe, but there’s one additional step you can take to make your passwords harder to crack: add time. Instead of hashing once, run the hash output (plus the original salt) through your hash algorithm multiple times. This adds computational overhead, which means that any cracker trying to match hashes in your database will have to spend more time. I’d time your algorithm and then loop so that it takes from 0.5 seconds up to 1 to 2 seconds. Note that this will slow down your users’ logins as well, so don’t go too crazy.

SUMMARY

• Take the plain text password.

• Generate random salt bytes. Use a quality random number generator, and get a significant number of bytes (e.g. 50).
• Combine password and salt (depending on your language this may entail converting the password string to a byte array and then appending the salt byte array).
• Run them through your hash algorithm. Choose a good one—SHA-2 or SHA-3 for example.
• Take the hash output bytes, append the salt bytes and run it through your hash algorithm. Repeat this step for a lengthy number of iterations (e.g. 50,000).
• Save the resulting output AND the salt bytes to your database. If you don’t want to deal with binary data, you can base64 encode them and store as strings.

This advice only pertains to the security of the passwords stored in your database. It doesn’t prevent crackers from gaining access to your systems. It just means that breaches have fewer negative impacts. Hashed passwords don’t alleviate the need for security in other areas.

Software Teams: Assessing a Problem

by John W. Stout

Sometimes software teams fail to understand and effectively articulate a difficult user-level problem and also fail to properly assess it to arrive at a workable solution. Solutions arrived at without an assessment can miss the target and backfire with consequences to the business.

How can this occur?

1. Not carrying out an up-to-date and accurate assessment of the external business climate, market players and user response to the team’s software product(s).

2. Not looking outward at evolving best practices and then assessing the team’s own processes, tools and technologies used to produce its products.
3. Treating an assessment as a subjective internal discussion. An assessment based on internal opinions, however well-intended, is usually myopic.
4. Engaging in internal battles without explicitly stating criteria that would be used to measure the viability or success of a solution. In my experience, this is a biggee.

In the past three months I have been in three separate consultations about the establishment of criteria for assessment of software quality, project teams and departments. These assessments were driven by financial and other business needs, and they required bringing team members together who often had diverse viewpoints.

For these reasons, Stout guides its software product clients through an assessment process. An assessment, often in the form of a project “discovery period,” does not need to take a great deal of time, but does have to be thorough enough to expose any “gotchas.” Efficiency is inherent by knowing in advance the right questions to ask (see 12 questions top technical managers ask at http://bit.ly/StoutITSC). A completed assessment has to be done, before one starts to create a solution document.

By the way, an assessment would include if the team even has the right people in place to implement an effective solution.

To skip the assessment is why projects fail to meet their objectives, with the resulting disappointed users. An assessment done well steers you past the cliff and strengthens your leadership position in your company or industry.