My Presentation From the Online ColdFusion Meetup Group

I just finished my first presentation to the Online ColdFusion Meetup Group. I had a great time. There were no technical difficulties, and everyone was very nice. Some great questions too.

I look forward to doing that again some day. As requested, I am posting my presentation. It is available as a download on this post, it is also available from

Application Security : Beyond SQL Injection

Chris Luksha's Gravatar I really enjoyed your presentation - thank you. I had to watch it this morning on recording so it was a bit confusing. Many of the slides were faster than your speaking - but once I found your presentation download here - it was easy enough to follow along with the preso that way. Thank you very much for the preso.

What are the chances you would share some of the code you used for the log in process? I was really interested in the looping over ht has etc - but the preso was too small view most of it. Just hoping :)

thanks again.
# Posted By Chris Luksha | 1/23/09 8:30 AM
Chris Luksha's Gravatar Sorry - I typed too fast. I meant to say I was very interested in the looping you did while hashing. Your password checking was pretty intense and I find that I use only a third of what you showed there - time to step it up I think.
# Posted By Chris Luksha | 1/23/09 8:33 AM
Jason Dean's Gravatar @Chris, thanks for the comments and praise. I had a great time doing the presentation and I am glad people are getting something out of it.

Thanks for asking about the code. I forgot to mention that it is available. You can download it here:
# Posted By Jason Dean | 1/23/09 8:47 AM
Stephen Weyrick's Gravatar Thanks for the presentation. I am green when it comes to coldfusion security, so this presentation really helped me to understand how important securing an application can be.
# Posted By Stephen Weyrick | 1/23/09 10:02 AM
Chris Luksha's Gravatar Thanks for the files that is great. I have a question for you about the setclientcookies. You said in your presentations that you prefer to use cfid and cftoken over jsession ids b/c of their ease of use. You also mentioned (and showed on slide 10 ) that you need to set setclientcookie = false in order to manipulate the cf session tokens.

In your sample files you have setclientcookie = true. Is this simply because you are not bothering with over the top security in the samples? You don't seem to edit the cfid and the cftoken in your sample files.

And btw - If it's ok I would like to grab from these files and rebuild my own login structures. I have been fighting for years to come up with a valid administrative login process and it seems that I change it every time the next guy says oh you should do it this way... So in keeping with my bouncing off the wall, never anything built the same habit - I thought I might try this out in my current app :)

If only I could find a good standard that I liked - and didn't keep getting reasons to not use the last one - I could settle down and get engaged to one of these processes.
# Posted By Chris Luksha | 1/23/09 10:52 AM
Jason Dean's Gravatar @Chris,

I am not dealing with cookies at all in that application, so the fact that I have setClientCookies there at all means I was either messing with something else, or I copied and pasted that from another source.

The only time you should setClientCookies to FALSE is when you are going to explicitly set the session token cookies yourself. If you set it to FALSE and then don't set the cookies, your users will lose there sessions on every request.

Make sense?
# Posted By Jason Dean | 1/23/09 12:08 PM
Jason Dean's Gravatar @Chris,

Oh, and Yes, by all means, use the code for whatever you like. I hope it works out. I'd love to hear about what you develop.
# Posted By Jason Dean | 1/23/09 12:09 PM
Chris Luksha's Gravatar Thanks Jason - I will let you know how it works out. I am so pressed to get this thing done and I am amazingly green on using the application.cfc format so I will be piecing it in a little at a time and praying in between as we all do :)
# Posted By Chris Luksha | 1/23/09 12:42 PM
Chris Luksha's Gravatar I have a crazy Question for you Jason - In my application I have 3 levels of users - Admin/ Human Resources/ and Employees. If I use the uber hashing and salting method - how might I go about making this happen do you think ...

The admin (while logged in as admin) wants to be able to login as an HR person with one click and the HR person (while logged in as hr) wants to be able to log in as an employee with one click.

I have 3 tables of users Admin, HR and Employees that can access diff portions of the site. Any ideas how I might implement the one click solution and still used hashed and salted passwords? Maybe setting roles? I'm a little stumped and hope that maybe you could help.

I have other apps with this kind security as most people do - and I tend to set up session structures similar to:
session.admin. ... ...
session.user. ...

Maybe they need to do more than just click - maybe they need to enter in a secondary password that they created on account setup? I just don't know and hope for any ideas from anyone :)

# Posted By Chris Luksha | 1/23/09 10:08 PM
Jason Dean's Gravatar @Chris, There is no reason that salting and hashing passwords should prevent, or even affect, your access control measures from doing their job. They are really two separate functions.

When a user logs in, regardless of what type of user they are, you will take the password that they provide, add that user's salt to it, and hash it. Then you'd compare the value to the hashed user password value that you have store. If they match, then you log the user in and grant them whatever privileged is appropriate. From that point on, your session management has nothing to do with the hashed password values.

Later, if the user wants to be able to switch their roles, you can simply change the value in their session. Although, I think I would strongly consider prompting them for their password again, should they do that. You already know their username, because they are logged in, so you should only ask for their password. When they provide it, salt it and hash it again and make the comparison again. If it matches, then switch their role.

Make sense?
# Posted By Jason Dean | 1/24/09 10:35 AM
Chris Luksha's Gravatar That does make a lot of sense Jason thanks. Funny thing is that I thought of that 'kind'a I just couldn't put my brain around it. I too would put the password in there again. Then I could simply set the session.user structure values to the appropriate user information. Makes perfect sense.

thanks again
# Posted By Chris Luksha | 1/24/09 11:44 AM
Michael White's Gravatar thanks again for the presentation and code, I've been wanted to implement this since your original post back in the stone age.
# Posted By Michael White | 1/24/09 5:46 PM
Henry Ho's Gravatar I've heard somewhere that prepending salt is better against rainbow table attack (for md5), but I couldn't remember where. Have any of you heard of it?
# Posted By Henry Ho | 1/25/09 10:44 AM
Jason Dean's Gravatar @Henry,

I can't imagine why prepending would be any better than appending. But I can see that it might be better to do both.

It would further obfuscate how the hash was used if you were to, for example, take the 35 charatcers of the UUID and prepend the first 27 characters to the password, then append the last 7 characters and leave out the 28th character completely. Then do the same thing with the the user input at login for the hash comparison. This way, even if the hacker did compromise you database and get both your hashed passwords and your clear-text salts, he would waste his time doing a brute force attack by appending and prepending the salts to common dictionary words, dates, names and stupid passwords.
# Posted By Jason Dean | 1/25/09 11:28 AM
Raj's Gravatar Just watched this.
Great presentation Jason. The salting technique is definitely new to me.
# Posted By Raj | 10/27/09 11:09 AM
BlogCFC was created by Raymond Camden. This blog is running version 5.9.1. Contact Blog Owner