I believe the ASP.NET Core MVC template should explicitly configure ephemeral Data Protection API key storage in the ConfigureServices method along with a comment indicating that developers should change this for production deployments. Or perhaps even an env.IsDevelopment test like the UseDeveloperExceptionPage if-else block in the Configure method, with no implementation and some sort of // TODO - configure for production comment in the non-dev else block.
Although the web farm deployment docs mention DPAPI key storage configuration, I am finding most corporate developers have zero awareness of the importance of this consideration, nor any awareness of the problems which may arise by failing to account for this. While I was glad to see key storage mentioned in the built-in log output, it is written as an "Information" level event which is normally disabled in production deployments. (I would prefer to see ephemeral storage written as a "Warning" event, which our log-monitoring solutions would then "see" in production, but that's a topic for an issue elsewhere.)
Some background about my experience with this problem: I work in a large corporate environment with more than 100,000 custom internal-use applications, about 70% of which are .NET-based. Our web-based apps run on groups of anywhere from eight to 32 servers on average (and in some cases many, many more). These apps are very slowly being migrated off .NET Framework, and in ALL of the ASP.NET Core apps I have reviewed over the past three years, none of them have configured DPAPI key storage, nor have the developers even heard of it.
Fortunately we haven't actually encountered production problems yet, but I suspect it's only a matter of time. Years ago I asked MS to document how and where ASP.NET Core uses DPIAPI internally, but it was decided to treat that as an internal implementation detail that would remain undocumented. This suggests many of our systems could unexpectedly break some day with hard-to-diagnose failures, hence my very high level of concern about the problem.
The longer it takes to surface this concern more visibly, the more apps we'll see in production that don't account for proper key storage.
As some of the MS people like to say, help devs "fall into the pit of success"!
I believe the ASP.NET Core MVC template should explicitly configure ephemeral Data Protection API key storage in the
ConfigureServicesmethod along with a comment indicating that developers should change this for production deployments. Or perhaps even anenv.IsDevelopmenttest like theUseDeveloperExceptionPageif-else block in theConfiguremethod, with no implementation and some sort of// TODO - configure for productioncomment in the non-develseblock.Although the web farm deployment docs mention DPAPI key storage configuration, I am finding most corporate developers have zero awareness of the importance of this consideration, nor any awareness of the problems which may arise by failing to account for this. While I was glad to see key storage mentioned in the built-in log output, it is written as an "Information" level event which is normally disabled in production deployments. (I would prefer to see ephemeral storage written as a "Warning" event, which our log-monitoring solutions would then "see" in production, but that's a topic for an issue elsewhere.)
Some background about my experience with this problem: I work in a large corporate environment with more than 100,000 custom internal-use applications, about 70% of which are .NET-based. Our web-based apps run on groups of anywhere from eight to 32 servers on average (and in some cases many, many more). These apps are very slowly being migrated off .NET Framework, and in ALL of the ASP.NET Core apps I have reviewed over the past three years, none of them have configured DPAPI key storage, nor have the developers even heard of it.
Fortunately we haven't actually encountered production problems yet, but I suspect it's only a matter of time. Years ago I asked MS to document how and where ASP.NET Core uses DPIAPI internally, but it was decided to treat that as an internal implementation detail that would remain undocumented. This suggests many of our systems could unexpectedly break some day with hard-to-diagnose failures, hence my very high level of concern about the problem.
The longer it takes to surface this concern more visibly, the more apps we'll see in production that don't account for proper key storage.
As some of the MS people like to say, help devs "fall into the pit of success"!