doBoard

do… Web Application Development and Security

Archive for November, 2007

What Is Security, Really?

Monday, November 12th, 2007

You get a different answer each time depending on who you listen to:

“It’s simple – patches, firewalls, anti-virus and the latest security products.”

The product vendors would like you to believe that.

“Preventing and fixing known security holes like XSS, SQL injection and CSRF.”

A good web developer might say that.

“Efficiently detecting and blocking hacking attempts.”

Spoken like someone who has been in the trenches. Whack-a-mole at Internet speed.

“Complying with security rules and requirements.”

Smells like bureaucrats. Hopefully the thousands (!) of requirements aren’t constantly changing, poorly defined, contradictory, or ill-conceived…

With more variations than we can count, there has to be a better way to get a handle on security. So what’s the bottom line?

Security is keeping bad events to a minimum.

That’s my simplest, broadest and most fundamental definition of security. Everything else derives one way or another from that basic goal.

So what does it mean to keep “bad events” to a minimum? What are these bad things?

It’s bad to lose control of sensitive information, like credit card numbers or passwords, allowing it to go where harm can result.

It’s bad to lose integrity of your information and your systems, allowing data to be altered, systems to be broken into, transactions to be falsified or erased, etc.

It’s bad for services to be unreliable or unavailable to those who legitimately are trying to use them.

As the news headlines remind us, there’s a growing community of people who are actively trying to make those bad things happen, with a wide variety of increasingly powerful motivations, tools and knowledge.

So what to do about this?

First, identify what you have that needs protection.

That might be sensitive customer data, confidential business information, computer-based services that are vital to business operations, and so forth. Understand what it is, where it resides, and how it’s processed and transmitted by your systems.

Second, understand the risks and damage that can result from problems with protection.

Where are your systems vulnerable? How much damage would be caused by leaking medical records? Tampering with financials? System takedown? How likely is it that such things will happen? What will that mean in terms of money?

Third, decide what protective measures to take.

You might want people to prove their identity before they can access private information on your system. You might want security audits of your financial systems. You might want to test your systems to ensure they’re not easily taken down. There’s a large menu of security controls including the things mentioned at the beginning of this post. And now you’re in a position to make intelligent choices balancing risks vs costs and setting priorities.

Fourth, implement your chosen security controls.

Have qualified people do this correctly. Clear enough tasks off their plates so they can focus on getting this done. Ensure they have the organizational support to make reasonable progress.

Fifth, continue to re-evaluate and update your security over time as changes happen.

This may require management attention, periodic reviews and gap analysis, and one or more workers who have security management as their primary responsibility. Ideally everyone in the organization will take ownership for the security aspects of what they do.

This approach will help ensure that the right things are protected to the appropriate degree, avoiding excess and preventing or resolving deficiencies in an efficient way. By taking a step back, and thinking of security in terms of the fundamentals, it becomes much clearer how to proceed and where to focus your efforts.

By doing this you’ll be well on your way toward keeping bad events to a minimum.

DC PHP Conference 2007 – Security Highlights

Monday, November 12th, 2007

This year’s conference had a fairly heavy dose of security.

Chris Shiflett’s keynote, “Security 2.0″, included nice discussions of XSS (cross-site scripting) and CSRF (cross-site request forgery) with an AJAX scenario.

Ed Finkler presented on the PHPSecInfo project, a tool to scan the PHP environment for security issues, and Inspekt, a PHP library to protect applications from the potentially tainted contents of superglobals.

Eli White presented “Help, My Website Has Been Hacked! Now What?” and covered how to prepare for and respond to hacking incidents, based on his experiences at Digg.

Damien Seguy presented on MySQL Security.

While not primarily security-related, Keith Casey included some discussion about security while presenting “Designing REST Web Services”.

Q & A: Risk of Duplicates When Using MD5?

Monday, November 12th, 2007

—–

Update April 27th, 2013 – WARNING – if your intention is to encrypt (hash) passwords, this isn’t the code you’re looking for. Because of massive advances in attacker capabilities the code in the original post is obsolete for that purpose. It’s better to use the built-in password hashing functions or an alternative made with appropriate techniques and expert review.

—–

Yes, MD5 can produce hash collisions in a very small percentage of cases. For many uses this shouldn’t be significant, but for security there are better options.

I prefer the SHA-2 series, referred to as SHA-224/256/384/512, because the algorithms are strong and widely supported.

If you need the hashes to be un-guessable then I’d recommend hashing more than just the input data. A well accepted strategy is to include a secret key in the computation, resulting in a keyed-Hash Message Authentication Code (HMAC), and another useful technique is to concatenate a “salt”, which may or may not be secret, with the input.

PHP versions >= 5.1.2 have the hash_hmac() and hash() functions:

$hmac = hash_hmac('sha256', $data, $key); // hex string output

$hmac = base64_encode(hash_hmac('sha256', $data, $key, TRUE)); // force binary output before encoding

$hash = hash('sha256', $data . $salt);

PHP versions < 5.3 have the mhash() function:

$hmac = base64_encode(mhash(MHASH_SHA256, $data, $key)); // mhash produces binary output

$hash = bin2hex(mhash(MHASH_SHA256, $data . $salt));

There’s a nice table of algorithms and their properties on Wikipedia.

Original email discussion was on the DC PHP Developers Group list.

DC PHP Conference 2007

Tuesday, November 6th, 2007

I’m going to the DC PHP Conference 2007 in Washington, DC, November 7-9. The keynote will be “Security 2.0″ by Chris Shiflett. Looking forward to seeing the PHP security guru in action, and I’ll probably run into several members of the DC PHP Developers Group.

The New doBoard

Friday, November 2nd, 2007

Despite all efforts to cling to the past, the times have changed. So I’ve retired the old website that served well for six years.

The new doBoard will participate in the web technology and security communities. Expect to see content and discussion about web development and web application security, plus the occasional foray into the broader technology, security, and business fields.