Cory Hardman's Blog » Development

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.

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.

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!

MySQL and Java common problem

Cory Hardman — Tue, 27 Oct 2009 19:52:01 +0000

Have you ever received the following error while using Java and MySQL:

You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ‘????????????????’ at line 1

This is a common error when you first set up Java and MySQL to work together. To correct it simply add the following lines of code to your my.cnf in the section [mysqld]

collation_server=utf8_general_ci
character_set_server=utf8

Self Replicating Code

Cory Hardman — Mon, 19 Oct 2009 04:08:50 +0000

For a class recently the teacher challenged us to write a code snip-bit that would be self replicating. By that I mean write a program that when executed would write out its own source code. This is a bit harder than you’d initially think it to be. My first attempt tried to store the source code within the program when execute it would output what was stored within. However this creates a chick and egg problem. The source code contains the source code. Something that at first stumped me. Then I remembered Stringification in the C preprocessor and I came up with this:

#include “stdio.h”
#define M(Code) main(){FILE* fp = fopen(“source.c”, “w”);fprintf(fp,”#include \”stdio.h\”\n#define M(Code) %s\nM(%s)\n”,#Code,#Code);fclose(fp);}
M(main(){FILE* fp = fopen(“source.c”, “w”);fprintf(fp,”#include \”stdio.h\”\n#define M(Code) %s\nM(%s)\n”,#Code,#Code);fclose(fp);})

This is a pretty cute program if I can say so myself. When its ran it will create a file called source.c that will be exactly the same as the code above. You could even recompile source.c and it will create another source.c. You should attempt to do this on your own to see if you can come up with other cool ways of doing it.

Download: SelfRep.c