There is a lot of ways to secure and encrypt your password. What i usually do is, take the values and send them to the CF server using AJAX as binary code. Like using ajax to upload a file. Basically the string get encoded encrypted thru the ajax. And the XML file changes order and format per request. There is an encrypted variable that defines what type of XML format is been submited as. Then on the CF side i get the values. Read the XML, parse it and then unencrypt the password and user. By the way the user and password get encrypted as one string together. And the delimeter changes randomly. I did this type of login for a transaction based website that wanted something really complicated and secure.

Dave, Actually.. :)intercepting a transmission does not mean you hacked the site.. I can intercept a http post quite easily. The issue with encrypting at the client level is that the encrypted string is the password... so if I interceptthe transmission you sending: falcon or a84571394b5e99fe70aae39ece25f844acbaf83479e27f39a30732e092b19677 makes no difference... because nothing is changing from submission to authentication. (Which kinda takes the purpose of encryption or hashing out of the equation... its like you didnt encrypt anything...) Now; if you do some type of "server-side" encryption to the client-side encryption (so in essense - dual encryption) then that isa different story... (but once again; it wouldmake no sense to do client side encryption; just to re-encrypt :) Just wanted to point that out... This is something I researched quite extensively for work and Ifound it to be a false sense of security :) I have 5 developers write code based on client-side encryption... I then walked through the logs and used the user/encrypted pass and I authenticated withing seconds... Not saying the tutorial is not a good thing; I mean encryption is good... Just think you should do it server-side... instead of client side :)

Pablo that makes sence, But "hypothedicaly" if you hack into the system you could just about what ever you wish. At least with jsSHJ-256 it makes it a bit more difficult for the transmission intersepter to see what the actual password is rather than being in the clear. If you intersept the raw a84571394b5e99fe70aae39ece25f844acbaf83479e27f39a30732e092b19677 and submitted it would not log you in unless the original password: falcon was used. This approch i is still better the sending the data in the raw. if a SSL wasn't being used Kind Regards, davED

I just wanted to post to let you know that doing things this way seem secure at first; but you are actually making it less secure. When you do a transmission the FORM vars (such as using httpExplore) can be intercepted and read... since you are processing the "encrypted" string at the client-level... that in essence becomes the password. So I would see: username=&password=a84571394b5e99fe70aae39ece25f844acbaf83479e27f39a30732e092b19677 Now if I was to hack into the system.. I can simply go in and use an application to modify the transmission when I submit a form and replace a random password I type in the form with: a84571394b5e99fe70aae39ece25f844acbaf83479e27f39a30732e092b19677 And it will authenticate me everytime... does that make sense? I think at first glance it appears to be more secure... but if you stop and think about it... it is actually less secure :)