Last year, Wired reporter Mat Honan was hacked when his Amazon account was compromised. That compromise allowed an attacker to access his Apple ID which gave him access to Mat’s Google account which, in turn, let the attacker into Twitter.

Email, in my opinion, is the gateway to identity theft. It’s bad if your Twitter or website are hacked. You get things like the AP hack. It’s bad, if an attacker gains access to your website and defaces it, or does something else. But as terrible as these things can be (and expensive), identity theft is something that is quite a bit more dangerous.

Here’s a scenario. Somehow, someway I gain access to your Gmail account. It could be that you have a pretty easy password, or you use the same password everywhere, or it can be from some other nefarious means. But I get access to your Gmail.

You might say, “well it’s only email and there’s nothing all that important there.”

But you’d be wrong. If I have access to your email, I have access to everything else. Can’t remember your Amazon password? That’s fine. I can perform a password reset, and gain access by clicking on a password reset link. Then delete it so you never even know it was there. Once into Amazon, using your saved billing information, I can run up your credit card info.

I might even be able to get into your bank, although that’s become significantly more challenging in recent years because of two-factor authentication (which I will get into momentarily).

I could potentially access credit records. Or, depending on the state or locality you are in, your driving and criminal records. And if there is something incriminating in your inbox, I might be able to blackmail you.

Granted, all of this stuff is extremely illegal, but I could still do it if I have access to your email account.

Side Point: Web services that use an email address as the login name are inadvertently dangerous. If I know your email address, I know your login. Then all I have to do is know your password. Whereas not having an email address as a login means I have to figure out BOTH your password AND your username.

Fortunately, Google has two-factor authentication. Amazon, Apple, Microsoft, and Facebook all have two-factor authentication as well. Banks, including Bank of America, all have two-factor authentication.

Two-factor authentication is your saving grace and you need to enable it on every account you have.

What is two-factor authentication?

The easiest way to explain what two-factor authentication is with the phrase, “Something you have, something you know”. You need BOTH things for authentication to happen.

You see this with some biometric systems. Enter a pin (something you know) and scan your thumbprint (something you have).

With banking sites, you enter a password (something you know) and you might identify a unique image (something you have).

You see this with SSH on Linux systems with ssh keys. You provide the server you are logging into with your public key (something you have) and in the “handshake” of authentication, it matches against your private key (something you know).

Google, Facebook and the other services providing two-factor authentication require you to enter your password (something you know) and then they’ll send a pin to your phone (something you have) that you have to also enter in.

It’s a pain in the ass, and certainly I hope technology reduces the friction that two-factor offers to the authentication process, but it’s incredibly important that you have two-factor authentication wherever you can.

Go re-read Mat’s nightmare and you will understand how vastly important that two-factor is. It’s a nightmare. It’s scary. It should be a come to Jesus moment for anyone that operates on the internet.

Hopefully, by enabling this stuff, we can not only stem off a vast amount of hacking attempts, but also become smarter about how we use the internet, protect our privacy and security and, even, in some cases… safety.

It’s a common misconception that if a plugin is deactivated in WordPress, that you are immune from performance or security issues.

On it’s face, this is not true, and you are risking the internet with this mentality!

Take last year’s Timthumb debacle, for instance. Many themes include Timthumb for dynamic resizing of images. Sometimes plugins do. When those themes or plugins are not activated, you are correct in assuming WordPress is not loading them. What you are failing to see is that their existence on the filesystem provides a vector of attack for someone wanting to exploit a system-level exploit.

Not to say Timthumb is insecure. Old versions are. I still don’t like it for other reasons, like performance. Simply using it as an example.

But if you decide to not use a plugin or a theme, delete the damn thing so it’s presence doesn’t even exist. In the case of Timthumb, the security flaw wasn’t a WordPress exploit. It was a “PHP directly interacting with the system” exploit and it would be there anywhere else regardless of CMS. It could exist on a static site.

And it’s not just your site at risk. Fuck your site. What if that flaw in whatever flawed code existed woke up a botnet? Then everyone is at risk. I’m at risk. You and your silly site are at risk. Joe the plumber’s site is at risk. Thoretically.

I am not a hacker. But I understand the information security world. It’s a scary place, unfortunately, to people who have no exposure to it. Yesterday, WordPress 3.0.4 was released as a critical release… and it was. Matt explained the reason for the release in this way:

Version 3.0.4 of WordPress…is a very important update to apply to your sites as soon as possible because it fixes a core security bug in our HTML sanitation library, called KSES. I would rate this release as “critical.”

Simple enough. He goes on to refer to the vulnerability as an XSS vulnerability which caused a bit of angst on Twitter about what that means and if non-technical users should be given more information due to the terminology.

So, as a public service, I give you some basic definitions and concepts of web security and what we mean. These concepts are rightly scary, but the names tend to be scarier to those who don’t understand them.

XSS

XSS means cross site scripting. Cross site scripting attacks are generally attacks that occur because something is injected into a URL or “event” on a site to make the site do something else. Do something else can mean “hijack” a site so all visitors are sent somewhere else, or special HTML is injected into a site (often in the form of hidden links that diminish Google search results for the site, etc). This was the nature of the vulnerability fixed in WordPress yesterday.

XSS attacks are almost always carried out because of JavaScript injection. WordPress does have security API that makes dangerous characters (that is, special characters that make JavaScript do things) and it is encouraged that all plugin and theme developers use these APIs. [Docs]

CSRF

CSRF means Cross Site Request Forgery. With CSRF attacks, browsers (and sometimes other things) are hijacked to “do” things to a website without a user knowing. It’s the proverbial trojan horse where there is an inherent trust from a site that the user/browser is doing something trusted and so attacks riding the coat tails of such trust are given the same trust that the user would also get.

A simple example (does not actually exist) would be that an authenticated user in WordPress with admin privileges is tricked into clicking a link (as the authenticated user) and then admin privileges are transferred to the attacker. We’ve seen this kind of attack on Facebook and Twitter before where DMs or messages are spread across Facebook walls or via Twitter DM).

SQL Injection

SQL Injection is an attack that, without going into the technical details, allows an attacker to send special queries to the database that can alter, modify or even delete a database altogether. You don’t see many of these anymore because most apps are built on frameworks or platforms (like WordPress or Drupal) that have built in routines and APIs that prevent this. In WordPress, there is a prepare() function in the database class which ensures that no SQL injection is possible.

0Day Vulnerabilities

0Day (that is Zero, not “Oh”) is a vulnerability that is exploited before it has been disclosed. Many security researchers work closely with web application developers to alert them to newly discovered vulnerabilities before they are publicly disclosed. They then work with the developers to close the hole before disclosing the vulnerability. The term 0Day comes from the idea that the web app developer knows about the exploit on the 0th day after public disclosure (it hasn’t been disclosed yet).

Denial of Service/(D)DoS

(D)DoS is a (Distributed) Denial of Service attack. These attacks are carried out by flooding a site with traffic/requests to the point where the site can no longer handle the traffic and collapses. If the attack comes from a single source, it’s a DoS but if it comes from more than one, it is a DDoS.

Obviously, there are many aspects of security. We could go way complicated on terminology and concepts, but these are some of the basics you should know when you see something about a vulnerability.

So, it’s happened again. Another vulnerability discovered in WordPress that is now becoming the raging topic around the blogosphere. Is WordPress insecure? Should people move to another platform? If we stomp our feet loud and enough and whine enough, then we can make WordPress look like a ridiculous piece of software that only amateurs should use.

I call bullshit. Here’s why.

The current security paranoia is around an exploit that has already been fixed! That’s right, it was known and fixed two releases ago. The problem is, the people complaining about WordPress’ security are running old software. They didn’t bother to do the responsible thing and keep their blog up to date!

See, WordPress has two different types of releases. Major releases (2.5, 2.6, 2.7, 2.8, etc) provide new features. These releases keep the software innovative, bringing new functionality to bloggers every 4-6 months. Security releases (2.8.1, 2.8.2, 2.8.3, 2.8.4, etc) are arguably more important than major releases because they keep you safe!

Bloggers who ignore these security releases do so at their own risk.

And because of that, when you are hacked, I will charge you an assload of money to fix you up! Believe it.

There is nothing more I want to do on a holiday weekend that also happens to be my birthday weekend, than to fix peoples blogs who didn’t bother to take care of themselves. It’s personal responsibility. Oh, I’ll do it. You won’t like the bill, though.

If you’re using WordPress 2.7+, as said loudmouth blogger was, it’s so simple to keep things up to date with the auto-upgrade button. WordPress even informs you when your version is out of date and provides a direct link to the upgrade page. If you ignore that, it’s not my fault… it’s yours.

For clients hosted on my servers, you are up to date. Why? Because I make sure of it. For the rest of you, do your part, so I don’t have to. Because my part will be making your blog secure, but it will also be sending you a sizable invoice.