> The issue was that if they can read the DB, then do they also have > readaccess to the code. If they do, then your decoding is toast > as well.
That is a false assumption. If by "code" you mean CF code, how does compromising the CF server compromise the DB server? Also, if you one-way hash a password using a strong hash (e.g. md5), it doesn't matter if someone has read access to the DB or the CF source. Their only recourse would be to brute force find the original string. > > That said, to what level do you take the encryption? On the ecommerce product I worked on: passwords are md5 hashed. CC information was RSA encrypted using a 2048 bit key. Public key was stored on server. Private key was held by vendor. The vendor needed to give the key when they wanted to view CC#/Expiry date for a customer. The private key was never stored in the database. If it was up to me, the private key would have been transferred to a c++ module that would ensure the key would never make it on the swap file of the server. Therefore, only a memory dump of the server would have been able to retrieve the private key. > > Andy > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Monday, February 24, 2003 6:07 PM > To: CF-Talk > Subject: Re: RE: Password fields in MS SQL Server 2000 > > > Well, if they have _write_ access to your DB, you're up sh!t > creek, no > matter what. > > Having said that, if you're going to store sensitive information, > effortshould be made to protect the privacy of that information. > > I find it mind boggling that people think to themselves "If > someone _could_ > have full access, the information is compromised. Therefore, I > will not put > _any_ effort into security, because someone _could_ have _full_ > access. But > I don't know how someone could get full access, and as such, I > don't need to > put in any security." Yikes. > > ----- Original Message ----- > From: Andy Ousterhout <[EMAIL PROTECTED]> > Date: Monday, February 24, 2003 4:55 pm > Subject: RE: Password fields in MS SQL Server 2000 > > > If someone can get access to your DB and the password field, is > > your problem > > bigger than that they found out users passwords? I don't > encrypt/hash> passwords now because of the perhaps mistaken view > that if they > > can access > > database fields outside of the control of my program then they can > > easilybreak any scheme that I apply either through brute force or > > by finding the > > appropriate code. I do password protect access to the database. > > > > Is this a good assumption/plan or should I also encrypt sensitive > > fieldssuch as PW and credit card numbers > > > > Andy > > -----Original Message----- > > From: Tilbrook, Peter [mailto:[EMAIL PROTECTED] > > Sent: Monday, February 24, 2003 5:17 PM > > To: CF-Talk > > Subject: Password fields in MS SQL Server 2000 > > > > > > Hi there, > > > > Just wondering if there is a setting in SQL Server to hide > > password fields > > like in MS Access. > > > > At the moment the fields are just nvarchar which sort of defeats > > the purpose > > of having a password field in the database (even using SSL for > > logging in). > > > > Thanks! > > > > == > > Peter Tilbrook > > Internet Applications Developer > > Australian Building Codes Board > > GPO Box 9839 > > CANBERRA ACT 2601 > > AUSTRALIA > > > > WWW: http://www.abcb.gov.au/ > > E-Mail: [EMAIL PROTECTED] > > Telephone: +61 (02) 6213 6731 > > Mobile: 0439 401 823 > > Facsimile: +61 (02) 6213 7287 > > > > > > > **********************************************************************> The > information contained in this e-mail, and any attachments to > > it, is > > intended for the use of addressee and is confidential. If you > are not > > the intended recipient, you must not use, disclose, read, forward, > > copy or > > retain any of the information. If you have received this e-mail in > > error, please delete it and notify the sender by return e-mail or > > telephone.The Commonwealth does not warrant that any attachments > > are free from > > viruses or any other defects. You assume all liability for any > loss,> damage, or > > other consequences which may arise from opening or using the > > attachments. > > > **********************************************************************> > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| 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 Signup for the Fusion Authority news alert and keep up with the latest news in ColdFusion and related topics. http://www.fusionauthority.com/signup.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
