PRISON OF MIRRORS We're not here because we're free. We're here because we're not free.

Category Archives: Security

Why You Should Never Sanitize or Change User-Supplied Passwords

May 17, 2013

I recently wrote this story on a forum I frequent, but I thought I’d share it here as well and include some additional details.

A little more than a month ago at my work we were dealing with a website that was constantly being hacked. The website itself ran just fine; the hack was unnoticeable to majority of users. The attackers were injecting hidden code into the website that was only appearing to bots like the Google bot. When people googled the website the listing on Google would show ads for other things (usually undesirable) rather than the website’s description or any intended content. Needless to say the client did not want this.

The client’s website had been a victim of hacking several times in the past over the course of several months. They were running a very outdated version of Joomla! that we determined to be the most likely way the attackers were getting in. Due to the amount of customization to the website and the age of it, we recommended rebuilding the site in WordPress or dropping the CMS capability altogether and just create a static website. The client declined to do either to save money. They continued to get hacked though and we continued to clean it up as best we could.

Eventually someone noticed the undesirable text on the Google (and other search engines) listings and alerted the client, who subsequently alerted us and asked us to fix it. We eventually convinced them to rebuild the website in WordPress; however, the attacks continued. At this point the client was getting increasingly annoyed with us thinking we were incompetent at what we did. To be clear: we’re not a security company. We make websites. This doesn’t mean we don’t know stuff, but we’re not experts at cleaning infections. There are some basic things that pretty much any programmer or techie would know to do or look for but we don’t specialize in this kind of work. We already went through the normal motions of changing passwords, folder/file permissions, etc.

The client pretty much threatened to drop us. This was our oldest client, and was very important to us in both monetary terms but also on a relationship basis. We wanted to make them happy and fix their problem but as just mentioned, this isn’t what we do. In any case, we stopped everything and decided to take a “scorched Earth” approach.

We deleted everything from their FTP and we systematically went through our code (line by line in many cases) looking for anything that was suspicious and scrutinized it with extreme prejudice. Once we were satisfied that our code had no infections we were ready to reupload the files.

During this process I was also going through changing all the passwords to their various systems, including the control panel password. We have a password scheme but I made the call that it was not sufficient in this case and decided to use KeePass’ password generation tool to generate 40 character passwords comprised of random letters, numbers, and symbols; these passwords were stored securely so there was no worry of having to remember them or even typing them in.

I changed the control panel password and it came back with a success message telling me it was changed. Great. I recorded the new password and went to log back in. The log in failed. I tried again. And again. I tried the old password as well. No dice. I tried on a different browser, a different computer. I tried everything. I couldn’t get back in.

We were in a critical moment as well because the client declared 5pm as the deadline to have everything back up and working again or they were no longer going to do business with us. It was 4:45pm. Myself and my boss were very stressed and almost freaking out. We contacted the hosting company but they were unable to do much for us. We weren’t “on the account” and therefore there wasn’t anything they could do except send out the password to the email addresses that were already on the account. One of the emails was the person we were dealing with directly (who had set the deadline).

That was the last person we wanted to interact with at this point, but my boss got on the phone and talked to him. He twisted some facts to take some of the heat off us but managed to get the password email forwarded to us. I took a look at the password and it was exactly what I generated. I copied and pasted it into the log in form and voila – I was in. But I was very perplexed because it was the same password! In any case, due to the time crunch I finished my work and we got everything settled with literally minutes to spare.

I went back to take a look at the password because I knew something was wrong. After putting both the generated password and the password from the retrieval email into Notepad I noticed the one from the retrieval email was only 39 characters. It was shorter. I studied both of them carefully to see what was missing and the password from the retrieval email was missing a backslash!

The control panel form accepted the password, but it stripped the backslash from it without ever telling me! There were no indications of any restrictions on passwords, and without giving any kind of feedback to the me, I was completely oblivious to what they had done. I told my boss about what happened because I wanted to make it clear that this wasn’t my mistake, and that this is very frowned upon when it comes to security practices.

We were both quite surprised because we have used the host quite a bit in the past and are still using them for several current projects as well and we have never had a problem at all. They seemed like they really knew what they were doing. I guess not. I sent a strongly worded email to them letting them know that this was poor practice and the trouble it caused me. I never heard from them.

Stripping random characters isn’t the only offence. I’ve seen people apply trim(), addslashes(), strip_tags(), strtoupper(), etc. to passwords. These are all bad, and most of all, completely unnecessary.

Just an additional tidbit of information: WordPress doesn’t accept backslashes in their users’ passwords either, but at least they display a message to tell you!

Regardless though, there’s no reason to restrict a user’s password. Not like this, anyway. Passwords are just strings that should be getting fed directly into some kind of hashing algorithm or other security function. By the time they reach something like a SQL query, they should no longer resemble anything a human would be able to understand, or anything that would be able to mess with a query. Period. Don’t do this. This is bad. Even if you reject the password and tell the user.

Posted in Security

An Introduction to Password Hashing and Storage

July 19, 2012

With all the recent password leaks and other security-related blunders, I decided to talk about password hashing and explain it so non-computer savvy people can understand. Hopefully people will gain a better understanding about storing passwords and how to create good ones.

Plain Text

You might have heard the term “plain text” when hearing about passwords or one of the recent leaks (or the mega-Sony leak of last year). This is sometimes referred to as clear text. So what does this mean? It simply means the password is stored so any person can read it. Like so:

Passw0rd

The dangers of this should be pretty obvious: anyone who has access to the password knows what it is, and considering that in a database an user name — or even worse, an email address — is usually accompanying the password, the dangers are even more paramount (especially if you’re one of those people who reuse passwords. Hint: don’t do that). And if a database is leaked… game over. So how do we prevent someone who has access to the password from knowing what it is? This where hashing comes in.

Hashing

Hashing is a way of obfuscating text. It can be any text, but it’s commonly used for passwords. It’s a one-way algorithm that literally transforms the password into a fixed-length string of random letters and numbers (in hexadecimal, meaning each “digit” goes from 0 to 15, which is represented by 0 to 9, and a to f). As just mentioned, this algorithm is one-way, so there’s no way to reverse the hash. Passwords at the bare minimum should be stored as hashed values in the database and the plain text versions should never be stored under any circumstances.

There are many different hashing algorithms. Some are better than others. The two most common ones are MD5 and SHA-1. Neither of these algorithms are considered secure anymore but they are still widely used. Each hashing algorithm is one-way and always produces a fixed-length string of characters, known as a string. MD5 outputs a 32 character string and SHA-1 outputs a 40 character string.

Let’s take a look at the MD5 output for Passw0rd, the example used above:

d41e98d1eafa6d6011d3a70f1a5b92f0

As one can see, there’s no real way to tell what password this is just by looking at it. It is important to note that each algorithm always produces the same output for the same input. In other words, every time one enters Passw0rd, the result will always be what’s above. This is how websites and other applications are able to authenticate users. If the user enters in an incorrect password, the hashed output will be different than what’s in the database and therefore will not be authenticated.

Another important thing to note is that input that is sequential or closely related will result in a drastically different output. Here’s a quick example using SHA-1:

Passw0rd is ebfc7910077770c8340f63cd2dca2ac1f120444f in SHA-1
passw0rd is 7c6a61c68ef8b9b6b061b28c348bc1ed7921cb53 in SHA-1

As you can see, changing just the first letter from uppercase to lowercase has a drastic effect on the output, and the two do not look similar at all. This helps make the algorithms stronger.

Predictable Output

While the output isn’t predictable to humans, it certainly is to computers. In an effort to “crack” hashed passwords people have created “dictionaries” and what’s known as rainbow tables to cover as many hash possibilities as possible. These dictionaries can number in the billions, and you can bet that the common passwords people choose on a regular basis are in there. There are rainbow tables that cover all combinations of upper and lowercase letters, numbers, and symbols up to eight characters for the MD5 algorithm. This is why it’s so important not to use some simple password like J@son123.

This suddenly doesn’t sound very secure. How do we mitigate the effects of precomputed hash dictionaries and rainbow tables? We use what’s known as a salt.

Salting

Salting is adding an additional string to the password, and then hashing the new string. Salts are usually appended to the front or end of the password. There are a few caveats about salts, though. The same salt should never be used more than once and should always be unique, changing every time the user changes his password. The salt should also be long and random, probably the same length as the hash algorithm’s output. The longer and more random, the stronger it is. I personally like to use a combination of PHP’s mt_rand() function (without arguments), which generates a random number between 0 and 2147483647, and the current date and time, formatted in a specific way, accurate to the second.

Adding a salt has two major strengths: 1) it makes the password much harder to guess, and a good salt would render hash dictionaries and rainbow tables useless, forcing an attacker to use brute-force techniques which could take centuries or longer, and 2) if two users are using the same password, the hashes that are stored in the database will look completely different. Since it’s expected that a lot of common passwords are reused, many unsalted hashes in a large database would be the same. An attacker would only have to crack it once, though, for all of the same password to be revealed. Adding a salt makes this impossible.

Simply put, adding a salt is just adding a string that’s so long, so ridiculously random, that it’s improbable to appear in any hash dictionary or rainbow table. Take a look at the following two passwords. Which do you think is more likely to appear in someone’s list?

Passw0rd
d32c00e3c7935e76da471babeda400c902903ee0Passw0rd

And what if three people in the database are all using the password Passw0rd?

The SHA-1 hash values of the following passwords

4e4940aa6f9df8148aafa6ed458d583091b6c162Passw0rd
79564deffc86af62e08f90d5cc432880357f5773Passw0rd
b5c4f7b8919242ed4316e302deb50748eb235812Passw0rd

Result in:

2a22aeaf4e0a6f10f475effa1256feff3b39b328
23da0509aaebb5b0e5911f9e1a5fb624f3bc6b0a
7e130f3cbb36cb86cd3caef24c554605c363012f

It’s not obvious that all three of those users are using the same password. Salting is essential to password security and every website should use it. Salts are usually stored in the database, and while this may seem detrimental, keep in mind that for an attacker to break the hash, they would have to apply the salt to every single entry in their dictionary, which would take an enormous amount of time — per password! Also don’t forget that the attacker has no way of knowing (unless they are able to get a hold of the application’s source code, which has happened before) whether the salt is appended to the front, end, or something else entirely before being hashed. Even if they did know, the amount of time required to break even a single password becomes infeasible.

Conclusion

I hope password hashing and storage has been explained simply enough for everyone to understand, and I hope after reading this post, you reevaluate your passwords. One other thing to keep in mind: hashing algorithms can handle any kind of string input, and do not require limitations; websites that impose arbitrary restrictions on your passwords should set off red flags because it’s an indicator that they’re storing the passwords in plain text. Think twice about the passwords you use for these websites and services.

Posted in Security

The Price of Security

July 15, 2012

There has been quite a few data breaches in the last month or so. LinkedIn, eHarmony, and Last.fm were all breached in early June and had user credentials leaked. Just a few days ago Yahoo!, Billabong, Formspring, Phandroid, and Nvidia were all breached as well with user information including passwords leaked. These breaches vary in severity; some of these sites were storing their passwords in plain-text (why are companies still doing this? Haven’t we learned from the Sony debacle?) and others were hashed. Storing passwords in plain-text is the biggest (and simplest to avoid) security mistake a company can make. Hashing the passwords is definitely better, but they’re not infallible as there are sites out there with massive hash dictionaries.

I don’t have much else to say about these breaches except that if you have an account with one of the above websites, I suggest you change your password immediately, as well as any other account where you may be using the same user name/email address and password combination (you’re not doing that, though, right?).

I’m no expert when it comes to security, but I like to think about it a lot, especially when I read about these high-profile breaches. I also like to think I’ve learned quite a bit over my years of programming that I could make a pretty secure web application. It may not be impenetrable, but it would be enough to repel opportunists. And that’s really what it’s about, isn’t it? Preventing “crimes of opportunity”?

I liken web and computer security in general to the security of a home, and what the price of it is. The price of security is convenience. Imagine your home with little to no security: you leave your doors unlocked or open, or heck, you may not even have a door! Anyone could come and go as they please. It’s very insecure but also very convenient. You never have to worry about forgetting your keys, or losing them, or locking yourself out. It’s a dream! Ever come home and your arms are full of groceries and you’re struggling to get your keys and open your front door? No need for that, just walk in!

Of course, no one lives like that, so we put some security on our homes: we have doors with locks, we have garage doors with keypads, we have locked windows. Some homes even have security alarms or security monitoring. Others may even own a dog or two (though I hope they have the dog for companionship rather than for security).

Pretty standard security. But houses get broken into all the time. It’s a very common occurrence. Imagine upping your home’s security. Imagine every room in your home had a locked door. An intruder could break in but he would be very limited on what he could do. Your house is very secure. On the flip side though it’s incredibly inconvenient. Every time you want to go to another room you have to bring a key. What if you lose a key? Uh oh.

So instead we choose to have a certain level of security because too much of it is too inconvenient. The same applies to web applications. It applies to both the user and the developer. A huge amount of forethought has to go into designing, testing, debugging, and fixing a secure system (as well as maintaining, and hopefully documenting). Users have to be able to use the system easily enough so they don’t become frustrated and leave. Imagine having to enter your user name and password every time you wanted to access a page of a site, or having different passwords for different areas. It would be secure because an attacker would need to know the specific password to the specific area he wants to access, or try to get them all. But it would be a huge pain to actually use.

In the end we have to decide what is an acceptable amount of inconvenience. I’m not sure there’s a definite answer to that, but we should strive to find the middle ground between too much security and too much convenience.

Posted in Security

Pwn2Own 2012

March 12, 2012

CanSecWest’s annual Pwn2Own hacking competition took place March 7 – 9 this year. It went by relatively quiet this time around. Nevertheless, some interesting developments occurred.

Google Chrome

Google pulled itself out as a sponsor of the event, citing rule changes; full disclosure was not required by the exploiters. Instead Google hosted their own “pwn” competition named Pwnium. Chrome was hacked three times. First by the security firm VUPEN, who didn’t reveal their exploit and decided instead to keep it for their customers. VUPEN used two zero-day flaws to complete their exploit. Second by Sergey Glazunov, a Russian university student with two zero-day vulnerabilities. Glazunov’s exploit didn’t break out of the sandbox, though; it avoided it altogether. The third exploit was completed by a teenager who goes by the handle of “Pinkie Pie”; he used three zero-day vulnerabilities to accomplish his exploit and break out of the sandbox.

For the exploits that were revealed, Google released a patch within 24 hours.

Internet Explorer

Internet Explorer 9 was hacked by VUPEN using two zero-day vulnerabilities. The vulnerabilities exist in all versions of Internet Explorer from 6 all the way to the newest platform preview for IE 10 on the Windows 8 Consumer Preview. VUPEN is only revealing one of the vulnerabilities and keeping the other private for their customers.

Mozilla Firefox

Firefox was hacked by the team of Willem Pinckaers and Vincenzo Iozzo, who demonstrated a zero-day flaw. A patch has not been issued yet.

Safari

Unlike previous years, no one attempted zero-day exploits on Apple’s Safari browser. Some are attributing the low turnout this year to the change of rules of the event.

Posted in Browsers, Security

How to Properly Secure Your Wireless Network

February 10, 2012

Wireless networks are ubiquitous technology; they’re everywhere. Anyone who’s ever lived in a dorm room, apartment building, or a tightly-packed neighbourhood will know how popular they are. And yet, most people do not secure them properly. They’re left wide open for anyone with a wireless device (which used to be just laptops, but now pretty much any smartphone or tablet is capable) to connect to.

Why?

Some may ask, “Why should I protect my wireless network?”, and the answer is very simple: because whoever connects to your network can do anything on the Internet that they can do somewhere else. What you’re mostly trying to prevent is some kind of illegal activity, and I don’t just mean file sharing. These malicious individuals are essentially using your identity to commit crimes on the Internet. Don’t be a victim to this.

In addition, if they’re able to connect to your network then they have access to all the devices on your network, including your PC and especially to any shared folders you might have. They can also use your Internet connection to waste your bandwidth, which might result in you receiving a much larger Internet bill. Lastly, since they’re on your network they can get to your router and if they get in there, they have 100% full control over your network and can block you from accessing the Internet.

Minimum

Your wireless network’s access point is the router. This is the device that all other devices on your network connect to, so this is what you need to protect. The absolute, bare minimum you need to do is to change the default administrator password on your router. Step-by-step instructions on how to do that is beyond the scope of this post, but there are dozens of tutorials online plus your router should come with a manual describing the procedure. Choose a strong password.

Note: this does not prevent anyone from accessing your network. It does however prevent someone from taking control of it.

The Basics

The first step is to choose a security protocol. WPA2 is what’s recommended. It has replaced WPA. Do not use WEP. Ever. It is not secure and can be cracked relatively easily. A simple Google search will reveal how easy this is. Again, choose a strong password; the security is useless if the password is easy to guess. Do not use the network’s name, your/siblings’ names, birthdays, etc. Instead use a combination of uppercase and lowercase letters, numbers, and symbols. This is crucial. I want to stress that.

More Advanced Stuff

There are some more advanced methods to protecting yourself if you’re a little more paranoid or have very sensitive information flowing through your network. The next thing you can do is implement MAC address filtering. This limits the access to your network to individual devices, so even if they had your password, if they’re not on the allowed list, the person cannot connect. Note however that this isn’t bulletproof since MAC addresses can be spoofed (they would have to know what to spoof it to, though).

In addition to this you can stop your SSID (the name of your network) from broadcasting. In other words, the person would have to know the name of your network in order to even attempt to connect; in their list of wireless networks yours would be absent and they would have to add yours manually. Note that this method as well is not bulletproof.

Lastly, you can physically block the wireless signal using metal mesh (such as the material used for screen doors). Mold it into the appropriate shape and voila, you’re now blocking your signal from reaching say, the street, or your neighbour’s house. You may have to use more than one layer but it does the trick. Now the perpetrator has to be inside your house to get onto your network, which at that point your wireless network is the least of your concerns.

Protect Yourself

Protect yourself from becoming a victim of Internet crime, bandwidth theft, or simply being locked out from your own network or Internet connection. Take a few minutes to look into how you can secure your wireless network and you’ll thank yourself.

Posted in Networking, Security