11

We have an ASP.NET core 2.2 web application exposing some web api controllers. Our application does not have any kind of authentication mechanism, all the exposed endpoints can be called by an anonymous user.

When we host the application under IIS we get three strange warning messages at the application startup. These are the logs we get:

  1. Using an in-memory repository. Keys will not be persisted to storage.
  2. Neither user profile nor HKLM registry available. Using an ephemeral key repository. Protected data will be unavailable when application exits.
  3. No XML encryptor configured. Key {GUID} may be persisted to storage in unencrypted form.

All these logs have Microsoft.AspNetCore.DataProtection as the log context and are written by the ASP.NET core framework internals.

The meaning of these logs seems quite clear to me: there is a "key" (whatever it means) that will be persisted in-memory because no registry storage has been provided (and, of course, it will be lost when the application exits). There is also a warning indicating that this key, if persisted, won't be encrypted in any way.

At this point I would ask the following questions:

  • what is the GUID reported inside the logs with the name "key" ? What is used for ?
  • is there any security risk associated with this warnings ?
  • should I take any action ?

SOME ADDITIONAL INFORMATION:

Some blogs online suggest that these kind of data protection warnings are related to the usage of ASP.NET identity, but we don't use identity in our app (we have no authentication enabled). Other blogs suggests to setup the hosting application pool in order to load the user profile: I already tried that, but the warnings are still there.

IMPORTANT UPDATE 2nd April 2019

I solved the issue thanks to the help of the asp.net core dev team. For a complete reference see the github issue I opened yesterday

Put it briefly the issue is related to the IIS configuration on my development machine. In order for the ASP.NET core data protection to work as expected there are some specific configuration for IIS and the hosting application pool (see here for a complete reference)

UPDATE 13th SEPTEMBER 2019

For the ones having the same warnings inside their ASP.NET core 2.2 web applications I suggest to take a look at this github issue.

We now have added cookie authentication to our product and we need to support the kubernetes hosting. In kubernetes with the cookie authentication the warnings discussed in this stackoverflow question are relevant, because you have to provide ASP.NET core with a place where storing the keys needed by the ASP.NET core data protection system.

We opted to implement a persistent key ring in MongoDB. Some details can be found here. I can't show the code here (the project is not open source), but we have basically started from the official entity framework core key ring store and substituted all the usages of entity framework db context with an injected IMongoCollection<DataProtectionKey>. We have also modified the DataProtectionKey class by removing the Id property (we prefer letting MongoDB generating its own object ids).

Enrico Massone
  • 6,464
  • 1
  • 28
  • 56

3 Answers3

7

Data Protection is used by various components to encrypt data at runtime, for example:

  • Authentication cookies
  • Identity password reset tokens

You can read more about it in the docs: https://learn.microsoft.com/en-us/aspnet/core/security/data-protection/introduction

You understood the warnings correctly, it has created a key but couldn't decide where to store the key. So it'll be lost if the app restarts. If you don't use e.g. authentication cookies, you may be able to ignore these warnings. You can also configure a storage location, outside your app's folder.

joostas
  • 485
  • 5
  • 10
juunas
  • 54,244
  • 13
  • 113
  • 149
  • the cookie you are talking about are the cookie used by ASP.NET identity in order to serialize the principal and maintain the user identity between requests ? – Enrico Massone Apr 01 '19 at 10:26
  • Yes, I'm talking about those :) – juunas Apr 01 '19 at 10:28
  • we don't use any authentication, we don't even call app.UseAuthentication() in our Startup class. That said, I guess we can safely ignore the warnings based on what you explained me – Enrico Massone Apr 01 '19 at 10:29
  • Yeah, just be on the lookout for exceptions related to data protection, in case something you use uses Data Protection without your knowledge of it. – juunas Apr 01 '19 at 10:31
3

If you're not using any authentication mechanism (ex: ASP.NET Core Identity which is using this type of keys) and if you're not using DataProtection API somewhere else you're good to go (for now).

What happens there?

You entered a fallback mechanism for storing keys (in memory storage). You will lose your keys when your app will get restarted.

What problems you can face?

Example: If you're using authentication mechanisms, you will end up with screwed authentication cookies, email validation tokens, reset password tokens, etc

What you can do right now?

If you want (future-proof solution) you can store the keys somewhere (ex: Redis).

Further reading: https://cypressnorth.com/programming/solved-using-memory-repository-keys-will-not-persisted-storage-asp-net-core-iis/

Razvan Dumitru
  • 11,815
  • 5
  • 34
  • 54
  • 2
    so if I understood well, in a scenario where you don't need authorization cookies, email address validations and / or password resets (put another way, the set of features offered by ASP.NET identity), you can safely ignore the warnings. Is it correct ? – Enrico Massone Apr 01 '19 at 10:32
  • I read the article you linked and I checked my application pool. It is configured as suggested in the article.Nevertheless, IIS is not able to persist the encryption key in its registry (which should be it's default strategy). Do you have any idea on why it is not working ? – Enrico Massone Apr 01 '19 at 11:06
  • @EnricoMassone Yes you can ignore the warnings. And, as juunas said above, take care when you add NuGet packages or when you're adding new code to your application. If you end up using DataProtection API you can get into many problems. About the solution in the article, i've never tried it. I don't really know why it isn't working for you. Maybe you're using a shared host that has other checks in place for being able to adjust registries. – Razvan Dumitru Apr 01 '19 at 11:27
2

ASP.Net core DataProtection stores keys in the HOME directory (/root/.aspnet/DataProtection-Keys) so when container restart keys are lost and this might crash the service.

This can be resolve by persisting key at

  • Persist key at the persistent location (volume) and mount that volume to docker container
  • Persist key at the external key store like Azure or Redis

More details about ASP.NET DataProtection:

https://learn.microsoft.com/en-us/aspnet/core/security/data-protection/configuration/overview?view=aspnetcore-3.1

https://learn.microsoft.com/en-us/aspnet/core/security/data-protection/introduction?view=aspnetcore-3.1

To mount an external volume (C:/temp-kyes) to docker container volume (/root/.aspnet/DataProtection-Keys) using following command

docker run -d -v /c/temp-keys:/root/.aspnet/DataProtection-Keys container-name

Also, You need to update your Starup.cs - ConfigureServices to configure DataProtection policy

services.AddDataProtection().PersistKeysToFileSystem(new DirectoryInfo(@"C:\temp-keys\"))
                .UseCryptographicAlgorithms(new AuthenticatedEncryptorConfiguration()
                {
                    EncryptionAlgorithm = EncryptionAlgorithm.AES_256_CBC,
                    ValidationAlgorithm = ValidationAlgorithm.HMACSHA256
                });
Niraj Trivedi
  • 2,370
  • 22
  • 24