Cory Hardman's Blog

Usable Security

Cory Hardman — Wed, 21 Jul 2010 06:30:55 +0000

There has been a big push over the last few years to develop what has been coined as “usable security”. Things like drawing patterns on Android devices instead of typing in a 4 digit pin or identifying particular things in an image instead of typing a password have been developed. The biggest problem with these usable security mechanisms is that they often take longer to use than the alternatives.

Imagine if you had to take your mouse and click at 10 particular spots in an image every time you wanted to unlock your screen at work. Doing this would take several more seconds at every sign on and would add up quickly. Often for systems that are used often keying in a password is still the fastest method.

Well Microsoft has developed a new solution. Instead of having password requirements that are visible to the user, like minimum length, they want to let users use anything as a password. Even simple passwords like “love” would be accepted. However there is a catch, only a small number of users will be allowed to use a particular password.

Complex password requirements were introduced to combat spraying and braying attacks. A spray and bray attack is when an attacker tries to use one particular password on a large number of accounts. This way bypassing lock out procedures. This solution by Microsoft will fix this by only allowing a small number of accounts to be compromised and thus reduce the benefits of the spray and pray attack while keeping passwords simple and easy to remember.

Code Reviews, the Lost Art

Cory Hardman — Fri, 16 Jul 2010 04:45:25 +0000

Nearly every software development shop worth its salt has some form of what is known as a code review and nearly every developer dislikes them. Most matured developers tend to like the idea of code reviews but given the choice, on there next commit they would likely opt to not send their code for code review. The reason why is simple, code reviews can delay the forward progress of the software and they take time. When you have other developers needing access to the library you just wrote it is hard to say we need to take a few hours to a week of our time to look over my code. I think we should be able to make code reviews better and into something everyone wants to do.

After a code review I often finding myself wondering was what was found worth my time and the reviewers time? Most of the code reviews that I have been apart of have had minor suggestions or more commonly code standards compliance problems. When you rummage through several hundred or a few thousand lines of code during a code review and all that is found is that you have a few extra blank lines or should change the name of a variable, it does seem like a bit of a wast.

I’m not saying that we should not care about those extra lines or any code standard for that matter. I’m a big fan of code standards, I think they help in the readability of code. I’m saying that there is a cost to code reviews, we have to weigh those costs against the rewards. When a reviewer only finds a few compliance issues, things that could be fixed by anyone that is reading through the code, it was not worth the time the reviewer spent reviewing.

So how do we make code reviews worth everyone’s time? Simple, we change the intent of a code review back to what the actual intent was. Code reviews are put into place to find bugs. Bugs that would show up to an end user or other developers that are trying to use the code.

You may say, “well Cory that is what every code reviewer is doing, they are looking for bugs.” However that is not true, sure they are looking for obvious bugs like unassigned variables being referenced, but they are not looking for deep bugs. One of the most common bugs comes from input validation, and yet it is a bug that is often over looked in code reviews. This is because it is often difficult to tell exactly where input to a function is coming from and how much it should be trusted. Detecting multi-level bugs requires a reviewer to see how the multiple levels interact and the path of the code in correct and error states. This kind of review takes a lot of time and drastically increases the complexity of a code review. The sharp increase is due to the fact that we are moving a code review from a mostly passive practice to a very active process.

Obviously code reviews could not detect all bugs and there will be times when a code review will not find any bugs. From this active process of a code review you get a new found level of confidence. Bug counts will be decrease and actual development should increase. This confidence is how a code review pay for themselves.

OpenVPN in Windows 7

Cory Hardman — Fri, 09 Jul 2010 06:13:39 +0000

I often need to work remotely from work, luckily my work has a VPN server that allows me to get access to the companies internal resources. I have been using OpenVPN in Windows XP for a long time to do this, through the use of OpenVPN GUI. Well when I got a new laptop it came with Windows 7 installed. So one of the first things I did was set up my development environment which required me to get into some of the file shares inside of my companies network. I thought it wouldn’t be a problem at all to do, I installed OpenVPN GUI and just copied over my configuration and key files. When I went to connect I got quite an interesting error:

Thu Jul 08 23:05:33 2010 ROUTE: route addition failed using CreateIpForwardEntry: One or more arguments are not correct. [if_index=16]

It turns out to be very simple to fix. In Windows 7 and I believe in Vista you need to do a few extra steps to get OpenVPN GUI to work with Windows 7. First you need to go C:\Program Files\OpenVPN\Bin and make sure openvpn-gui.exe is always started as Administrator (in the compatibility menu of the file properties). Then you will need to edit your configuration file and add two lines after the line that describes your cipher:

route-method exe

route-delay 2

That should do it. Let me know if you have any questions.

Nexus One Support in Ubuntu 10.04

Cory Hardman — Wed, 07 Jul 2010 01:16:09 +0000

I recently purchased the Nexus One from Google. It is quite an amazing phone and I’ve been really happy with it. I’ve taken interest in developing for the Android platform now that I have one. Luckily Google has provided a very good resource for Android app development at http://developer.android.com/.

Today I was working on allowing me to upload my applications onto my Nexus One so that I could test the software on a real device. Well I ran into an issue after following Google’s tutorial on how to do it located here. I run Ubuntu 10.04 on my main development machine and so I followed the instructs for how to do it for Linux. Well when I got to the end of the tutorial when it tells you to test your the setup with the following command:

adb devices

I got the following output:

List of devices attached

???????????? no permissions

It turns out that Google’s instructions have not been updated so reflect how to get the Nexus One to work under Linux. Well after a bit of research I came across the following blog post that explained it. Basically the list of USB Vendor IDs does not have listed the proper value for the Nexus One. I had selected to use HTC’s Vendor ID (“0bb4″) being that the Nexus One is actually produced by HTC, however that is incorrect. Instead you need to use the Vendor ID of “18d1″. So the following line should be in /etc/udev/rules.d/51-android.rules

SUBSYSTEM==”usb”, SYSFS{idVendor}==”18d1″, MODE=”0666″

NOTE: Be sure not to capitalize the D in 18d1, doing this will cause this solution not to work.

Now that you have added that line to the file, you will simply need to restart udev. With the Nexus One unplugged from your system run this command:

sudo service udev reload

Now you can plug in your Nexus One and run:

adb devices

You should see something like this:

List of devices attached

???????????????? device

I hope this helps and post below if you need any further help.

Examining Security Of Open Source and Closed Source

Cory Hardman — Sun, 02 May 2010 16:45:25 +0000

I recently just completed a research paper, with two of my colleagues: Clint Caywood and Matt Strayhall, on the security of Open Source Software. The paper went very in depth and I feel helped fill a void of the lack of credible information in this hotly debated topic. Here is the abstract:

In this paper, we examine the security of open source software versus that of closed source software. Facets examined include a brief history of the growing need for security in software, a comparison of the different philosophies driving the development of security in open and closed source software, arguments for obscurity in closed source versus the “many eyeballs” theory in open source, and the pros and cons involved with both development processes. We also look at the two approaches in practice, focusing on competing software like Linux and Windows, OpenOffice.org and Microsoft Office, and Apache and Windows IIS Server. Finally, we examine the impacts on society from software security, as well as who is responsible for maintaining secure software.

You can find more, including download links, if you visit my Research section of this website.

Floating Point Guide

Cory Hardman — Sun, 02 May 2010 16:24:36 +0000

I came across a great article about the pit falls of using floating point numbers in programming. All to often software bugs come up because developers expect something like 0.1+0.2==0.3. The article goes into very clear detail as to why it is not the case that we can expect exact equality while using float point representations.

No NoSQL

Cory Hardman — Sun, 28 Mar 2010 16:45:06 +0000

I’ve recently seen major websites start to move their database back-ends from MySQL to a NoSQL solution. NoSQL for those that have not yet heard of it is way to story data in a loose manner without a rigid scheme defined in a non relational way. The claim is that it these newer technologies can scale better than other relational based methods.

Which is fine and dandy for certain projects and if it works it works. However, a recent article underscores a feeling I have had with this trend. What is wrong with MySQL? The recent move to NoSQL would make one wonder how did we ever manage to store this information in the past? I’d have to guess that over 99% of all projects are not large enough to every be concerned with scale issues. By scale issues I mean trying to store Google’s search information. MySQL or some other relational database back-end is being used by nearly every large cooperation in the world to store and manage tons of information.

Relational storage based solutions are still perfectly fine for nearly every project and they are often much easy to use. Be sure to think carefully before trying to decide which direction to head down.

Risks of Modern Life

Cory Hardman — Mon, 22 Feb 2010 04:11:44 +0000

According to Confused using social websites such as Twitter or Facebook can increase your risk of being robbed. It is even being said that using Facebook or Twitter may soon increase your home owners insurance. At first glance this seems pretty scary and is something that most people likely never considered.

Robbers want to rob a house when they will have the greatest chance of not getting caught. That means they do not want anyone to be home. These articles point out that when you post your ware abouts online, you are informing robbers. They could use the information that you are not home to go to your house and rob it. The first assumption is that your address is freely available. After doing a quick check of my computer illiterate friends on Facebook, I didn’t find any with that information available. However, the robber could use your name and a phone book to look you up.

The other problem is robbers already have tons of ways to find people that are not home. Simply picking up a phone book and calling numbers in order and going to the houses that do not pick up. In fact the robber could get lucky and they home owner would have put a message on their voice mail saying they will be out of town. Robbers also know that nearly everyone works during the day. So they can simply go up to a house during the day and knock to see if someone answers the door.

If we look at someone who can guarantee is not home during a certain time, such as a news anchor who is live on air at a certain time each day. We do not see an increase in the likelihood of robber for news anchors versus the average person.

I’m not saying its perfectly fine to post your ware abouts online. I just want to point out that it is very doubtful it increases your likelihood of being robbed. I hope the smart people at the insurance companies actually look at some data and not just jump on the chance to charge more money.

Future of AI

Cory Hardman — Thu, 11 Feb 2010 01:18:00 +0000

AI has always intrigued me. The idea of recreating human or at least intelligent behavior with software is an amazing idea. Unfortunately modern AI is nothing like the dream of creating human behavior. Sure the current solutions can solve some pretty cool problems, but its not the types of problems that people think of when they dream of AI. At h+ Magazine an article was posted discussing what the experts of the AI field predict to happen over the next century. Most seem to think we are a long way off from even being able to pass a 3rd grade exam and possibly 100 years off from making smarter than human AI.

The thing about most AI style problems is that we can solve them in a much easier ways without AI. Passing a 3rd grade exam could be done with advances in natural language processing and some clever Internet searching. It turns out to be very difficult to find ways to test AI. Even the famous Turing Test may not be as satisfactory as one might think. Its hard for a human to tell even if they are talking to another human even if they are, in fact, talking to another human.

The reason why it is so hard to identify another human during the Turing Test is because we don’t know what we expect from another human. It comes down to the fact that we have no idea what makes us human. Its nearly impossible to describe a humans intelligence and identify the intelligent parts. So it would be very difficult to quantify how an AI system is better than a human, let alone equal.

I think before we are able to make any true AI system we first need to figure out how the human mind works. Which is turning out to be much easier said than done. Every time we figure something out about the brain, it creates at least ten more questions about the brain. To put this problem in some sort of perspective: We had a theory of computation decades before the first computer hardware and we had predictive models of space centuries before we had the ability to test them. However we have the hardware to run our AI systems on, but no theory as to how to do it. So I think we are at least half a century away from having anything near what we dream AI to become.

Fast Case Converter

Cory Hardman — Wed, 16 Dec 2009 01:03:47 +0000

Often I find myself needing to convert between upper case to lower case and vice versa. This is a fairly simple thing to do if you understand ASCII encoding. A good reference for the ASCII Table can be found here. As you can see, to convert a letter to lower case you would add 32 to the current value and subtract 32 to convert it from lower to upper. However to implement this it takes a few lines of code to put some conditions in that check to see the current case and decide to add or subtract.

I was looking at the ASCII Table the other day and came up with a simplistic method to swap the case of a given character. That is to exclusively-or the value of the character with 0×20. This will convert the upper case to lower and the lower to upper. Its probably the fastest method to swap ,CPUs can xor in one cycle (excluding memory load time). However you still need some type of conditions to make sure the character is actually a letter and not a number of symbol.

Enjoy!