settings.txt - password stored in plain text?

Jan 23, 2011 at 1:40 AM

When Orchard is installed to use a SQL Server with a connection string a file called settings.txt is created in the .\App_Data\Sites\Default directory.

This file contains the DataConnectionString (including password) in plain text along with other keys.

1) Isn't this a serious security vunerability? - passwords should be stored in encripted rather than plain text form.

2) Why isn't the connection string being stored in web.config?

Jan 23, 2011 at 2:41 AM

1) The App_Data folder isn't exposed to the outside world at all. The whole idea of app_data since it's been in ASP.NET existance is for this role.

2) I don't know for sure but I'm guessing it has to do with either Azure or trust levels.

Coordinator
Jan 23, 2011 at 5:58 AM

Yes, it's very wrong (although normally quite safe): you should be using integrated security instead of a username and password.

Coordinator
Jan 23, 2011 at 6:42 AM

1) Connection strings are often stored in plaintext in Web.config too. You have to go out of your way to encrypt Web.config too, and do it explicitly on each machine. The important thing is that the file is prevented from download (by virtue of location under App_Data).

2) We avoid putting Orchard app settings (like connection strings) in Web.config because we want people to be able to independently update their Orchard installations/enlistments (which includes the Web.config file), separately from site configuration and data.

Hope this helps,

Bradley

From: JonnyBoats [email removed]
Sent: Saturday, January 22, 2011 6:41 PM
To: Bradley Millington
Subject: settings.txt - password stored in plain text? [orchard:242881]

From: JonnyBoats

When Orchard is installed to use a SQL Server with a connection string a file called settings.txt is created in the .\App_Data\Sites\Default directory.

This file contains the DataConnectionString (including password) in plain text along with other keys.

1) Isn't this a serious security vunerability? - passwords should be stored in encripted rather than plain text form.

2) Why isn't the connection string being stored in web.config?

Jan 23, 2011 at 7:35 AM

Bradly,

I find your points less than compelling.

Just because people often store connection strings in plain text does not make it a "best practice" or even acceptable.

According to Microsoft "Protecting access to your data source is one of the most important goals when securing an application. A connection string presents a potential vulnerability if it is not secured. Storing connection information in plain text or persisting it in memory risks compromising your entire system." (See: http://msdn.microsoft.com/en-us/library/89211k9b.aspx ).

As to point 2 ("We avoid putting Orchard app settings (like connection strings) in Web.config" ), have you considered the use of external configuration files?

"External configuration files are separate files that contain a fragment of a configuration file consisting of a single section. The external configuration file is then referenced by the main configuration file. Storing the connectionStrings section in a physically separate file is useful in situations where connection strings may be edited after the application is deployed. For example, the standard ASP.NET behavior is to restart an application domain when configuration files are modified, which results in state information being lost. However, modifying an external configuration file does not cause an application restart. External configuration files are not limited to ASP.NET; they can also be used by Windows applications. In addition, file access security and permissions can be used to restrict access to external configuration files. Working with external configuration files at run time is transparent, and requires no special coding."

(See: http://msdn.microsoft.com/en-us/library/ms254494.aspx )

Bertrand,

While integrated security has a lot going for it, it is far from a panacea. Three points come to mind immediately:

1) The "double hop issue" when your database server is on a seperate computer from your IIS server (See: http://weblogs.asp.net/owscott/archive/2008/08/22/iis-windows-authentication-and-the-double-hop-issue.aspx )

2) Would not the requirement to use integrated security virtually eliminate the possibility of using shared hosting?

3) Requiring integrated security would preclude a MONO version of Orchard as a practical matter (in that any computer with integrated security would be a Windows computer with .Net already supported).

Coordinator
Jan 23, 2011 at 8:06 AM

Integrated security does solve the problem you were mentioning. Any problems it does introduce would be problems that I'm afraid would be out of the reach of the Orchard team and that you'd have to take to the team that's building that IIS feature. A mono version would have to solve the problem in a different way, but that's probably not the most serious thing standing in the way of a Mono conversion. If you are not satisfied with that solution, feel free to submit a patch for encrypted settings files or to file a bug.

Jan 24, 2011 at 4:54 PM

I have proposed on the feature request site (uservoice) that security be made a priority for the entire Orchard project. The link is: http://orchard.uservoice.com/forums/50435-general/suggestions/1406551-security-best-practices

Unfortunately security is more than just encripting settings files.

If anyone else is concerned with external security requirements such as PCI for ecommerce, HIPPA for healthcare, SOX for public companies or privacy requirements in EU contries I would ask you to read my proposal and vote it up if this is something that is important to you.

Coordinator
Jan 24, 2011 at 8:49 PM

Thanks. If you find any more issues, please feel free to add them as issues in the Issue Tracker on this site.