Řešení chyb kódu ověřování zpráv stavu zobrazení (MAC)

Co je stav zobrazení?

Stav zobrazení je informace, které jsou v aplikaci ASP.NET kruhové zakopnutí mezi stránkami WebForms (. aspx). Značky jazyka HTML pro pole __VIEWSTATE se podobají následujícímu:

< input type = "skrytý" název = "__VIEWSTATE" ID = "__VIEWSTATE" hodnota = "..."/>Jedním z příkladů položky, která může být uložena v poli __VIEWSTATE, je text ovládacího prvku Button. Pokud uživatel klikne na tlačítko, obslužná rutina události Button_Click bude moci extrahovat text tlačítka z pole stavu zobrazení. Podrobnější přehled o stavu zobrazení ASP.NET naleznete v tématu Přehled stavu zobrazení ASP.NET na webu MSDN (Microsoft Developer Network). Protože pole __VIEWSTATE obsahuje důležité informace, které slouží k rekonstrukci stránky při postbacku, ujistěte se, že Útočník nemůže s tímto polem manipulovat. Pokud by útočník předložil škodlivý datový typ __VIEWSTATE, mohl by potenciálně přimět aplikaci k provedení akce, kterou by jinak nebylo možné provést. Aby se zabránilo tomuto druhu napadení, je pole __VIEWSTATE chráněno ověřovacím kódem zprávy (MAC). ASP.NET ověřuje MAC, který je odeslán společně s datovou částí __VIEWSTATE v případě, že dojde k postbacku. Klíč, který se používá k výpočtu MAC, je specifikován v elementu aplikace v souboru Web. config. Protože Útočník nemůže uhodnout obsah elementu < machineKey >, nemůže útočník poskytnout platný kód MAC, pokud se útočník pokusí o manipulaci s datovou částí __VIEWSTATE. ASP.NET rozpozná, že nebyl poskytnut platný MAC, a ASP.NET bude škodlivý požadavek odmítnut.

Co způsobuje chyby ověřování MAC?

Chyba ověření MAC bude vypadat podobně jako v následujícím příkladu:

Chyba serveru v aplikaci '/'. Ověření kódu MAC vlastnosti ViewState se nezdařilo. Pokud je hostitelem této aplikace webová farma nebo cluster, ujistěte se, že konfigurace < machineKey > určuje stejný klíč validationKey a ověřovací algoritmus. Funkci AutoGenerate nelze použít v clusteru. Popis: při provádění aktuálního webového požadavku došlo k nezpracované výjimce. Další informace o chybě a její původ v kódu naleznete v trasování zásobníku. Podrobnosti o výjimce: System. Web. HttpException: ověření MAC ViewState se nezdařilo. Pokud je hostitelem této aplikace webová farma nebo cluster, ujistěte se, že konfigurace < machineKey > určuje stejný klíč validationKey a ověřovací algoritmus. Funkci AutoGenerate nelze použít v clusteru. Chyba zdroje: [žádné relevantní zdrojové řádky] Zdrojový soubor:... Přímce: 0 Trasování zásobníku: [ViewStateException: neplatný stav zobrazení. Adresa IP klienta::: 1 Přístav: 40653 Odkazující server: http://localhost:40643/MyPage.aspx Cesta:/MyPage.aspx User-Agent: Mozilla/5.0 (kompatibilní; MSIE 10,0; Windows NT 6,2; WOW64 Trident/6.0) Stav zobrazení:...] [HttpException (0x80004005): ověření kódu MAC vlastnosti ViewState se nezdařilo. Pokud je hostitelem této aplikace webová farma nebo cluster, ujistěte se, že konfigurace < machineKey > určuje stejný klíč validationKey a ověřovací algoritmus. Funkci AutoGenerate nelze použít v clusteru. Další informace naleznete v http://go.microsoft.com/fwlink/?LinkID=314055.] System. Web. UI. ViewStateException. ThrowError (výjimka vnitřní, String persistedState, řetězcový errorPageMessage, logická hodnota macValidationError) + 190 System. Web. UI. ViewStateException. ThrowMacValidationError (vnitřní výjimka, String persistedState) + 46 System. Web. UI. ObjectStateFormatter. deserializovat (řetězec inputString, účel účelu) + 861 System. Web. UI. ObjectStateFormatter. System. Web. UI. IStateFormatter2. deserializovat (serializedState řetězce, účel účelu) + 51 System. Web. UI. util. DeserializeWithAssert (IStateFormatter2 Formatter, Serializedstav řetězce, účel účelu) + 67 System. Web. UI. HiddenFieldPageStatePersister. Load () + 444 System. Web. UI. Page. LoadPageStateFromPersistenceMedium () + 368 System. Web. UI. Page. LoadAllState () + 109 System. Web. UI. Page. ProcessRequestMain (logická hodnota includeStagesBeforeAsyncPoint, logická hodnota includeStagesAfterAsyncPoint) + 7959 System. Web. UI. Page. ProcessRequest (logická hodnota includeStagesBeforeAsyncPoint, logická hodnota includeStagesAfterAsyncPoint) + 429 System. Web. UI. Page. ProcessRequest () + 125 System. Web. UI. Page. ProcessRequestWithNoAssert (HttpContext Context) + 48 Systémová. Web. UI. Page. ProcessRequest (kontext HttpContext) + 234 ASP. mypage_aspx. ProcessRequest (kontext HttpContext) v...: 0 System. Web. Callhandlerexecutionkrok. System. Web. HttpApplication. Iexecutionkrok. Execute () + 1300 System. Web. HttpApplication. ExecuteStep (krok IExecutionStep, Boolean & Completedsynchronně) + 140

Příčina 1: webová aplikace je spuštěna ve farmě (prostředí s více servery).

ASP.NET automaticky generuje kryptografický klíč pro každou aplikaci a uloží klíč do podregistru HKCU. Tento automaticky generovaný klíč se používá v případě, že v konfiguraci aplikace neexistuje explicitní element < machineKey >. Avšak vzhledem k tomu, že tento automaticky generovaný klíč je místní v počítači, ve kterém byl klíč vytvořen, způsobí tento scénář problém u aplikací spouštěných ve farmě. Každý server ve farmě vygeneruje vlastní místní klíč a žádný ze serverů ve farmě nebude souhlasit s tím, který klíč použít. Výsledkem je, že pokud jeden server vygeneruje datovou část __VIEWSTATE, kterou spotřebovává jiný server, dojde u příjemce k chybě ověření MAC.

Řešení 1a: vytvoření explicitního elementu < machineKey > Přidáním explicitního elementu < machineKey > do souboru Web. config aplikace, vývojář oznámí, že ASP.NET nepoužívá automaticky generovaný kryptografický klíč. Pokyny pro vygenerování elementu < machineKey > naleznete v dodatku A . Po přidání tohoto prvku do souboru Web. config znovu nasaďte aplikaci na každý server ve farmě. Poznámka: Některé webové hostitelské služby, jako například weby Microsoft Azure, dělají kroky k synchronizaci automaticky generovaných klíčů každé aplikace na jejich serverech back-end. To umožňuje aplikacím, které nespecifikuje explicitní element < machineKey >, pokračovat v práci v těchto prostředích, i když je aplikace spuštěna ve farmě. Pokud je aplikace spuštěna v hostitelské službě jiného výrobce, obraťte se na poskytovatele hostitelských služeb a zjistěte, zda se tato situace týká vás.
Rozlišení 1b: Povolení spřažení v balanceru pro vyrovnávání zatížení Pokud vaše weby pracují za účelem vyrovnávání zatížení, můžete povolit spřažení serveru, aby se dočasně obešlo problém. To pomáhá zajistit, že každý daný klient pracuje pouze s jedním fyzickým serverem za pomocí služby Vyrovnávání zatížení, takže všechny kryptografické zátěže budou vygenerovány a spotřebovány stejným serverem. Toto by nemělo být považováno za dlouhodobé řešení problému. I v případě, že je povoleno spřažení serverů, bude většina balancovaných balíků přesměrovávat klienta na jiný fyzický server, pokud původní server, na který byly tyto balíky načteny, přechází do režimu offline. To způsobí, že nový server odmítne kryptografické zatížení (například __VIEWSTATE, ověřovací lístky formulářů, tokeny proti padělání MVCs a další služby), které má klient v současnosti. Použití explicitního elementu < machineKey > a opětovné nasazení aplikace by mělo být upřednostňováno před povolením spřažení serveru.

Příčina 2: pracovní proces používá identitu fondu aplikací služby IIS 7,0

Internetová informační služba (IIS) 7,0 (Windows Vista, Windows Server 2008) zavedla identitu fondu aplikacía nový mechanismus izolace, který pomáhá zajistit zvýšené zabezpečení pro servery, které spouštějí aplikace ASP.NET. Servery, které jsou spuštěny pod identitou fondu aplikací, však nemají přístup k registru HKCU. Toto je místo, kde modul runtime ASP.NET uchovává své automaticky generované klíče > < machineKey. Výsledkem je, že ASP.NET nemůže zachovat automaticky generovaný klíč při resetování fondu aplikací. Proto je při každém resetování souboru w3wp. exe generován nový dočasný klíč. Poznámka: Toto není problém ve službě IIS 7,5 (Windows 7, Windows Server 2008 R2) a novějších verzích. V těchto verzích služby IIS může ASP.NET uchovávat automaticky generované klíče v jiném umístění, které přežívá v obnovení fondu aplikací.

Usnesení 2a: použití nástroje Aspnet_regiis Instalace ASP.NET obsahují nástroj Aspnet_regiis. exe. Tento nástroj umožňuje ASP.NET rozhraní se službou IIS provádět konfigurace, které jsou požadovány ke spuštění spravované aplikace. Jedna z těchto konfigurací vytváří v podregistru registru potřebné klíče k povolení přetrvávání automaticky generovaných klíčů počítače. Nejprve je třeba určit, který fond aplikací váš web používá. To lze určit pomocí nástroje inetmgr , který je součástí služby IIS. Ve stromovém zobrazení vlevo vyberte web, klepněte pravým tlačítkem myši na položku Spravovat Website a pak klepněte na příkaz Upřesnit nastavení. Zobrazené dialogové okno zobrazí název fondu aplikací. Chcete-li provést lešení příslušných klíčů registru pro fond aplikací ASP.NET 4,0, postupujte následujícím způsobem:
1. Otevřete příkazový řádek pro správu.
2. V závislosti na tom, zda je fond aplikací 32 nebo 64, vyhledejte příslušný adresář:
  - 32-bitový fond aplikací: CD/D%windir%\Microsoft.NET\Framework\v4.0.30319
  - 64-bit fond aplikací: CD/D%windir%\Microsoft.NET\Framework64\v4.0.30319
3. Přejděte do adresáře, zadejte následující příkaz a stiskněte klávesu ENTER:
  
  aspnet_regiis-ga "IIS APPPOOL\app-pool-name"
Pokud je fond aplikací ve fondu aplikací ASP.NET 2,0 nebo 3,5, postupujte následujícím způsobem:
1. Otevřete příkazový řádek pro správu.
2. V závislosti na tom, zda je fond aplikací 32 nebo 64, vyhledejte příslušný adresář:
  - 32-bit fond aplikací: CD/D%windir%\Microsoft.NET\Framework\v2.0.50727
  - 64-bit fond aplikací: CD/D%windir%\Microsoft.NET\Framework64\v2.0.50727
3. Přejděte do adresáře, zadejte následující příkaz a stiskněte klávesu ENTER:
  
  aspnet_regiis-ga "IIS APPPOOL\app-pool-name"
Pokud se například fond aplikací jmenuje můj fond aplikace (jako v předchozím obrázku), spusťte následující příkaz:

aspnet_regiis-ga "IIS APPPOOL\My App Pool" Poznámka: Je možné, že systémové služby APPHOSTSVC a be budou muset být spuštěny pro nástroj Aspnet_regiis, který bude správně překládat názvy služby IIS APPPOOL \ *.
Řešení 2b: vytvoření explicitního prvku < machineKey > Přidáním explicitního elementu < machineKey > do souboru Web. config aplikace, vývojář oznámí, že ASP.NET nepoužívá automaticky generovaný kryptografický klíč. Pokyny pro vygenerování elementu < machineKey > naleznete v dodatku A .

Příčina 3: fond aplikací je konfigurován pomocí příkazu LoadUserProfile = false

Pokud je fond aplikací spuštěn s vlastní identitou, služba IIS pravděpodobně nenačte profil uživatele pro danou identitu. To má vedlejší účinek, že registr HKCU není přístupný pro ASP.NET, aby uchoval automaticky vygenerovaný < machineKey >. Proto bude nový automaticky generovaný klíč vytvořen při každém restartování aplikace. Další informace naleznete v části Profil uživatele na webu společnosti Microsoft.

Rozlišení 3a: použití nástroje Aspnet_regiis Pokyny pro tento postup jsou shodné s rozlišením 2a. Další informace naleznete v této části.
Rozlišení 3B: Použijte explicitní < machineKey > Přidáním explicitního elementu < machineKey > do souboru Web. config aplikace, vývojář oznámí, že ASP.NET nepoužívá automaticky generovaný kryptografický klíč. Pokyny pro vygenerování elementu < machineKey > naleznete v dodatku A .
Usnesení 3C: ruční zajištění požadovaných klíčů registru HKCU Pokud nelze spustit nástroj Aspnet_regiis, můžete pomocí skriptu prostředí Windows PowerShell zřídit příslušné klíče registru v HKCU. Další informace naleznete v dodatku B .
Rozlišení 3D: nastavení LoadUserProfile = true pro tento fond aplikací Můžete také povolit načítání profilu uživatele v rámci tohoto fondu aplikací. Tímto se vytvoří podregistr registru HKCU, dočasná složka a další uživatelská umístění specifická pro uživatele, která jsou k dispozici pro aplikaci. To však může způsobit zvýšené využití disku nebo paměti pro pracovní proces. Další informace o povolení tohoto nastavení naleznete v prvku .

Příčina 4: vlastnost Page. ViewStateUserKey má nesprávnou hodnotu.

Vývojáři softwaru se mohou rozhodnout použít vlastnost Page. ViewStateUserKey k přidání ochrany proti falšování požadavků mezi servery do pole __VIEWSTATE. Použijete-li vlastnost Page. ViewStateUserKey , je obvykle nastavena na hodnotu, jako je například uživatelské jméno aktuálního uživatele nebo identifikátor relace uživatele. Šablony projektů pro aplikace Microsoft Visual Studio 2012 a novější verze obsahují ukázky, které tuto vlastnost používají. Další informace naleznete v tématu o vlastnosti Page. ViewStateUserKey na webu MSDN (Microsoft Developer Network). Pokud je zadána vlastnost ViewStateUserKey , je její hodnota v době generování vypálena do __VIEWSTATE. Pokud je pole __VIEWSTATE spotřebováno, zkontroluje server vlastnost ViewStateUserKey aktuální stránky a ověří ji podle hodnoty, která byla použita ke generování pole __VIEWSTATE. Pokud se hodnoty neshodují, je požadavek odmítnut jako potenciálně škodlivý. Příkladem selhání souvisejícího s klíčem ViewStateUserKey by byl klient, který má v prohlížeči otevřeny dvě karty. Klient je přihlášen jako uživatel A a na první kartě je stránka vykreslena s __VIEWSTATE, jejíž vlastnost ViewStateUserKey obsahuje hodnotu uživatel A. Na druhé kartě se klient přihlásí a znovu přihlásí jako uživatel B. Klient přejde zpět na první kartu a odešle formulář. Vlastnost ViewStateUserKey může obsahovat hodnotu User B (protože to říká ověřovací soubor cookie klienta). Pole __VIEWSTATE, které klient vložil, však obsahuje "uživatel A". Tato neshoda způsobuje selhání.

Rozlišení 4a: Ověřte, zda je vlastnost ViewStateUserKey nastavena správně Pokud aplikace používá vlastnost ViewStateUserKey , ověřte, že hodnota vlastnosti je stejná, jak je generován stav zobrazení a kdy je spotřebováno. Pokud používáte aktuální uživatelské jméno přihlášeného uživatele, ujistěte se, že je uživatel stále přihlášen a že identita uživatele se v okamžiku postbacku nezměnila. Pokud používáte identifikátor relace aktuálního uživatele, ujistěte se, že relace není časově omezena. Pokud pracujete v prostředí farmy, ujistěte se, že elementy > < machineKey se shodují. Pokyny k vygenerování těchto prvků naleznete v dodatku A .

Dodatek A: generování elementu < machineKey >

Upozornění zabezpečení Existuje mnoho webových serverů, které vytvoří prvek < machineKey > klepnutím na tlačítko. Nikdy nepoužívejte element < machineKey >, který jste získali z jedné z těchto sítí. Nelze zjistit, zda byly tyto klíče vytvořeny bezpečně nebo zda jsou zaznamenávány do tajné databáze. Vždy byste měli použít konfigurační prvky < machineKey >, které jste sami vytvořili.

Chcete-li vygenerovat prvek < machineKey > sami, můžete použít následující skript prostředí Windows PowerShell :

# Generates a <machineKey> element that can be copied + pasted into a Web.config file.
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)
  }
}

Pro ASP.NET 4,0 aplikace můžete pouze volat generování-machineKey bez parametrů pro vygenerování elementu < machinekey > následujícím způsobem:

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

ASP.NET 2,0 a 3,5 aplikace nepodporují HMACSHA256. Místo toho můžete zadat algoritmus SHA1 pro vygenerování kompatibilního elementu < machineKey > následujícím způsobem:

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

Jakmile máte element < machineKey >, můžete jej umístit do souboru Web. config. Element < machineKey > je platný pouze v souboru Web. config v kořenovém adresáři aplikace a není platný na úrovni podsložky.

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

Chcete-li zobrazit úplný seznam podporovaných algoritmů, spusťte z příkazového řádku prostředí Windows PowerShell nápovědu Generate-MachineKey .

Dodatek B: zřízení registru pro zachování automaticky generovaných klíčů

Protože v registru HKCU jsou zachovány automaticky generované klíče technologie ASP. NETs, mohou být tyto klíče ztraceny, pokud nebyl profil uživatele načten do pracovního procesu služby IIS a poté se fond aplikací recykluje. Tento scénář by mohl mít vliv na poskytovatele sdílených hostitelských služeb, kteří používají fondy aplikací jako standardní uživatelské účty systému Windows. Chcete-li tuto situaci obejít, ASP.NET povolí uchování automaticky generovaných klíčů v registru HKLM namísto registru HKCU. To se obvykle provádí pomocí nástroje Aspnet_regiis (viz pokyny v části řešení 2a: použití nástroje Aspnet_regiis). Avšak pro správce, kteří nechtějí spustit tento nástroj, lze místo toho použít následující skript prostředí Windows PowerShell :

# Provisions the HKLM registry so that the specified user account can persist auto-generated machine keys.
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 {
    # We require administrative permissions to continue.
    if (-Not (new-object System.Security.Principal.WindowsPrincipal([System.Security.Principal.WindowsIdentity]::GetCurrent())).IsInRole([System.Security.Principal.WindowsBuiltInRole]::Administrator)) {
        Write-Error "This cmdlet requires Administrator permissions."
        return
    }
    # Open HKLM with an appropriate view into the registry
    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)
    # Open ASP.NET base key
    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)
    # Create AutoGenKeys subkey if it doesn't already exist
    $autoGenBaseKey = $aspNetBaseKey.OpenSubKey("AutoGenKeys", $True)
    if ($autoGenBaseKey -eq $null) {
        $autoGenBaseKey = $aspNetBaseKey.CreateSubKey("AutoGenKeys")
    }
    # Get the SID for the user in question, which will allow us to get his AutoGenKeys subkey
    $sid = (New-Object System.Security.Principal.WindowsIdentity($upn)).User.Value
    # SYSTEM, ADMINISTRATORS, and the target SID get full access
    $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) {
        # Subkey didn't exist; create and ACL appropriately
        $userAutoGenKey = $autoGenBaseKey.CreateSubKey($sid, [Microsoft.Win32.RegistryKeyPermissionCheck]::Default, $regSec)
    } else {
        # Subkey existed; make sure ACLs are correct
        $userAutoGenKey.SetAccessControl($regSec)
    }
  }
}

Následující příklad ukazuje, jak zřídit příslušné položky registru HKLM pro fond aplikací, který běží jako uživatel, example@contoso.com (název UPN uživatelského účtu systému Windows). Tento fond aplikací je 32 fond aplikací, ve kterém je spuštěn modul CLR verze 2.0 (ASP.NET 2,0 nebo 3,5).

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

Pokud je namísto fondu aplikací 64 fond aplikací s modulem CLR v 4.0 (ASP.NET 4,0 nebo 4,5), bude příkaz následující:

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

I když jsou automaticky generované klíče uloženy v HKLM, je podklíč registru, který uchovává tajný kryptografický materiál každého uživatelského účtu, přidán do seznamu řízení přístupu (ACL), takže kryptografický materiál nelze číst jinými uživatelskými účty.

Dodatek C: šifrování elementu < machineKey > v konfiguračních souborech

Je možné, že správci serveru nebudou chtít, aby v konfiguračních souborech byly v nešifrovaném formátu žádné vysoce citlivé informace, například materiál klíče < machineKey >. V takovém případě se mohou správci rozhodnout, že využijí funkci rozhraní .NET Framework známou jako chráněná konfigurace. Tato funkce umožňuje šifrovat určité části souborů. config. Pokud se obsah těchto konfiguračních souborů někdy zobrazí, zůstane obsah těchto oddílů stále tajný. Stručný přehled chráněné konfigurace naleznete na webu MSDN. Obsahuje také výukový program o ochraně elementů < connectionStrings > a < machineKey > souboru Web. config.