Resolución de errores de código de autenticación de mensajes (MAC) del estado de la vista

Seleccione idioma Seleccione idioma
Id. de artículo: 2915218 - Ver los productos a los que se aplica este artículo
Expandir todo | Contraer todo

¿Qué es el estado de la vista?

El estado de la vista es la información que viene y va entre las páginas de WebForms (.aspx) en una aplicación ASP.NET. El formato HTML para el campo __VIEWSTATE es similar al siguiente:

<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="..." />

Un ejemplo de un elemento que puede almacenarse en el campo __VIEWSTATE es el texto de un control de botón. Si un usuario hace clic en el botón, el controlador de eventos Button_Click podrá extraer el texto del botón del campo del estado de la vista. Consulte el tema Descripción general del estado de la vista ASP.NET en el sitio web de Microsoft Developer Network (MSDN) para obtener una descripción general más detallada del estado de la vista ASP.NET.

Ya que el campo __VIEWSTATE contiene información importante que se utiliza para reconstruir la página en el postback, asegúrese de que los atacantes no puedan alterar este campo. Si un atacante envió una carga __VIEWSTATE malintencionada, es posible que este engañe a la aplicación y realice una acción que, de lo contrario, no se habría realizado.

Para evitar este tipo de ataque de manipulación, el campo __VIEWSTATE se protege mediante un código de autenticación de mensajes (MAC). ASP.NET valida el MAC que se envía junto con la carga __VIEWSTATE cuando se produce el postback. La clave que se utiliza para calcular el MAC se especifica en el elemento <machineKey> de la aplicación en el archivo Web.config. Ya que el atacante no puede estimar el contenido del elemento <machineKey>, no puede ofrecer un MAC válido al intentar manipular la carga __VIEWSTATE. ASP.NET detectará que no se ha proporcionado un MAC válido y ASP.NET rechazará la solicitud malintencionada.

¿Qué provoca los errores de validación de MAC?

El formato del error de validación de MAC será parecido al del siguiente ejemplo:

Error de servidor en la aplicación '/'.

Error de validación MAC de Viewstate. Si esta aplicación se encuentra alojada en una granja web o clúster, asegúrese de que la configuración <machineKey> especifique el mismo algoritmo de validación o validationKey. AutoGenerate no se puede utilizar en un clúster.

Descripción: Se produjo una excepción no controlada durante la ejecución de la solicitud web actual. Revise el seguimiento de la pila para obtener más información acerca del error y dónde se originó en el código.

Detalles de la excepción: System.Web.HttpException: Error de validación MAC de Viewstate. Si esta aplicación se encuentra alojada en una granja web o clúster, asegúrese de que la configuración <machineKey> especifique el mismo algoritmo de validación o validationKey. AutoGenerate no se puede utilizar en un clúster.

Error de código fuente: [No hay líneas de fuente relevantes]

Archivo fuente: ... Línea: 0

Seguimiento de la pila:

[ViewStateException: Viewstate no válido.
IP del cliente: ::1
Puerto: 40653
Sitio de referencia: http://localhost:40643/MyPage.aspx
Ruta de acceso: /MyPage.aspx
Agente de usuario: Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; WOW64; Trident/6.0)
ViewState: ...]

[HttpException (0x80004005): Error de validación MAC de Viewstate. Si esta aplicación se encuentra alojada en una granja web o clúster, asegúrese de que la configuración <machineKey> especifique el mismo algoritmo de validación o validationKey. AutoGenerate no se puede utilizar en un clúster.

Consulte http://go.microsoft.com/fwlink/?LinkID=314055 para obtener más información.
System.Web.UI.ViewStateException.ThrowError(Exception inner, String persistedState, String errorPageMessage, Boolean macValidationError) +190
System.Web.UI.ViewStateException.ThrowMacValidationError(Exception inner, String persistedState) +46
System.Web.UI.ObjectStateFormatter.Deserialize(String inputString, Purpose purpose) +861
System.Web.UI.ObjectStateFormatter.System.Web.UI.IStateFormatter2.Deserialize(String serializedState, Purpose purpose) +51
System.Web.UI.Util.DeserializeWithAssert(IStateFormatter2 formatter, String serializedState, Purpose purpose) +67
System.Web.UI.HiddenFieldPageStatePersister.Load() +444
System.Web.UI.Page.LoadPageStateFromPersistenceMedium() +368
System.Web.UI.Page.LoadAllState() +109
System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +7959
System.Web.UI.Page.ProcessRequest(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +429
System.Web.UI.Page.ProcessRequest() +125
System.Web.UI.Page.ProcessRequestWithNoAssert(HttpContext context) +48
System.Web.UI.Page.ProcessRequest(HttpContext context) +234
ASP.mypage_aspx.ProcessRequest(HttpContext context) in ...:0
System.Web.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +1300
System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +140

Causa 1: La aplicación web se está ejecutando en una granja (entorno de varios servidores)

ASP.NET genera automáticamente una clave criptográfica para cada aplicación y almacena la clave en el subárbol del Registro HKCU. Esta clave que se genera de forma automática se utiliza si no hay un elemento <machineKey> no explícito en la configuración de la aplicación. Sin embargo, puesto que esta clave que se genera automáticamente se almacena en local en el equipo que creó la clave, este escenario provoca un problema en las aplicaciones que se ejecutan en una granja. Cada servidor de la granja generará su propia clave local y ninguno de los servidores de la granja acordarán qué clave usar. El resultado es que, si un generador genera una carga __VIEWSTATE que consume un servidor diferente, el usuario experimentará un error de validación de MAC.
  • Solución 1a: Crear un elemento <machineKey> explícito

    Si agrega un elemento <machineKey> explícito al archivo Web.config de la aplicación, el desarrollador indica a ASP.NET no usar la clave criptográfica generada automáticamente. Consulte el Apéndice A para ver las instrucciones sobre cómo generar un elemento <machineKey>. Después de que este elemento se agregue al archivo Web.config, vuelva a implementar la aplicación en cada servidor de la granja.

    Nota: algunos servicios de alojamiento web, como los sitios web de Microsoft Azure, realizan pasos para sincronizar cada clave que se genera automáticamente de la aplicación en los servidores back-end. Esto permite a las aplicaciones que no hayan especificado un elemento <machineKey> explícito seguir funcionando en estos entornos, incluso si la aplicación se ejecuta en una granja. Si la aplicación se ejecuta en un servicio de alojamiento de terceros, póngase en contacto con el proveedor de alojamiento para determinar si esta situación se aplica a usted.

  • Solución 1b: Habilitar la afinidad en el equilibrador de carga

    SI sus sitios funcionan detrás de un equilibrador de carga, puede habilitar la afinidad del servidor para que evite temporalmente el problema. Esto ayuda a garantizar que un cliente determinado solo interactúa con un servidor físico detrás del equilibrador de carga para que el mismo servidor genere y consuma todas las cargas criptográficas.

    Esto no puede considerarse una solución a largo plazo para el problema. Incluso si la afinidad del servidor está habilitada, la mayor parte de los equilibradores de carga redirigirán el cliente a un servidor físico distinto si el servidor general para el que se estableció la afinidad con los equilibradores de carga está desactivado. Esto provoca que el nuevo servidor rechace las cargas criptográficas (como __VIEWSTATE, vales de autenticación de formularios, tokens antifalsificación MVC y otros servicios) que tenga el cliente.

    Es preferible utilizar un elemento explícito <machineKey> y volver a implementar la aplicación que habilitar la afinidad del servidor.

Causa 2: El proceso de trabajo usa la identidad del grupo de aplicaciones IIS 7.0

Internet Information Services (IIS) 7.0 (Windows Vista, Windows Server 2008) introdujo la identidad de grupo de aplicaciones, un mecanismo de aislamiento que ayuda a ofrecer una mayor seguridad para servidores que ejecutan aplicaciones ASP.NET. Sin embargo, los sitios que se ejecutan bajo la identidad del grupo de aplicaciones no tienen acceso al registro HKCU. Esto ocurre cuando el tiempo de ejecución de ASP.NET almacena las claves <machineKey> que se generan automáticamente. El resultado es que ASP.NET no puede conservar la clave que se genera automáticamente cuando se restablece el grupo de aplicaciones. Por lo tanto, cada vez que se restablece w3wp.exe, se genera una nueva clave temporal.

Nota: este problema no existe en IIS 7.5 (Windows 7 y Windows Server 2008 R2) ni en versiones posteriores. En estas versiones de IIS, ASP.NET puede conservar las claves que se generan automáticamente en una ubicación distinta que permanece a pesar de los restablecimientos del grupo de aplicaciones.
  • Solución 2a: Usar la utilidad aspnet_regiis

    Las instalaciones de ASP.NET contienen una utilidad, aspnet_regiis.exe. Esta utilidad permite a la interfaz de ASP.NET con IIS realizar las configuraciones necesarias para ejecutar una aplicación administrada. Una de estas configuraciones crea las claves necesarias en el subárbol del Registro para habilitar la persistencia de las claves de equipo que se generan automáticamente.

    En primer lugar, debe determinar qué grupo de aplicaciones está utilizando su sitio. Esto puede determinarse usando la utilidad inetmgr incluida con IIS. Seleccione su sitio en la vista de árbol de la izquierda, haga clic con el botón secundario en Administrar sitio web y, a continuación, haga clic en Configuración avanzada. Aparecerá un cuadro de diálogo que mostrará el nombre del grupo de aplicaciones.

    Contraer esta imagenAmpliar esta imagen
    Configuración avanzada


    Para aplicar la técnica scaffolding a las claves de registro para un grupo de aplicaciones ASP.NET 4.0, siga estos pasos:
    1. Abra un símbolo del sistema administrativo.
    2. Busque el directorio apropiado, dependiendo de si el grupo de aplicaciones es de 32 bits o 64 bits:
      • Grupo de aplicaciones de 32 bits: cd /d %windir%\Microsoft.NET\Framework\v4.0.30319
      • Grupo de aplicaciones de 64 bits: cd /d %windir%\Microsoft.NET\Framework64\v4.0.30319

    3. Diríjase al directorio, escriba el siguiente comando y, a continuación, pulse Intro:

      aspnet_regiis -ga "IIS APPPOOL\app-pool-name".

    Si el grupo de aplicaciones es un grupo de aplicaciones ASP.NET 2.0 o 3.5, siga estos pasos:
    1. Abra un símbolo del sistema administrativo.
    2. Busque el directorio apropiado, dependiendo de si el grupo de aplicaciones es de 32 bits o 64 bits:
      • Grupo de aplicaciones de 32 bits: cd /d %windir%\Microsoft.NET\Framework\v2.0.50727
      • Grupo de aplicaciones de 64 bits: cd /d %windir%\Microsoft.NET\Framework64\v2.0.50727

    3. Diríjase al directorio, escriba el siguiente comando y, a continuación, pulse Intro:

      aspnet_regiis -ga "IIS APPPOOL\app-pool-name".

    Por ejemplo, si el grupo de aplicaciones tiene el nombre de Mi grupo de aplicaciones (como en la imagen anterior), ejecute el siguiente comando:
     
    aspnet_regiis -ga "IIS APPPOOL\My App Pool".


    Nota: es posible que los servicios del sistema APPHOSTSVC y WAS tengan que ejecutarse para que la utilidad aspnet_regiis resuelva los nombres IIS APPPOOL\* correctamente.

  • Solución 2b: Crear un elemento <machineKey> explícito

    Si agrega un elemento <machineKey> explícito al archivo Web.config de la aplicación, el desarrollador indica a ASP.NET no usar la clave criptográfica generada automáticamente. Consulte el Apéndice A para ver las instrucciones sobre cómo generar un elemento <machineKey>.


Causa 3: El grupo de aplicaciones se configura mediante LoadUserProfile=false

Si el grupo de aplicaciones se ejecuta con una identidad personalizada, puede que IIS no haya cargado el perfil de usuario para la identidad. Esto provoca que el registro HKCU no esté disponible para que ASP.NET conserve el elemento <machineKey> que se genera automáticamente. Por lo tanto, se generará una nueva clave automáticamente cada vez que se reinicie la aplicación. Consulte la sección Perfil de usuario en el sitio web de Microsoft para obtener más información.
  • Solución 3a: Usar la utilidad aspnet_regiis

    Las instrucciones para esta solución son las mismas que para la Solución 2a. Consulte la sección correspondiente para obtener más información.

  • Solución 3b: Utilizar un elemento <machineKey> explícito

    Si agrega un elemento <machineKey> explícito al archivo Web.config de la aplicación, el desarrollador indica a ASP.NET no usar la clave criptográfica generada automáticamente. Consulte el Apéndice A para ver las instrucciones sobre cómo generar un elemento <machineKey>.

  • Solución 3c: Preparar las claves de registro HKCU necesarias manualmente

    Si no puede ejecutar la utilidad aspnet_regiis, puede usar un script de Windows PowerShell para preparar las claves de registro apropiadas en HKCU. Consulte el Apéndice B para obtener más información.

  • Solución 3d: Establecer LoadUserProfile=true para este grupo de aplicaciones

    También puede habilitar la carga del perfil de usuario dentro de este grupo de aplicaciones. Esto hace que el subárbol del Registro HKLM, la carpeta temporal y otras ubicaciones de almacenamiento específicas del usuario estén disponibles para la aplicación. Sin embargo, esto puede provocar un uso mayor del disco o de la memoria para el proceso de trabajo. Consulte el elemento <processModel> para obtener más información sobre cómo habilitar esta configuración.

Causa 4: La propiedad Page.ViewStateUserKey cuenta con un valor incorrecto

Los desarrolladores de software pueden decidir usar la propiedad Page.ViewStateUserKey para agregar la protección antifalsificación de solicitudes entre sitios al campo __VIEWSTATE. Si utiliza la propiedad Page.ViewStateUserKey, se configura normalmente en un valor, como el identificador de sesión del usuario o el nombre de usuario del usuario actual. Las plantillas de proyecto para las aplicaciones de WebForms en Microsoft Visual Studio 2012 y versiones posteriores contienen plantillas que utilizan esta propiedad. Consulte el tema Page.ViewStateUserKey Property en el sitio web de Microsoft Developer Network (MSDN) para obtener más información.

Si se especifica la propiedad ViewStateUserKey, el valor se graba en __VIEWSTATE a la hora de generación. Cuando se consume el campo __VIEWSTATE, el servidor comprueba la propiedad ViewStateUserKey de la página actual y la valida en comparación con el valor que se utilizó para generar el campo __VIEWSTATE. Si los valores no coinciden, se rechaza la solicitud como potencialmente malintencionada.

Un ejemplo de un error relacionado con ViewStateUserKey sería un cliente que tiene dos pestañas abiertas en el explorador. El cliente ha iniciado sesión como Usuario A, y en la primera pestaña, aparece una página con __VIEWSTATE cuya propiedad ViewStateUserKey contiene el "Usuario A". En la segunda pestaña, el cliente cierra sesión y luego vuelve a iniciar sesión como Usuario B. El cliente vuelve a la primera pestaña y envía el formulario. La propiedad ViewStateUserKey puede contener "Usuario B" (porque esto es lo que la cookie de autenticación del cliente indica). Sin embargo, el campo __VIEWSTATE que envió el cliente contiene "Usuario A." Esta falta de coincidencia provoca el error.
  • Solución 4a: Comprobar que el ViewStateUserKey se establece correctamente

    Si su aplicación utiliza la propiedad ViewStateUserKey, compruebe que el valor de la propiedad es la misma cuando se genere el estado de la vista y cuando se consuma. Si está utilizando el nombre de usuario del usuario que ha iniciado sesión actualmente, asegúrese de que el usuario sigue con la sesión iniciada y que la identidad de este no ha cambiado en el momento del postback. Si está utilizando el identificador de sesión del usuario actual, asegúrese de que no se ha terminado el tiempo de espera de la sesión.

    Si se está llevando a cabo la ejecución en un entorno de granja, asegúrese de que los elementos <machineKey> coinciden. Consulte Apéndice A para obtener instrucciones sobre cómo generar estos elementos.

Apéndice A: Cómo generar un elemento <machineKey>

Advertencia de seguridad

Existen muchos sitios web que generarán un elemento <machineKey> para usted con solo hacer clic en un botón. No utilice nunca un elemento <machineKey> obtenido a partir de uno de estos sitios. Es imposible saber si estas claves se generaron de forma segura o si se registraron en una base de datos secreta. Solo debe usar los elementos de configuración <machineKey> que cree usted mismo.


Para generar un elemento <machineKey> usted mismo, puede usar el siguiente script de Windows PowerShell:

# Genera un elemento <machineKey> que puede copiarse y pegarse en un archivo Web.config.
function Generate-MachineKey {
  [CmdletBinding()]
  param (
    [ValidateSet("AES", "DES", "3DES")]
    [string]$decryptionAlgorithm = 'AES',
    [ValidateSet("MD5", "SHA1", "HMACSHA256", "HMACSHA384", "HMACSHA512")]
    [string]$validationAlgorithm = 'HMACSHA256'
  )
  process {
    function BinaryToHex {
        [CmdLetBinding()]
        param($bytes)
        process {
            $builder = new-object System.Text.StringBuilder
            foreach ($b in $bytes) {
              $builder = $builder.AppendFormat([System.Globalization.CultureInfo]::InvariantCulture, "{0:X2}", $b)
            }
            $builder
        }
    }
    switch ($decryptionAlgorithm) {
      "AES" { $decryptionObject = new-object System.Security.Cryptography.AesCryptoServiceProvider }
      "DES" { $decryptionObject = new-object System.Security.Cryptography.DESCryptoServiceProvider }
      "3DES" { $decryptionObject = new-object System.Security.Cryptography.TripleDESCryptoServiceProvider }
    }
    $decryptionObject.GenerateKey()
    $decryptionKey = BinaryToHex($decryptionObject.Key)
    $decryptionObject.Dispose()
    switch ($validationAlgorithm) {
      "MD5" { $validationObject = new-object System.Security.Cryptography.HMACMD5 }
      "SHA1" { $validationObject = new-object System.Security.Cryptography.HMACSHA1 }
      "HMACSHA256" { $validationObject = new-object System.Security.Cryptography.HMACSHA256 }
      "HMACSHA385" { $validationObject = new-object System.Security.Cryptography.HMACSHA384 }
      "HMACSHA512" { $validationObject = new-object System.Security.Cryptography.HMACSHA512 }
    }
    $validationKey = BinaryToHex($validationObject.Key)
    $validationObject.Dispose()
    [string]::Format([System.Globalization.CultureInfo]::InvariantCulture,
      "<machineKey decryption=`"{0}`" decryptionKey=`"{1}`" validation=`"{2}`" validationKey=`"{3}`" />",
      $decryptionAlgorithm.ToUpperInvariant(), $decryptionKey,
      $validationAlgorithm.ToUpperInvariant(), $validationKey)
  }
}

Para aplicaciones ASP.NET 4.0, puede llamar a Generate-MachineKey sin los parámetros para generar un elemento <machineKey> de la siguiente forma.

PS> Generate-MachineKey
<machineKey decryption="AES" decryptionKey="..." validation="HMACSHA256" validationKey="..." />

Las aplicaciones ASP.NET 2.0 y 3.5 no son compatibles con HMACSHA256. En su lugar, puede especificar SHA1 para generar un elemento <machineKey> complemento de la siguiente forma:

PS> Generate-MachineKey -validation sha1
<machineKey decryption="AES" decryptionKey="..." validation="SHA1" validationKey="..." />

Tan pronto como disponga de un elemento <machineKey>, puede ponerlo en el archivo Web.config. El elemento <machineKey> solo es válido en el archivo Web.config en la raíz de la aplicación y no es válido en el nivel de subcarpeta.

<configuration>
  <system.web>
    <machineKey ... />
  </system.web>
</configuration>

Para obtener una lista completa de los algoritmos compatibles, ejecute help Generate-MachineKey desde el símbolo del sistema de Windows PowerShell.

Apéndice B: Preparar el registro para conservar las claves que se generan automáticamente

De forma predeterminada, debido a que las claves que se generan automáticamente ASP.NET permanecen en el registro HKCU, pueden perderse si el perfil del usuario no se ha guardado en el proceso de trabajo IIS y, a continuación, se recicla el grupo de aplicaciones. Esta situación podría afectar a los proveedores de alojamiento compartidos que ejecutan grupos de aplicaciones como cuentas de usuario de Windows estándar.

Para evitar esta situación, ASP.NET permite la conservación de las claves que se generan automáticamente en el registro HKLM en lugar del registro HKCU. Normalmente, esto se realiza mediante la utilidad aspnet_regiis (vea las instrucciones en la "Solución 2a: Utilice la sección de la utilidad aspnet_regiis. Sin embargo, para los administradores que no deseen ejecutar esta utilidad, puede utilizarse el siguiente script en Windows PowerShell:

# Prepara el registro HKLM para que la cuenta de usuario especificada pueda conservar las claves del equipo que se generan automáticamente.
function Provision-AutoGenKeys {
  [CmdletBinding()]
  param (
    [ValidateSet("2.0", "4.0")]
    [Parameter(Mandatory = $True)]
    [string] $frameworkVersion,
    [ValidateSet("32", "64")]
    [Parameter(Mandatory = $True)]
    [string] $architecture,
    [Parameter(Mandatory = $True)]
    [string] $upn
  )
  process {
    # Se requieren permisos de administrador para continuar.
    if (-Not (new-object System.Security.Principal.WindowsPrincipal([System.Security.Principal.WindowsIdentity]::GetCurrent())).IsInRole([System.Security.Principal.WindowsBuiltInRole]::Administrator)) {
        Error de escritura "Este cmdlet requiere permisos de administrador".
        return
    }
    # Abrir HKLM con una vista apropiada en el registro
    if ($architecture -eq "32") {
        $regView = [Microsoft.Win32.RegistryView]::Registry32;
    } else {
        $regView = [Microsoft.Win32.RegistryView]::Registry64;
    }
    $baseRegKey = [Microsoft.Win32.RegistryKey]::OpenBaseKey([Microsoft.Win32.RegistryHive]::LocalMachine, $regView)
    # Abrir clave base ASP.NET
    if ($frameworkVersion -eq "2.0") {
        $expandedVersion = "2.0.50727.0"
    } else {
        $expandedVersion = "4.0.30319.0"
    }
    $aspNetBaseKey = $baseRegKey.OpenSubKey("SOFTWARE\Microsoft\ASP.NET\$expandedVersion", $True)
    # Crear la clave secundaria AutoGenKeys si ya existe
    $autoGenBaseKey = $aspNetBaseKey.OpenSubKey("AutoGenKeys", $True)
    if ($autoGenBaseKey -eq $null) {
        $autoGenBaseKey = $aspNetBaseKey.CreateSubKey("AutoGenKeys")
    }
    # Obtener SID para el usuario en cuestión, que nos permitirá obtener la subclave AutoGenKeys
    $sid = (New-Object System.Security.Principal.WindowsIdentity($upn)).User.Value
    # El sistema, los administradores y el SID de destino obtienen acceso completo
    $regSec = New-Object System.Security.AccessControl.RegistrySecurity
    $regSec.SetSecurityDescriptorSddlForm("D:P(A;OICI;GA;;;SY)(A;OICI;GA;;;BA)(A;OICI;GA;;;$sid)")
    $userAutoGenKey = $autoGenBaseKey.OpenSubKey($sid, $True)
    if ($userAutoGenKey -eq $null) {
        # No existe la subclave; crear y ACL adecuadamente
        $userAutoGenKey = $autoGenBaseKey.CreateSubKey($sid, [Microsoft.Win32.RegistryKeyPermissionCheck]::Default, $regSec)
    } else {
        # Existía la subclave; asegúrese de que las ACL son correctas
        $userAutoGenKey.SetAccessControl($regSec)
    }
  }
}

El siguiente ejemplo muestra cómo preparar las entradas de registro HKLM apropiadas para un grupo de aplicaciones que se ejecuta como usuario, ejemplo@contoso.com (este es el UPN de la cuenta de usuario de Windows). Este grupo de aplicaciones es un grupo de aplicaciones de 32 bits que está ejecutando CLR v2.0 (ASP.NET 2.0 o 3.5).

PS> Provision-AutoGenKeys -FrameworkVersion 2.0 -Architecture 32 -UPN "example@contoso.com"

Si el grupo de aplicaciones es un grupo de aplicaciones de 64 bits que ejecuta CLR v4.0 (ASP.NET 4.0 o 4.5), el comando es como el siguiente:

PS> Provision-AutoGenKeys -FrameworkVersion 4.0 -Architecture 64 -UPN "example@contoso.com"

A pesar de que las claves que se generan automáticamente se almacenan en HKLM, la subclave de registro que ostenta el material criptográfico secreto de cada cuenta se agrega a una lista de control de acceso (ACL) para que otras cuentas de usuario no puedan leer el material criptográfico.

Apéndice C: Cifrado del elemento <machineKey> en los archivos de configuración

Puede que los administradores de servidor no deseen que la información altamente confidencial como material de la clave <machineKey> tenga forma de texto sin formato en los archivos de configuración . En este caso, los administradores pueden decidir sacar provecho de la característica .NET Framework conocida como "configuración protegida". Esta característica le permite cifrar determinadas secciones de los archivos .config. Si se revela el contenido de estos archivos de configuración, el contenido de estas secciones seguirá siendo secreto.

Puede encontrar una breve descripción general de la configuración protegida en el sitio web de MSDN. También contiene un tutorial sobre cómo proteger los elementos <connectionStrings> y <machineKey> del archivo Web.config.
Nota: es un artículo de "PUBLICACIÓN RÁPIDA" creado directamente por la organización de soporte técnico de Microsoft. La información aquí contenida se proporciona como está, como respuesta a problemas que han surgido. Como consecuencia de la rapidez con la que lo hemos puesto disponible, los materiales podrían incluir errores tipográficos y pueden ser revisados en cualquier momento sin previo aviso. Vea las Condiciones de uso para otras consideraciones

Propiedades

Id. de artículo: 2915218 - Última revisión: viernes, 20 de junio de 2014 - Versión: 2.0
La información de este artículo se refiere a:
  • Microsoft .NET Framework 4.5.1 Release Candidate
  • Microsoft .NET Framework 4.5.1
  • Microsoft .NET Framework 4.5
  • Microsoft .NET Framework 4.0
  • Microsoft .NET Framework 3.5.1
  • Microsoft .NET Framework 3.5
  • Microsoft .NET Framework 2.0 Service Pack 2
  • Microsoft .NET Framework 1.1 Service Pack 1
Palabras clave: 
kbsecvulnerability kbsecurity kbsecbulletin kbfix kbexpertiseinter kbbug atdownload KB2915218

Enviar comentarios

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com