Are we talking about building Bank of America's Online Banking ;) Seems to me, the user asking the question is not looking for a cure-all.
============================================ Bryan F. Hogan Director of Internet Development Team Macromedia Volunteer Macromedia Certified ColdFusion MX Developer Digital Bay Media, Inc. 1-877-72DIGITAL ============================================ -----Original Message----- From: Barney Boisvert [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 02, 2003 1:35 PM To: CF-Talk Subject: RE: encrypting password You could store it as a single CFSET tag in an encrypted file that only the CF user has permission to read, or put it somewhere that's really secure (offline DB that you have to do some nasty authentication over SSL to get the data from), and then cache it upon app startup. Both are still suceptible to anything that lets a use execute CF code, as they can just dump the application scope variables, but such is life. --- Barney Boisvert, Senior Development Engineer AudienceCentral (formerly PIER System, Inc.) [EMAIL PROTECTED] voice : 360.756.8080 x12 fax : 360.647.5351 www.audiencecentral.com > -----Original Message----- > From: Tony Schreiber [mailto:[EMAIL PROTECTED] > Sent: Wednesday, April 02, 2003 10:23 AM > To: CF-Talk > Subject: RE: encrypting password > > > Ditto. My question though, is since you must store your salt string in the > code (or the db somewhere), access to the db pretty much assumes they have > access to the code as well. How is the salt string secure? > > > Yes but if they have access to your db then you've got > generally a bigger > > problem than a dictionary attack > > > > > > > > -----Original Message----- > > From: Brandon Stone [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, April 2, 2003 18:21 > > To: CF-Talk > > Subject: RE: encrypting password > > > > > > One note on security using hash, this still leaves the passwords in the > > database open to dictionary attacks. Its really only slightly > better than > > storing the passwords unencrypted. That is to say, if the > attacker somehow > > gains access to the database, they just need to use a > dictionary file, and > > try a hash of those words one at a time until a match is found. > > > > A generally accepted strategy is to use a salt word as well to > create the > > password. The salt is a string which you know and keep secure, > which the > > attacker hopefully does not. Then they need 2 pieces of information to > > attack the database. The comparison is essentially the same: > > > > <cfset salt = "mysuperS3cRetStr$ng"> > > <cfif Hash(form.password&salt) is not checkperson.passwordHash> > > <cflocation url = "unauthenticated.cfm"> > > <cfelse> > > ... > > </cfif> > > > > when you insert the hashed password, just append the salt to > the end. <cfset > > hashedPwForDBInsertion = Hash(form.password&salt)> > > > > One more note, using hash() makes lost password retrieval more > difficult in > > that the hash() function is a one way hash. There is no way to > unhash. So > > essentially, if someone loses their password, you need a > mechanism for them > > to reset the password to a new password, rather than just > pulling the old > > one from the db and sending it to them. > > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, April 02, 2003 11:51 AM > > To: CF-Talk > > Subject: RE: encrypting password > > > > > > I'd suggest using CFs hash() function. It's a one way > encryption/obfuscation > > method. > > > > Doug > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Get the mailserver that powers this list at http://www.coolfusion.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89 70.4
