This series of articles will help you become more familiar with the use of the various ways in which you can secure data. Before we get into the nitty gritty of how to secure your data, it is important to first understand both why and when to secure your data.

I've started most discussion, talks and blog posts on this topic in the past with the same statement, and it is the same statement I will once again share here:

There is no such thing as a secure application. What can be done, can be undone. Period.

Having said that, however, let me follow it up with what securing [web] applications is really all about:

Adding security methodologies such as encryption, obfucation, authentication, rejection and access control decrease the surface area exposed to would be hackers.

What does this mean, really? The more layers of complexity you add to the exposed layers of your application the more unlikley it will be a) a target of a hacker and b) [fully] hacked if it is targeted.

So, let's take a moment in brief to discuss each of these methodologies and what they can do for you.

Encryption
For experienced application developers encryption is no stranger. Encrypted values have purposes above and beyond simply storing data safely, and combinations of encryption methods exponentially increase the complexity of the encrypted result.

For beginning developers, however, the use and purpose of Encryption, depending on their corporate standards, may be something simply glossed over or, at worst, unknown.

What kind of developer you are usually depends on one simple question... can I see the users passwords in your database in clear text?

Encryption, in it's most simple explanation, is the method of translating human readable information into non-human readable information by way of some (usually mathematical) manipulation.

So, for example, in the earlier centuries (let's say the 17th century - in England, for the sake of argument) when someone wanted to send a covert message to another person they would transpose or translate the existing text into other letters, numbers, symbols or some combination thereof using what was called a key.

Let us say we wanted to translate the word 'food' into a word that has no relation to the word food and, for all intents and purposes wouldn't be understood as 'food' by anyone without possession of the key.

Let's say that the letter 'f' should be turned into the letter 'w'.

Let us further say that the letter 'o' should be turned into zero (0).

And, finally, let us say that the letter 'd' should be turned into the letter 't'

so, our key would be:

w = f
0 = o
t = d

and the text 'food' would be 'w00t' when we penned it on our parchment before sealing it with wax and sending it off by horseback to our nearest allies.

Even if our horseman was caught, tortured and killed (poor horseman)... without the key, or an alarming sense of wit, determination and intelligence, anyone attempting to decipher the covert message would find it to be, at worst, impossible, and at best a highly daunting and time consuming task.

Over the years, many methods of encryption have been invented and used around the world to protect messages in all their forms. Some have been relatively low-tech - the use of native american indians to speak their native (and unknown to the enemy) language for communicating on open airwaves during the war, for example.

Modern methodologies have grown more and more complex as our technology has gotten better, faster and more capable of executing complex mathematical equations quickly.

In Coldfusion land you have many, many encryption methodologies to choose from, depending on either your version of Coldfusion (with 8 and 9 supporting more methods than 6 or 7) or your level of effort (Sun's JCE,  and other cryptographic service providers (like Bouncy Castle) can easily be installed on CF7... see the technote ).

We'll cover the Coldfusion specific aspects later, but now let's talk about why you would want to use this handy functionality. It can all be summed up nicely in three words:

Personally Identifiable Information

Or, PII for short. What is PII? Names, addresses, birthdates, medical (or any other kind of) history, phone numbers, email addresses, social security and credit card numbers (though the latter is not wise to keep in any database, encrypted or otherwise), etc. Any information which *could* be used in any *harmful* way against another human being should fall under the category of Personally Identifiable Information (blog posts and stupidity not withstanding).

Application security that generously uses encryption throughout its design creates a much more secure application as well. Sending critical information in a form or on the url? Encrypt it first and decrypt it on the receiving page.

I'll dive pretty deep into Encryption in my next part of this series, but for now let's move on to our next topic.

Obfuscation
The dictionary defines obfuscation as: to be evasive, unclear, or confusing. Obfuscation is the practice of hiding things in plain sight. A real quick example is the use of an MD5 hash to pass variable names on a form or url, and a more complex example would be using that same hashing to pass column names in a database. How is this evasive, unclear or confusing? Well, let us say you normally pass things like this on your URL:

myFile.cfm?user=5&sugar=true&spice=true&everything_nice=true

Any would be hacker might infer (and most likely be accurate) that the user id of the currently logged in user is '5'. Depending on your application and what effects the remaining fields have on the outcome of the business logic behind them, a hacker might at least attempt to break the code or otherwise hack the site using combinations of values. For instance, I might be tempted to try:

myFile.cfm?user=6&sugar=false&spice=true&everything_nice=;INSERT INTO users (username, password) VALUES ('hacker','0wn3d!');

Let us assume that this page erroneously uses the user id passed into it to set a request variable that defines the current user. At worse, suddenly, I'm whoever user id #7 is and now have an authenticated session to do as I choose with that users account.

Let us further assume that sugar, spice and everything_nice are used as some funny way of passing along the gender of the user - all set to true the presumption is the user is a female (being they're made of sugar, spice and everything nice) - any falses assumes a male.

Let us further assume that your page has an unprotected select statement that checks for the value of 'everything_nice''. Viola! I cause an error, but run the chance of inserting a user into your database using some pretty common naming conventions. I already know you're not using encryption or obfucation on the URL so will assume none is being used on the backend either.

Let us further assume that you've taken the extra steps to protect against SQL injection in your application, however the security of your SQL server itself can be easily compromised. Again, the hacker already has an id of '5', so they can simply go looking through the compromised database to find all the information on that, or any other, user.

So, how to solve this problem?

myFile.cfm?#Hash('user','MD5')#=5&#Hash('sugar','MD5')#=true&#Hash('spice','MD5')#=true&#Hash('everything_nice','MD5')#=true

or, after the output:

myFile.cfm?EE11CBB19052E40B07AAC0CA060C23EE=5&ADA15BD1A5DDF0B790AE1DCFD05A1E70=true&77F4DE0C4DB55DEC736561AC64C7EA6B=true&E069AE80F59380EB79CCE5B19296898C=true

Is this evasive? Yes. Is it unclear? Yes. Is it confusing? Yes. It is obfuscated.

Again, this is merely a brief introduction, I'll cover more on this topic in Part 3.

Authentication
My personal favorite topic. Authentication is the method by which you allow very access for individuals, computers or services.

I'm not going to go into a lot of detail in this article as the topic of authentication could be many articles all by itself. I will say I am not a fan of <cflogin>, never have been and, as far as I can tell with CF9, I still will not be.

I like granular control over the authentication process. I like using hashing and Javascript, cookies and CGI referrer's and domain validation and all sorts of things a proper authentication mechanism should do and which <cflogin> severely lacks (not to mention the memory and session issues it has).

There are many different stylers of authentication. Basic, Form Based Basic, NTLM/AD, Secured and Federated - not to mention Single Sign-On which is a variant of Federated authentication.

Basic authentication is the authentication you're being asked for whenever you log into a site and it throw up a javascript-ish looking 'username' and 'password' (and for NTLM Basic, 'domain') fields. The main caveat (though there are several) to using this security method is the username and password are sent in clear text on *every single request*. In short, if someone did manage to get a man in the middle attack going against you, it wouldn't take them long to sniff out a user/pass combo to use.

Form Based Basic authentication is the most widely used method by most web applications today, which is unfortunate for most web applications and great for hackers. For based basic authentication also sends the username and password in clear text, one of it's main caveats.

NTLM/AD authentication falls into a realm somewhere between Basic authentication and Secured authentication. From a web application perspective, NTLM/AD authentication is directory service authentication with all the enhanced security functionality of back-end (e.g. local) authentication using Kerberos keys, among other functions.

Secured authentication takes the extra step to use some kind of hashing routine to hash the password, and often the username, in Javascript through the browser before the data is ever transmitted to the backend.

Federated authentication goes a couple steps further than simple secured authentication, adding cookie, referrer or some combination of checks to ensure the user is logging into the website from the domain the site is hosted on. This stops most everyone from running a local application or a script from another website which hammers your website with brute force attacks, with a few exceptions.

Single-Sign On authentication is the methodology you would use to share the same login credentials for multiple web applications. This is handy for building applications in smaller units and then tying them together with a portal framework.

I'll cover authentication heavily in Part 4 of this series.

Rejection
We've already briefly seen an example of SQL injection earlier in this article - rejection is the methodology used to validate user input and reject (or parse out) any dangerous code which might be present. This includes SQL and Javascript injection. Just as you reject the things that do not meet your standards in your everyday life, so too must your applications reject anything non-standard in their everyday life.

Often it is handy to build a utility class (CFC, Component) in Coldfusion that shares the duties of trimming space from before and after the input, reformatting HTML special characters and eliminating unwanted inputs such as SQL and Javascript injection, among other handy repetitive FORM handler tasks. This component can be built generically enough that it can be reused throughout your application(s) for various [all] user input validations and is generally written to accept and return Struct's (e.g. FORM or URL, which are both structs).

I'll be breaking down how to write this utility class in Coldfusion and how to use it efficiently as both an input parser and a server-side validator in Part 5 of this series.

Access Control
When you talk about authentication, access control is usually a large part of the conversation. Implementing access control solutions, however, can take many forms and depends entirely on your understanding of the methodologies available to you and, more importantly, the requirements to which they will be applied.

Most ColdFusion developers are familiar with and comfortable using a role based approach. Anyone following the unfortunate guidelines of the <cflogin> evangelists at least learn one important concept - the concept of role based access control. While I do agree that IsUserInRole() is a nice function of ColdFusion, it is tied to an insanely inadequate and buggy <cflogin> construct. So, the best approach is usually to replace IsUserInRole() with ListFind() if you want to continue using a role based approach where you store the users roles as a list, in a varchar, in the database and then pull that list into the ListFind routine (as in: ListFind(MyList,MyRole) ). In the case of multiple roles, you simply use logical AND/OR as taste suites you (as in: ListFind(MyList,MyFirstRole) OR ListFind(MyList,MySecondRole) ).

Anyone with a hint of Unix, Linux, Apache or Cisco access control experience will know that flat files are another methodology of maintaining access controls. There are some drawbacks to using flatfiles for systems with a large number of users and/or a large number of roles however. Flatfiles are accessed and processed sequentially (this includes XML - though this is another discussion for later). So, the more users and/or more roles you have the larger the flatfile becomes and the longer it takes to read and process the access control for a specific user. Also, you have to use locking to ensure the files are not being appended to by more than one request at a time, and there are a few other caveats. However, for a limited number of users and roles, an XML file might be just the thing (though, please, make sure it is *not* in your web document directory or subdirectory - put it out of the reach of what you expose to the web!).

More complex access controls, dating back to the good ole days of rock 'n' roll and Commodore Vic-20's, are still viable and, often, faster than even the most modern methods. Bit manipulation, my favorite, and a function available to CF8 and up, allows for the use of a single byte to store multiple access levels per bit using positional math.

And, as a final note about access controls, it's not all about user access. Sometimes you have API's which you only want subscribers to have access to. Sometimes you have ColdFusion servers talking to other ColdFusion (or any other) servers and want to ensure only allowed servers can communicate. Access control can even go as far as ensuring applications only have access to and use specific pieces of it's whole, as in limiting your SaaS functionality - the easy way.

In Part 6 of this series I'll dive more deeply into these and other methods of access control and implementation.

And, finally, in the end I will sum up what you [should have] learned in the process and detail more clearly how each piece interacts and coordinates it's activity with the other pieces in Part 7.

Afterword
I intentionally didn't expose much code in this first article in the series as I feel it is just as important to understand why it is neccesary to take these measures as it is to understand how to do it, and these theories will help build a good foundation for the next several articles.