ROPC remediation - more files with connection strings (#33990)

Author: tdykstra

aspnetcore/performance/caching/distributed/samples/8.x/RedisCache/appsettings.json

@@ -7,6 +7,6 @@
   },
   "AllowedHosts": "*",
   "ConnectionStrings": {
-    "MyAzureRedisConStr": "<cache name>.redis.cache.windows.net,abortConnect=false,ssl=true,allowAdmin=true,password=<primary-access-key>"
+    "MyAzureRedisConStr": "<connection string>"
   }
 }

aspnetcore/security/app-secrets.md

@@ -5,12 +5,13 @@ description: Learn how to store and retrieve sensitive information during the de
 ms.author: tdykstra
 monikerRange: '>= aspnetcore-3.0'
 ms.custom: mvc
-ms.date: 10/29/2024
+ms.date: 10/30/2024
 uid: security/app-secrets
 ---
 <!-- ms.sfi.ropc: t -->
 # Safe storage of app secrets in development in ASP.NET Core
 
+
 [!INCLUDE[](~/includes/not-latest-version.md)]
 
 :::moniker range=">= aspnetcore-6.0"
@@ -19,7 +20,7 @@ By [Rick Anderson](https://twitter.com/RickAndMSFT) and [Kirk Larkin](https://tw
 
 [View or download sample code](https://github.com/dotnet/AspNetCore.Docs/tree/main/aspnetcore/security/app-secrets/samples) ([how to download](xref:index#how-to-download-a-sample))
 
-This article explains how to manage sensitive data for an ASP.NET Core app on a development machine. Never store passwords or other sensitive data in source code or configuration files. Production secrets shouldn't be used for development or test. Secrets shouldn't be deployed with the app.  Production secrets should be accessed through a controlled means like Azure Key Vault. Azure test and production secrets can be stored and protected with the [Azure Key Vault configuration provider](xref:security/key-vault-configuration).
+This article explains how to manage sensitive data for an ASP.NET Core app on a development machine. Never store passwords or other sensitive data in source code or configuration files. Production secrets shouldn't be used for development or test. Secrets shouldn't be deployed with the app. Production secrets should be accessed through a controlled means like Azure Key Vault. Azure test and production secrets can be stored and protected with the [Azure Key Vault configuration provider](xref:security/key-vault-configuration).
 
 For more information on authentication for deployed test and production apps, see [Secure authentication flows](xref:security/index#secure-authentication-flows).
 
@@ -201,21 +202,15 @@ The `Movies:ConnectionString` and `Movies:ServiceApiKey` secrets are mapped to t
 
 ## String replacement with secrets
 
-Storing passwords in plain text is insecure. For example, a database connection string stored in `appsettings.json` may include a password for the specified user:
-
-[!code-json[](~/security/app-secrets/samples/3.x/UserSecrets/appsettings-unsecure.json?highlight=3)]
+Storing passwords in plain text is insecure. Never store secrets in a configuration file such as `appsettings.json`, which might get checked in to a source code repository.
 
-A more secure approach is to store the password as a secret. For example:
+For example, a database connection string stored in `appsettings.json` should not include a password. Instead, store the password as a secret, and include the password in the connection string at runtime. For example:
 
 ```dotnetcli
-dotnet user-secrets set "DbPassword" "pass123"
+dotnet user-secrets set "DbPassword" "`<secret value>`"
 ```
 
-Remove the `Password` key-value pair from the connection string in `appsettings.json`. For example:
-
-[!code-json[](~/security/app-secrets/samples/3.x/UserSecrets/appsettings.json?highlight=3)]
-
-The secret's value can be set on a <xref:System.Data.SqlClient.SqlConnectionStringBuilder> object's <xref:System.Data.SqlClient.SqlConnectionStringBuilder.Password%2A> property to complete the connection string:
+Replace the `<secret value>` placeholder in the preceding example with the password value. Set the secret's value on a <xref:System.Data.SqlClient.SqlConnectionStringBuilder> object's <xref:System.Data.SqlClient.SqlConnectionStringBuilder.Password%2A> property to include it as the password value in the connection string:
 
 [!code-csharp[](~/security/app-secrets/samples/6.x/UserSecrets/Program.cs?name=snippet_sql&highlight=5-8)]
 

aspnetcore/security/app-secrets/includes/app-secrets-3-5.md

@@ -8,6 +8,7 @@ By [Rick Anderson](https://twitter.com/RickAndMSFT), [Kirk Larkin](https://twitt
 This article explains how to manage sensitive data for an ASP.NET Core app on a development machine. Never store passwords or other sensitive data in source code or configuration files. Production secrets shouldn't be used for development or test. Secrets shouldn't be deployed with the app. Production secrets should be accessed through a controlled means like Azure Key Vault. Azure test and production secrets can be stored and protected with the [Azure Key Vault configuration provider](xref:security/key-vault-configuration).
 
 For more information on authentication for test and production environments, see [Secure authentication flows](xref:security/index#secure-authentication-flows).
+
 ## Environment variables
 
 Environment variables are used to avoid storage of app secrets in code or in local configuration files. Environment variables override configuration values for all previously specified configuration sources.
@@ -172,23 +173,17 @@ The `Movies:ConnectionString` and `Movies:ServiceApiKey` secrets are mapped to t
 
 ## String replacement with secrets
 
-Storing passwords in plain text is insecure. For example, a database connection string stored in `appsettings.json` may include a password for the specified user:
-
-[!code-json[](~/security/app-secrets/samples/3.x/UserSecrets/appsettings-unsecure.json?highlight=3)]
+Storing passwords in plain text is insecure. Never store secrets in a configuration file such as `appsettings.json`, which might get checked in to a source code repository.
 
-A more secure approach is to store the password as a secret. For example:
+For example, a database connection string stored in `appsettings.json` should not include a password. Instead, store the password as a secret, and include the password in the connection string at runtime. For example:
 
 ```dotnetcli
-dotnet user-secrets set "DbPassword" "pass123"
+dotnet user-secrets set "DbPassword" "<secret value>"
 ```
 
-Remove the `Password` key-value pair from the connection string in `appsettings.json`. For example:
-
-[!code-json[](~/security/app-secrets/samples/3.x/UserSecrets/appsettings.json?highlight=3)]
-
-The secret's value can be set on a <xref:System.Data.SqlClient.SqlConnectionStringBuilder> object's <xref:System.Data.SqlClient.SqlConnectionStringBuilder.Password%2A> property to complete the connection string:
+Replace the `<secret value>` placeholder in the preceding example with the password value. Set the secret's value on a <xref:System.Data.SqlClient.SqlConnectionStringBuilder> object's <xref:System.Data.SqlClient.SqlConnectionStringBuilder.Password%2A> property to include it as the password value in the connection string:
 
-[!code-csharp[](~/security/app-secrets/samples/3.x/UserSecrets/Startup2.cs?name=snippet_StartupClass&highlight=14-17)]
+[!code-csharp[](~/security/app-secrets/samples/6.x/UserSecrets/Program.cs?name=snippet_sql&highlight=5-8)]
 
 ## List the secrets
 

aspnetcore/security/app-secrets/samples/2.x/UserSecrets/appsettings-unsecure.json

@@ -8,6 +8,5 @@
   },
   "ConnectionStrings": {
     "Movies": "Server=(localdb)\\mssqllocaldb;Database=Movie-1;User Id=johndoe;MultipleActiveResultSets=true"
-  },
-  "DbPassword": "MySecret"
+  }
 }

aspnetcore/security/app-secrets/samples/3.x/UserSecrets/appsettings-unsecure.json

@@ -1,4 +1,5 @@
 :::moniker range=">= aspnetcore-6.0 <= aspnetcore-8.0"
+<!-- ms.sfi.ropc: t -->
 
 By [Damien Bowden](https://github.com/damienbod)
 

aspnetcore/security/app-secrets/samples/6.x/UserSecrets/appsettings.Development.json

@@ -5,10 +5,11 @@ description: Learn how to configure Data Protection in ASP.NET Core.
 monikerRange: '>= aspnetcore-3.1'
 ms.author: tdykstra
 ms.custom: mvc
-ms.date: 6/14/2023
+ms.date: 10/30/2024
 uid: security/data-protection/configuration/overview
 ---
 # Configure ASP.NET Core Data Protection
+<!-- ms.sfi.ropc: t -->
 
 :::moniker range=">= aspnetcore-6.0"
 
@@ -317,6 +318,8 @@ services.AddDataProtection()
     .ProtectKeysWithAzureKeyVault(new Uri("<keyIdentifier>"), new DefaultAzureCredential());
 ```
 
+[!INCLUDE [managed-identities](~/includes/managed-identities-conn-strings.md)]
+
 ## PersistKeysToFileSystem
 
 To store keys on a UNC share instead of at the *%LOCALAPPDATA%* default location, configure the system with <xref:Microsoft.AspNetCore.DataProtection.DataProtectionBuilderExtensions.PersistKeysToFileSystem%2A>:

aspnetcore/security/authentication/mfa/includes/mfa-5-8.md

@@ -5,10 +5,10 @@ description: Learn how to set up a Redis backplane to enable scale-out for an AS
 monikerRange: '>= aspnetcore-2.1'
 ms.author: wpickett
 ms.custom: mvc
-ms.date: 02/06/2024
+ms.date: 10/31/2024
 uid: signalr/redis-backplane
 ---
-
+<!-- ms.sfi.ropc: t -->
 # Set up a Redis backplane for ASP.NET Core SignalR scale-out
 
 By [Andrew Stanton-Nurse](https://twitter.com/anurse), [Brady Gaster](https://twitter.com/bradygaster), and [Tom Dykstra](https://github.com/tdykstra).
@@ -17,6 +17,8 @@ By [Andrew Stanton-Nurse](https://twitter.com/anurse), [Brady Gaster](https://tw
 
 This article explains SignalR-specific aspects of setting up a [Redis](https://redis.io/) server to use for scaling out an ASP.NET Core SignalR app.
 
+[!INCLUDE [managed-identities](~/includes/managed-identities-conn-strings.md)]
+
 ## Set up a Redis backplane
 
 * Deploy a Redis server.

aspnetcore/security/data-protection/configuration/overview.md

@@ -1,7 +1,10 @@
 :::moniker range="> aspnetcore-2.0 <= aspnetcore-5.0"
+<!-- ms.sfi.ropc: t -->
 
 This article explains SignalR-specific aspects of setting up a [Redis](https://redis.io/) server to use for scaling out an ASP.NET Core SignalR app.
 
+[!INCLUDE [managed-identities](~/includes/managed-identities-conn-strings.md)]
+
 ## Set up a Redis backplane
 
 * Deploy a Redis server.