ASP.NET machineKey exposure and key protection¶

What does this mean?¶

In ASP.NET Framework with System.Web, the machineKey configuration supports cryptographic protection for features such as forms-authentication tickets and ViewState. Exposed private keys can undermine those protections. This issue concerns server-side key material; putting an encrypted user password into a browser cookie is not an appropriate fix or session design.

Recommendation¶

Provision strong keys through a controlled deployment process, restrict access and use protected configuration where applicable. Keep plaintext keys out of repositories, logs, downloadable backups and public diagnostics. For a web farm, instances that share protected data need a coordinated key configuration; independent automatic keys are not interchangeable. Microsoft's MachineKeySection reference explains this requirement.

Sample code¶

These alternatives belong in a one-off Windows/.NET Framework deployment tool, not a request handler. Assume config is the target application's loaded System.Configuration.Configuration, and its machineKey section already contains the intended deployment-provisioned keys. The unsafe example assumes the section is unprotected. No key values are shown.

Unsafe storage step: persist an unprotected key section.

var section = config.GetSection("system.web/machineKey");
section.SectionInformation.ForceSave = true;
config.Save(ConfigurationSaveMode.Modified);

Safer storage step: protect the section before saving.

var section = config.GetSection("system.web/machineKey");
if (!section.SectionInformation.IsProtected)
{
    section.SectionInformation.ProtectSection(
        "RsaProtectedConfigurationProvider");
}
section.SectionInformation.ForceSave = true;
config.Save(ConfigurationSaveMode.Modified);

Provision the RSA provider's key container and grant only the required application/deployment identities access. Back up and protect that container through the deployment's recovery process. ProtectSection protects configuration at rest; it cannot defend against an already compromised process that may decrypt the section.

Check the deployment¶

In a disposable IIS application, confirm the saved section is protected without printing its plaintext, and verify the actual application-pool identity can use it. Test restart, restore and all farm nodes before rollout. A key change can invalidate existing tickets or protected data; coordinate rotation and rollback rather than changing keys casually.

ASP.NET Core distinction¶

ASP.NET Core uses Data Protection, not this System.Web machineKey setting. Configure its key persistence, access and protection for the hosting model. Use the framework's authentication facilities; do not store recoverable login passwords in cookies.

See hardcoded keys, ViewState integrity and session fixation.