Thanks Scott, I've updated the ticket to reflect this.
-Ben Dewey -----Original Message----- From: Scott Golightly [mailto:[email protected]] Sent: Monday, November 09, 2009 4:09 PM To: [email protected] Subject: RE: [jira] Commented: (STONEHENGE-15) Protect connection strings in Business Services and Order Processor solutions I was reviewing this the other day. Since we moved the majority of the the uid/password information out of the config file this is mostly a non-issue. Instead of automatically encrypting sections of the config file I was going to update the documentation to explain how it could be done through the command line utilities and then close the ticket. I personally believe there is some value in having the majority of the web.config file encrypted on "to keep the honest but curious person honest" but that seems to be getting out of the realm of best practices and into the realm of personal preferences. Scott Golightly -----Original Message----- From: Ben Dewey (JIRA) [mailto:[email protected]] Sent: Monday, November 09, 2009 2:03 PM To: [email protected] Subject: [jira] Commented: (STONEHENGE-15) Protect connection strings in Business Services and Order Processor solutions [ https://issues.apache.org/jira/browse/STONEHENGE-15?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12775137#action_12775137 ] Ben Dewey commented on STONEHENGE-15: ------------------------------------- Nick, Config is building the connection string from app.config BS and OPS both use the values returned from the Config service which are feed into the SQLHelper method. At the time of building the config service there wasn't a uid/password setting in the DB for the DB connection string. I just checked the php/wsas/metro stacks and it doesn't appear that they are using the DB values for the connection string. It looks like all they're using is the config file connection string. Either way this is a really old ticket, from before M1, and I don't know how much it relates. If anything we should close this and create a new ticket to remove the hard-coded uid/password from the SQLHelper class (we'd need to discuss options here thou, because if you store DB uid/passwords in the DB then we'll definately want to do some encryption) If others agree, please respond and I'll close this. Scott??? > Protect connection strings in Business Services and Order Processor solutions > ----------------------------------------------------------------------------- > > Key: STONEHENGE-15 > URL: https://issues.apache.org/jira/browse/STONEHENGE-15 > Project: Stonehenge > Issue Type: Improvement > Components: DOTNET_BS, DOTNET_OPS > Environment: .NET trunk > Reporter: Scott Golightly > Assignee: Scott Golightly > Priority: Minor > Fix For: M2 > > Original Estimate: 2h > Remaining Estimate: 2h > > The database connection strings are listed in plain text in the configuration > files. .NET provides the means to encrypt the connection strings and > automatically decrypt the values before using it. Encrypting the connection > string is a best practice to protect the database login information. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
