In this article we will talk about a very important aspect concerning the security settings introduced with ASP.NET Core: Data Protection APIs, a set of interfaces that determine the functioning of the security keys used within our application.
As probably many developers already know, ASP.NET Core applications use a set of security keys to perform multiple encrypt, decrypt and validate the various tokens that are issued by the various authorization and authentication middleware: bearer token, session, antiforgery, tokens that identify the user's password change requests, etc .; each of these tokens is automatically generated by the application using a unique set of security keys, so as to minimize the risk that a malicious attacker could equip himself with the necessary tools to be able to generate "valid" tokens.
By default, ASP.NET Core security keys are generated in memory when the application is started. This is undoubtedly a very effective strategy for preventing the aforementioned malicious attacks, but it is certainly impractical for the ordinary management of most applications: in this way, in fact, every time the app is restarted, new keys will be generated. security, making it impossible to decrypt or identify previously released encrypted content: in practical terms this means that, for example, all encrypted cookies released up to that moment (including session cookies, "remembered" cookies me "etc) will be considered invalid, forcing users to re-enter their credentials. This type of inconvenience can be negligible when our web application is launched in the Development environment or in a Staging environment, but they could be very annoying for our user base when our app is published on a Production server.
To work around this problem, it is possible to configure a behavior other than the default one using the specific services.AddDataProtection() method inside the Startup.cs file (or Program.cs, for apps developed since .NET 6).
In the following example, the application is asked to generate the keys on a special folder /App_Keys/ (present on the FileSystem) and regenerate every 90 days:
|
1 2 3 4 5 |
services.AddDataProtection() .SetApplicationName("myApp") .SetDefaultKeyLifetime(TimeSpan.FromDays(90)) .PersistKeysToFileSystem(new DirectoryInfo("/App_Keys/")); } |
For the code above to work, you need to do the following on the server machine:
- Create the /App_Keys/ folder inside the publish folder.
Set the write permissions for the IIS_IUSRS user (or for the user related to the Application Pool used).
In the absence of this folder or the write permissions, the application in production will give an error, as it will not be able to store the security keys on disk.
Obviously, the hypothesis of persisting the security keys on FileSystem is only one of the possible alternatives: the Data Protection APIs allow you to implement even more secure and effective storage solutions, such as through the use of Azure Key Vault or other Key Storage Providers, i.e. services that allow the secure storage of credentials.
For further info about this topic, we recommend consulting the Key Storage Providers configuration guide on Microsoft Docs.
Affinché il codice di cui sopra funzioni, è necessario svolgere le seguenti operazioni sulla macchina server:
