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 slidesix.com






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.
Chris
Thanks for asking about the code. I forgot to mention that it is available. You can download it here:
http://www.12robots.com/enclosures/HashAndSalt.zip...
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.
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?
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.
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.dealer. ...
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 :)
Thanks
Chris
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?
thanks again
Chris
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.
Great presentation Jason. The salting technique is definitely new to me.
Thanks.