cf.Objective() 2010 — Day 3

Part three of my cf.Objective 2010 series. Again I arrived a little late today. Just over tired. I got to Terry Ryan’s ORM talk about half way through. When I walked in he was talking about lazy loading, extra lazy, and eager. He mentioned how you can actually do a eager join when you load an object which instead of running separate queries two get all of the data you need it Hibernate will create a ‘large’ join statement that will pull all of the data in one query. This was something I hadn’t previously heard of and sounded like it might have some good uses. He went on to talk about Caching, Event Handling and Table Generation.

I am starting to get to the point in the conference where I just want to lock myself in my office at home and experiment with all of the things I have been exposed. This inevitably makes it a bit difficult to pay close attention to the presentations.

Practical ColdFusion Security

with Justin Mclean

Justin’s talk was split into two parts. First he talked about risk assessment then applying it to a practical example.

Risk assessment is balancing the business objectives and security requirements. This process should not be done only once. Risk should be assessed before the project is implemented, after it has been implemented and any time it is changed. Keep in mind that treats are not always external. Once threats have been identified they should be rated for both frequency (how likely the treat is to occur) and consequence. The level of risked is determined by f x c. After level of risk is determined each threat can be prioritized.

Risk Assessment Process

  1. Identify Assets (anything that has risk. staff, software, hardware, information)
  2. Identify and Quantify the possible threats (include unlikely threats, don’t ignore the obvious)
  3. Determine the consequences of each threat
  4. Evaluate the current risk (What level of risk are they based on frequency and consequence. What is acceptable.)
  5. Decide acceptable level of risk
  6. Treat each risk

The simpler a system is the more secure it is.

For the second half of his presentation Justin talked about how he applied this process to a Student Election System he helped develop.

Developing APIs: Dos and Donts

with Simon Free

An API (Application Programming Interface) is an interface to an application that has documentation for what functionality is available and exposes functionality of an application to outside use. Whether that be another internal application or an external application. They are good for sharing content and functionality, centralizing functionality, and allowing other technologies and code to interact with your code. There are two major types of APIs, RESTful and RPC. RESTful is a much more flexible API a base URI that exposes multiple URLs that have different functionality. When developing an API you should write and test your documentation before writing any code. This will ensure you have a solid road map for the code you are developing.

Once you have a solid, tested set of documentation write your code strictly from that documentation. If you discover revisions it is best to update the documentation and have it tested again before continuing to your coding. After coding the API you need rigorous testing (obviously) and attempt to hack it. This is important because you can be certain that once it is available to your end user they will try to break and hack it.

Simon had a lot of great information in this presentation and it was very compelling. He did a good job of taking a high level approach and then giving multiple examples. Part of the way through his talk he brought up three people onto the stage and had them test some documentation. He came back to them after a while and went over the results. The API they where testing documentation for was actually the Flickr API. He gave one person no documentation, one person a single page of documentation, and the third person the entire Flickr API documentation. Person one could not complete the task at all. Person two was very close but not perfect. Person three had it perfect but had to sort through all of the 30+ functions to find the few he needed.

A Brief Introduction to Cryptography

with Jason Dean

I was going to go to the session on using ColdFusion for creating workflows but because of my personal interest in Cryptography I decided to go to Jason’s presentation. I asked Jason if he had read the book that got me interested “The Code Book” by Simon Singh. He told me it was on his list of books to read.

Jason started off the presentation by giving a very brief overview of cryptography, cryptanalysis, and cryptology. I am not going to write much about this part of the presentation. I would encourage you to check out any number of books on the subject such as the one I mentioned above. I must say that book was a very enjoyable read. It even inspired me to write a couple simple CF apps that handle some basic well known ciphers.

After his overview he started using examples that we as programs would be familiar with just as Digitally Sign Certificates, SSL, and TLS.

Some encryption technologies available in CF include CFMX_COMPAT, Blowfish, DES (Data Encryption Standard), Triple-DES, AES, PBEWithMD5AndDES (Password Based Encryption), PBEWithMD5AndTripleDES. DES is the old standard but is not anymore. Triple-DES is much stronger and can be effective is used correctly (C = Ek3(Dk2(Ek1(plaintext))). The new standard algorithm is Rijndael (rain-doll). It is a 128 bit encryption that can accept either 128, 256, or 512 bit keys.

To use encryption in ColdFusion you would use the Encrypt function:

encrypt(str, key, [cipher, encoding, IV or salt, iterations])

<cfset plaintext = "My plain text message" >
<cfset key = "mykey" >
<cfset cipertext = encrypt(plaintext, key, "AES&#39;/CBC/PKCS5Padding", "key") >
<cfoutput>#cipertext#</cfoutput>
<cfset decipertext = decrypt(cipertext, key, "AES&#39;/CBC/PKCS5Padding", "key") >
<cfoutput>#decipertext#</cfoutput>

Making Bad Code Good

with Dan Wilson

This was a pretty basic session with a lot of code examples. Dan just went through about nine real world code examples he has encountered during his career and showed how they could have been written in a more efficient way. I can basically summarize it by saying use proper standards, name variables and functions with context and avoid taking shortcuts.

If you have any questions about what went on at the conference don’t hesitate to contact me or better yet leave a comment.