I'm not dead. Happy New Year!

I apologize if this blog is starting to look a little abandoned.  It's not (I promise) I just had to go on hiatus for a few months.

I started a new job in September (Director of Technology for a school district) and it has kept me very busy.  Over the new few months, I'm planning a handful of posts on technical topics plus a few about the realities of trying to run an IT department.

Here are the next three posts that I have in mind:

• Understanding Diffie-Hellman and the Discrete Logarithm Problem
• The Elliptic Curve Discrete Logarithm Problem
• Understanding Dual Elliptic Curve Deterministic Random Bit Generator (Dual EC DRBG)

Dual EC DRBG is the random number generator that the NSA supposedly put a backdoor into.  The first two posts that I'm planning are just to provide background information so that readers can understand the third one.  The third post will explain how Dual EC DRBG actually works and why it's susceptible to key escrow/backdoors.

Career prospects: going to grad school

I've recently been involved in several discussions about whether online schools are really helping their students.  In particular, do they prepare people for the job market?  I can't comment on how this works in other fields, although many are probably similar, but here are my thoughts on IT degrees:

The Oversell

I think that many schools oversell the value of their degrees.  A degree is useful and often required, but it's not a guaranteed ticket to your dream job.  Many schools report that X% of their graduates received a raise or promotion after graduating, but these are rarely automatic.  If you're considering going back to school, the burden is on you to figure out what a degree can do for you and how it fits into your career plan.

What is your narrative?

I've run into a few people who either have no work experience or who are in entry level jobs and have completed graduate degrees in IT.  I think education is a good thing and there's nothing inherently wrong with earning a graduate degree, but you have to think about how it fits into your personal narrative.

Attending an online for-profit school

A few years ago, I decided to go back to school to finish a bachelor's degree.  The school I ultimately chose was Capella University, an online for-profit college.  Online universities, and for-profits in particular, have a poor reputation, but I decided to attend anyway.  Here's my take on for-profit universities and why I plan to return to Capella to finish a master's degree.

Availability

I live in a small town.  When I started going back to school, there were no night-time or degree completion programs that I could take advantage of.  I would have loved to go back to school full-time and attend a well-regarded university, but I support a family and can't afford to relocate and quit work in order to go to school.  I needed a degree program that I could complete while working full-time.

Threat scenarios

When analyzing security features, we often look at them in black and white terms: either they can be broken or they can't.  DES is crackable but as far as we know AES is not so we recommend AES.  This is useful when we're making general recommendations because we don't know what threats everyone is going to be concerned about so it's safer to assume that we'll always need to protect against a skilled, well-funded attacker.  In many cases, however, that assumption is not true.

At Passwords 13, Steve Thomas, a.k.a. sc00bzT, gave a presentation about building a cheap hardware security module (HSM) to store and protect passwords.  During the talk, someone mentioned on IRC that what he developed wasn't a true HSM since the hardware was not tamper resistant.  While that is a valid concern, others correctly pointed out that it may not matter depending on your threat scenario.

Since it has no physical protection, Thomas's HSM is vulnerable to hardware tampering.  It should not be used in situations where that is a valid concern.  If you're worried about foreign governments bribing your employees or about a rogue employee (e.g. at a bank) being able to sell those credentials, then you should consider laying out the cash to get a tamper-resistant HSM.  But, if you're mostly worried about outsiders using SQL injection to dump your password hashes, this solution is perfect.  It's cheap and it solves the problem.

Passwords 13 - Next Week

I haven't posted anything lately, but I'm heading to Passwords '13 in Las Vegas next week and hope to come back with some new thoughts and ideas worth posting about.  In the mean time, here's a picture of my dog.

Basics: Avoiding SQL Injection

SQL injection is a pretty big deal.  The attack is easy to carry out, the vulnerabilities are prevalent and the payoff is potentially large.  Many of the password breaches reported over the last year or two are known or thought to have been carried out via SQL injection. 

SQL injection attacks allow attackers to execute arbitrary queries or commands against a database.  Developers introduce the vulnerabilities into their code when they concatenate or substitute user input into the elements of a SQL query.  In the following Python example, the program will accept any input as the "user_id" variable (returned as a part of login_data) and tack it onto the end of a string that is subsequently executed as a sql query:  

login_data = web.input()
query_string = "SELECT * FROM USERS WHERE ID = '%s'" %

login_data.user_id

cursor.execute(query_string)

Lessons from the S.C. breach

In October, the South Carolina Department of Revenue discovered that it had been breached and contacted Mandiant to assist in the investigation and response.  All told, millions of social security numbers and hundreds of thousands of bank/credit card numbers had been stolen.

In November, Mandiant published their findings.  This is exciting.  All we usually get is a news article lacking in technical detail.  This we can actually learn from.

My goal in this blog post is to explore what, in hindsight, the S.C. Department of Revenue could or should have done better. Please read the Mandiant report before you move on.

Lessons from the CCSF debacle

In January 2012, some fairly sensational news stories were published about a major data breach at City College of San Francisco.  According to the early reports, tens of thousands of student records may have been compromised.  Even more interesting, the reports said that some systems may have been infected for over a decade and that there were connections to China and Russia.  While the reports were interesting, they were short on details and I hoped to eventually read more after the school had some time to sort things out.

In May, the CTO of CCSF was suspended at least in part for his reaction to the breach.  The Guardsman, CCSF's newspaper, published a series of articles that described controversy within CCSF over the handling of the breach, the CTO's management and accusations that the breach was a false alarm.

The CTO's tenure sounds like it was a disaster.  It's also full of lessons for IT and security managers.

Wrapping up 2012

I've been really busy lately so I haven't blogged much.  Things are coming together pretty well here at the end of 2012.  Here's what's happening with me.

This summer, I won a free trip to Fishnet Security's iSWAT training event in Las Vegas through The Ethical Hacker Network.  I decided to take the CISSP review course.  I've been meaning to take the CISSP exam for a while, but it's been hard to find time to study since I'm working and in school full-time.  There were only three of us in class, but it worked out really well.  Instead of sitting in rows and listening to the instructor drone on for hours, we sat around a conference table and actually discussed things as we went over them.  Many of the discussions went well past what we needed for the exam, but I enjoyed the hell out of it.  It's not often that I get to spend an entire day talking about security.

My only complaint is that Fishnet was supposed to reimburse me for the CISSP exam (it was part of the package).  I was told a month ago that my reimbursement was being processed, but I haven't heard back and I haven't received anything.

Password Expiration

One common bit of advice with respect to security is to require frequent password changes.  This "best practice" has persisted for decades despite some prominent criticism.  But, is password expiration actually helpful or not?

Are there benefits?

Password expiration has a negligible effect on limiting or preventing malicious behavior.  The ability to steal passwords often implies privileged access to your systems or network.  If the attacker has administrator rights, access to the password database or the ability to sniff traffic on your network, he can install a backdoor or continuously steal passwords in order to avoid the expiration window.  That’s assuming he even needs continued access to accomplish his goal.  If the attacker only needs short-term access, which is often the case, password expiration is irrelevant.

A note on password math

The number of possible passwords with a character set of size C and a password length x is C^x.  For instance, with mixed case alphanumeric passwords we have a character set that has 62 possible characters: 26 lower case letters, 26 upper case letters and 10 numbers (26 + 26 + 10 = 62).  If a password is 8 characters long, there are 62⁸ = 62 ∙ 62 ∙ 62 ∙ 62 ∙ 62 ∙ 62 ∙ 62 ∙ 62 possible combinations.

If there are P possible passwords and we can guess G passwords per second, then it will take us P ÷ G seconds to guess all possible passwords.  Since there are 86,400 seconds in a day, the number of days that it will take us is P ÷ (G ∙ 86,400) and the number of years is P ÷ (G ∙ 86,400 ∙ 365).

The number of guesses that an attacker can make per second depends mostly on the password hashing algorithm.  For a fast algorithm like MD5, a reasonable cracking speed is several billion guesses per second.  For bcrypt or scrypt, a reasonable speed might be from a few hundred to a few thousand guesses per second. 

Example:

Number of possible 8 character mixed-case alphanumeric passwords = 62⁸ = 218,340,105,584,896

Seconds to guess all possible passwords (1 billion per second) = 62⁸ ÷ 1,000,000,000 = 218,340 seconds.

Days to guess all possible passwords = 218,340 ÷  86400 = 2.523 days.

Years to guess all possible = 2.523 ÷ 365 = .007 years