From a552d5196424a62c22f1e6325fc25634ec7857bc Mon Sep 17 00:00:00 2001 From: Scott Addie Date: Fri, 13 Apr 2018 14:30:58 -0500 Subject: [PATCH] Data protection permissions warning patch --- .../security/data-protection/configuration/overview.md | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/aspnetcore/security/data-protection/configuration/overview.md b/aspnetcore/security/data-protection/configuration/overview.md index 9f133ffe3e..40449127ed 100644 --- a/aspnetcore/security/data-protection/configuration/overview.md +++ b/aspnetcore/security/data-protection/configuration/overview.md @@ -17,11 +17,7 @@ By [Rick Anderson](https://twitter.com/RickAndMSFT) When the Data Protection system is initialized, it applies [default settings](xref:security/data-protection/configuration/default-settings) based on the operational environment. These settings are generally appropriate for apps running on a single machine. There are cases where a developer may want to change the default settings, perhaps because their app is spread across multiple machines or for compliance reasons. For these scenarios, the Data Protection system offers a rich configuration API. > [!WARNING] -> Like configuration files the data protection key ring should be protected using appropriate permissions. While you can choose to encrypt keys at rest this does not protect against attackers being able to create -> new keys, which in turn can impact your application’s security. The storage location you configure Data Protection to use should have its access limited to the application itself, in much the same way you would choose -> to protect configuration files. For example, if you choose to store your key ring on disk you should use file system permissions to ensure only the identity your web application runs under has -> read, write and create access to that directory, if you chose to use Azure Table Storage only the web application should have the ability to read, write or create new entries in the table store etc. - +> Like configuration files, the data protection key ring should be protected using appropriate permissions. You can choose to encrypt keys at rest, but this doesn't prevent attackers from creating new keys. Consequently, your app's security is impacted. The storage location configured with Data Protection should have its access limited to the app itself, in much the same way you would choose to protect configuration files. For example, if you choose to store your key ring on disk, use file system permissions. Ensure only the identity under which your web app runs has read, write, and create access to that directory. If you use Azure Table Storage, only the web app should have the ability to read, write, or create new entries in the table store, etc. There's an extension method [AddDataProtection](/dotnet/api/microsoft.extensions.dependencyinjection.dataprotectionservicecollectionextensions.adddataprotection) that returns an [IDataProtectionBuilder](/dotnet/api/microsoft.aspnetcore.dataprotection.idataprotectionbuilder). `IDataProtectionBuilder` exposes extension methods that you can chain together to configure Data Protection options.