Wordpress 2.6.2 and Automatic Updating
Wordpress version 2.6.2 is out, fixing a few security holes. If you haven’t already, you should upgrade your installation as soon as possible.
I think I’ve mentioned it here before, but if you’re not running the Automatic Upgrade plugin, stop and add it to the top of your to-do list. True to it’s name, the plugin does all the work of updating your Wordpress install with just a series of clicks. This is especially useful for users who may be afraid of uploading a bunch of files or perhaps don’t have FTP access to their blog.
From a technical perspective, the plugin does a lot of nice things on the system side. First, it gives you zip files containing your content and database backups. It’s more a just-in-case thing, but nice to have. Then, it puts your blog into a maintenance mode. That way, people aren’t leaving comments or trying to log in during the upgrade. It will also de-activate your plugins, again, to reduce the possible errors that may pop up. The plugin then gets new files from Wordpress directly, updates your install, turns everything back on and asks you to clean up the cruft leftover.
Upgrading today took 3 minutes, which is a small price to pay to make sure your install is safe and secure.
If you enjoyed this post, please subscribe to my RSS feed!
Exterminating Form Spam
In 2005, we launched a web application for our campus that allows our users, especially those with no technical knowledge, to produce web forms.
Why did we do this? Mostly, we did it because everyone always wanted a form and my group had to build them all. We had been using the ancient FormMail.pl but each receipient had to be approved and each form hand-coded with required fields. I wanted users to be able to create forms, have the results emailed to them as well as saved in a database, and manage those forms, all without having to get the web team involved.
I know, web forms aren’t sexy. Not in the least, but they’re a critical part of how people communicate with us on our sites. Since it’s launch, FormBuilder (original name, I know) has really made an impact across campus. Forms are all uniform in terms of style and layout. This was a huge problem, as everyone, myself included, was building forms differently. Offices on campus can create a form in just a few minutes, email the address or post it on the web and start getting responses in minutes. These offices have seem a dramatic improvement in student responses and program attendance.
So FormBuilder’s been chugging along with no problems, until recently when it’s been getting hammered with spam. Not all forms are getting hit, just a lucky few. They are receving, seriously, hundreds of submissions a day. Luckily, it’s mostly gibberish and not pr0n spam, but still, it’s annoying for my users and it’s using my resources up. Not cool.
I wrestled for a long time with how to stop the spam. I thought about adding some kind of question that would be appended to each form, such as “What is 2+2,” or something to that effect. I thought about using code like Bad Behavior, but I don’t know if that would be easily defeated.
In the end, I decided to implement the dreaded CAPTCHA.
I looked at code to generate my own and do all the processing on my server. I struggled with getting them to be readable and getting them to fit in with the look and feel of our forms. After running into so many problems, I decided to use the reCAPTCHA service.
reCaptcha was developed by Carnegie Mellon University, and, in addition to reducing spam, the project helps digitize books from the Internet Archive. In my eyes, that’s a win-win. ReCaptcha allows users to reload the images if they are tough to read, and they also allow for users to hear a series of numbers that they enter instead of words. Listen to the numbers sometime, it’s a little creepy.
ReCaptcha is being used on a great deal of large websites, including Twitter, StumbleUpon and Ticketmaster, to name but a few. I’m sure you’ve seen the red reCaptcha boxes as you’ve surfed the web.
Implementing reCaptcha was painless. They offer libraries in a variety of languages and detailed instructions. I used the PHP code and it’s worked perfectly. What really drew me to the service is the fact that you can really customize the look and feel of the captcha to match your color scheme.
Here’s a standard reCaptcha box:
Here’s an example from one of our FormBuilder powered forms:
Earlier this week, we rolled this out on all FormBuilder-powered forms. It was smooth and other then a call to our computing help desk by a user who feared we’d been hacked, we haven’t heard any issues from people filling out forms or from our campus users.
Thus far, the spamming has stopped and only legitimate form entries are getting through. Of course, it will only be a matter of time until hackers beat ReCaptcha, and the whole cat and mouse game will start again.
If you enjoyed this post, please subscribe to my RSS feed!
Season Your Passwords with some Salt
Let’s say you’re building a big new web app at your institution. One of the parts of this application will be storing usernames and passwords. There are a ton of ways to do this, but today I want to share with you one way that I do things, in the hopes of making my logins as secure as possible. For our examples today, we’ll be using PHP.
Before I get going too far, I should mention that when I say storing passwords, what we’re really doing is storing a hash of the user’s password. When we authenticate a user, we run the password they supply through whatever algorithm we’re using to encrypt and hash their input and we compare the result to what we’re storing in our database.
That being said, when storing passwords for your app, you have a many options. You could skip all security and store your users’ passwords in plain text in MySQL. Bad idea. You could use MySQL’s default password functionality. This is okay, but you could do things better.
For the rest of this post, let’s create a password variable, $pass. For all the examples, let’s set the value of $pass as “highedwebtech1″.
Let’s look at what’s generated when we pass the $pass variable through MD5.
echo md5($pass);
That gives us the following hash:
4fc86b20556f29a3291b5fb296189eff
That’s not a terrible way to store a password, but there’s been research for the last couple of years that its possible to create MD5 collisions - where you generate lists and lists of MD5 hashes and look for matches. For example, this site will look up your MD5 hashes and check for collisions.
Well, we could use SHA1 to encode the password. Let’s run our $pass variable through SHA1:
echo sha1($pass);
That gives this:
1f046ee5bdacf0842729674034e5d1cf8c3ce512
Getting better. But - SHA1’s been broken as well. The chances of your user accounts being brute-forced by someone running SHA1 collisions is very minute, but let’s keep searching for something better.
Let’s do some crazy hashing and mashing. Let’s look at PHP’s crypt function.
crypt() will return an encrypted string using the standard Unix DES-based encryption algorithm or alternative algorithms that may be available on the system.
If we run the following code:
echo crypt($pass);
We get the following:
12sO.2eqklceI
crypt() also allows you to add a salt. Wikipedia describes a salt thusly: “a salt comprises random bits that are used as one of the inputs to a key derivation function.” This basically means we can specify some characters that will become part of our encryption scheme.
Let’s create a $salt variable. We’ll give $salt a value of, for now, “yummysalt”.
Let’s run crypt() again but this time we’ll specify a specific salt. The system I’m running this on in these examples is using standard DES as it’s encryption.
echo crypt($pass,$salt);
This returns:
yupJSdhPX0e66
Standard DES puts the first 2 characters of the salt at the beginning of the hash of the password. If we use “yummysalt” as our salt (footnote - DES only uses the first 2 characters, we could have just made our salt “yu”), every time we run our password through crypt we will get the same value. The number of characters in your salt can depend on your system settings, including values in PHP and your server software.
Specifying a salt isn’t a bad thing to do, but you’ve got to now store that salt somewhere in your code. If your system is compromised, and with your salt, cracking passwords may be a little easier for your user passwords to be cracked.
If you’re sensing a theme here, you’d be right. DES is also susceptible to cracking, even when using a salt.
So, what’s a way to do it thats secure and has little chance of getting cracked? There are a lot of different ways to answer that question, but here’s some ideas I had, along with some help from a friend, who’s a security professional at a major research institution.
He recommends using something like the following, which is based on the username and password responses we receive from the user.
$username = "user1";
$password = "highedwebtech1";
echo sha1($username.$password);
In the code above, we’re creating a hash from a concatenation of the username and the password they enter. But, Mike, you say, a few paragraphs earlier you said SHA1 wasn’t the best choice. In this case though, we’re not hashing just the password. We’re hashing an entirely new value, in this case, user1highedwebtech1. That would be much more difficult to crack, especially using a brute-force attack. Here’s the hash value we get back from this function:
033e1ce0e67fce92ddf5cdf437d15b9967f4b307
It’s long, and difficult to crack. When it comes time for a user to log in, checking against what they enter is easy. Just put the two values together, run it through SHA1 and then compare that to the value we originally stored in the database.
It should also go without saying that you should never email a user’s password to them. Either send them a replacement, temporary password or make them reset it altogether by emailing them a link with a hashed value they need to reproduce. But that’s a whole other post.
Want to learn more about doing this stuff in PHP? I’d recommend reading about about the mcrypt module. It offers a great deal of additional functionality.
Happy hashing!
What tips or tricks do you use when it comes to handling passwords? I’d like to learn how you deal with this issue.
If you enjoyed this post, please subscribe to my RSS feed!
