>Its not a failure of the industry experts to understand the problem. Its >the failure to have a problem in the first place, honestly. I think that, >while you are clearly working hard to wrap your arms around the subject... >you aren't there yet. > >What you want to do is inherently insecure... use client-side code to >enforce a component of security? How would you protect the client-side code >from being hacked and manipulated to ill effect? What scenario will you be >covering, since the transmission off the screen is fully covered by the >https protocol and a certificate? The only threat left is someone looking >over the hapless user's shoulder and writing down their input, and in your >capacity as developer you cannot protect against this type of threat. > >And client-side code is inherently open and available to the ... client. >Open for inspection and giving clues to the server side tools in use; >providing insight to the thoughtful hacker as to how they go about their >next step in their attack against you. > >So if the client desktop is its own problem outside your control, and the >transmission has a globally-accepted, universal solution in place, that only >leaves the server side, and there you do indeed have quite a lot of wiggle >room with respect to doing it badly versus doing it well. > >Just for starters, if you are hashing something (like a password) I would >say you have made a mistake right there if its a simple hash. Use a salted >hash always. I know cfencrypt/cfdecrypt has made great strides in CF7, but >I'm not sure if it is really industrial-strength? I'll leave that question >to others. I rely on 3rd-party tools that give me RSA asymmetric-key >encryption of selectable strength, personally. > >> "SSL is used for confidentiality, not Data Integrity" > >That is incorrect. Read tha Wikipedia article that was linked a few posts >back in this thread. > >While you need to exercise care and perform due diligence, some of this is a >lot simpler than you are making it out to be. Worry about the server side. >The rest is effectively out of your hands due to the nature of the medium. > > >-- >[EMAIL PROTECTED] >Janitor, The Robertson Team >mysecretbase.com
<<<What you want to do is inherently insecure... use client-side code to enforce a component of security? How would you protect the client-side code from being hacked and manipulated to ill effect?>>> I think I get it, but I stand by what I said, it appears to me there is a disconnect when it comes to security and the internet. I did a search on Google with "data integrity" and hash and there are over half a million hits, touting using a hash for data integrity. Fact is, if I understand you, it can't be done, at least not properly/securely, not by me, because the hash has to be done on the client, and like you said, the client is inherently open, although, you can use the cfcompile utility with the deploy switch to protect the code on the client, can't you? Anyway, I now see that you have to depend on SSL and do your encrypting on the server for the DB. As far salting the hash used for the password(after the password has arrived on the server), I assume you need to use some kind of salt that is repeatable, I was thinking of using several characters from other columns in the record and plugging those characters into a hash or encryption function, then using that result as the salt and hashing that with the password. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Check out the new features and enhancements in the latest product release - download the "What's New PDF" now http://download.macromedia.com/pub/labs/coldfusion/cf8_beta_whatsnew_052907.pdf Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:286896 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
