Rezolvare Vizualizare stare mesaj Cod autentificare (MAC) erori

Ce este starea de vizualizare?

Vizualizare stare este informații care este rotund-declanșat între WebForms (. aspx) pagini într-o aplicație ASP.NET. Marcajul HTML pentru câmpul _ VIEWSTATE seamănă cu următorul:

< tip de intrare = "Hidden" name = "' _ VIEWSTATE" ID = ' _ VIEWSTATE "Value ="... "/>Un exemplu de un element care ar putea fi stocate în câmpul "_ VIEWSTATE" este textul unui control buton. Dacă un utilizator face clic pe buton, rutina de tratare a evenimentelor Button_Click va putea extrage textul butonului din câmpul Vizualizare stare. Consultați subiectul ASP.net vizualizare generală de stat pe site-ul Web Microsoft Developer Network (MSDN) pentru o imagine de ansamblu mult mai detaliată a stării de vizualizare ASP.net. Deoarece câmpul _ VIEWSTATE conține informații importante care sunt utilizate pentru a reconstrui pagina pe postback, asigurați-vă că un atacator nu poate să manipulați acest câmp. În cazul în care un atacator a trimis o încărcătură rău intenționat, atacatorul poate păcăli aplicația să efectueze o acțiune pe care altfel nu ar fi efectuat-o. Pentru a preveni acest tip de atac de manipulare, câmpul _ VIEWSTATE este protejat de un cod de autentificare mesaj (MAC). ASP.NET validează MAC-ul care este trimis împreună cu instrumentul de încărcare de _ VIEWSTATE atunci când apare un postback. Cheia care este utilizat pentru a calcula MAC este specificată în elementul aplicației în fișierul web. config. Deoarece atacatorul nu poate ghici conținutul elementului < machineKey >, atacatorul nu poate furniza un MAC valid dacă atacatorul încearcă să se manipulați cu încărcătura "_ VIEWSTATE". ASP.NET va detecta că nu a fost furnizat un MAC valid, iar ASP.NET va respinge solicitarea rău intenționată.

Ce cauzează erorile de validare MAC?

O eroare de validare MAC va semăna cu următorul exemplu:

Eroare de server în '/' Application. Validarea ViewState MAC nu a reușit. Dacă această aplicație este găzduit de o fermă Web sau cluster, asigurați-vă că < machineKey > configurația specifică același algoritm de validationKey și validare. Generarea automată nu poate fi utilizată într-un cluster. Descriere: s-a produs o excepție negestionată în timpul executării solicitării Web curente. Vă rugăm să revizuiți Stack Trace pentru mai multe informații despre eroarea și în cazul în care provine din cod. Excepție detalii: System. Web. HttpException: validarea ViewState MAC nu a reușit. Dacă această aplicație este găzduit de o fermă Web sau cluster, asigurați-vă că < machineKey > configurația specifică aceeași validationKey și algoritmul de validare. Generarea automată nu poate fi utilizată într-un cluster. Eroare sursă: [nu există linii sursă relevante] Fișier sursă:... Linie: 0 Stivei: [ViewStateException: stare de vizualizare nevalidă. IP client::: 1 Port: 40653 Referer: http://localhost:40643/MyPage.aspx Cale:/MyPage.aspx User-agent: Mozilla/5.0 (compatibil; MSIE 10,0; Windows NT 6,2; WOW64 Trident/6.0) ViewState:...] [HttpException (0x80004005): validarea ViewState MAC nu a reușit. Dacă această aplicație este găzduit de o fermă Web sau cluster, asigurați-vă că < machineKey > configurația specifică aceeași validationKey și algoritmul de validare. Generarea automată nu poate fi utilizată într-un cluster. Consultați http://go.microsoft.com/fwlink/?LinkID=314055 pentru mai multe informații.] System. Web. UI. ViewStateException. ThrowError (excepție interior, String persistedState, șir errorPageMessage, Boolean macValidationError) + 190 System. Web. UI. ViewStateException. ThrowMacValidationError (excepție interior, String persistedState) + 46 System. Web. UI. ObjectStateFormatter. Deserialize (șir inputString, scopul scopului) + 861 System. Web. UI. ObjectStateFormatter. System. Web. UI. IStateFormatter2. Deserialize (șir serializedState, scopul scop) + 51 System. Web. UI. util. Deserializewithafirme (IStateFormatter2 Formatter, String serializedState, scopul scop) + 67 System. Web. UI. Hiddenfieldpagestatepersora. 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. Processrequestwithnoafirme (HttpContext context) + 48 System. Web. UI. Page. ProcessRequest (context HttpContext) + 234 ASP. mypage_aspx. ProcessRequest (HttpContext context) în...: 0 System. Web. CallHandlerExecutionStep. System. Web. HttpApplication. IExecutionStep. execute () + 1300 System. Web. HttpApplication. ExecuteStep (Pasul IExecutionStep, Boolean & Completedsincron) + 140

Cauza 1: aplicația Web se execută într-o fermă (mediu multi-server)

ASP.NET generează automat o cheie criptografică pentru fiecare aplicație și stochează cheia în secțiunea de registry HKCU. Această cheie generat automat este utilizat dacă nu există nici un element explicit < machineKey > în configurația aplicației. Cu toate acestea, deoarece această cheie generat automat este local la computerul care a creat cheia, acest scenariu provoacă o problemă pentru aplicațiile care se execută într-o fermă. Fiecare server din fermă va genera propria cheie locală, și nici unul dintre serverele din fermă va fi de acord pe care cheie pentru a utiliza. Rezultatul este că, în cazul în care un server generează o sarcină de $ _ VIEWSTATE că un alt server consumă, consumatorul va experimenta o eroare de validare MAC.

Rezoluția 1a: Creați un element explicit < machineKey > Adăugând un element explicit < machineKey > la fișierul web. config al aplicației, dezvoltatorul spune ASP.NET nu utilizați cheia criptografică generată automat. A se vedea apendicele a pentru instrucțiuni despre se generează un element < machinekey >. După ce acest element este adăugat la fișierul web. config, redistribui aplicația pentru fiecare server din fermă. Notă Unele servicii de găzduire web, ar fi site-urile Web Microsoft Azure, iau măsuri pentru a sincroniza cheia generată automat a fiecărei aplicații pe serverele back-end. Acest lucru permite aplicațiilor care nu au specificat un element explicit < machineKey > pentru a continua lucrul în aceste medii, chiar dacă aplicația se execută într-o fermă. Dacă aplicația se execută pe un serviciu de găzduire terță parte, vă rugăm să contactați furnizorul de găzduire pentru a determina dacă această situație se aplică pentru tine.
Rezoluția 1b: activați afinitatea în echilibrare de încărcare Dacă site-urile funcționează în spatele unui balancer de încărcare, aveți posibilitatea să activați afinitatea serverului pentru a lucra temporar în jurul problemei. Acest lucru vă ajută să se asigure că orice client dat doar interacționează cu un server fizic în spatele echilibrare de încărcare, astfel încât toate încărcări criptografice va fi atât generate de și consumate de către același server. Acest lucru nu ar trebui să fie considerată o soluție pe termen lung la problema. Chiar și atunci când afinitate server este activat, cele mai multe echilibrat de încărcare va redirecționa clientul la un alt server fizic în cazul în care serverul original la care echilibrat de încărcare au fost affinitized merge offline. Acest lucru provoacă noul server pentru a respinge încărcări criptografice (cum ar fi _ VIEWSTATE, bilete de autentificare formulare, MVCs token-uri anti-falsificare și alte servicii) pe care clientul are în prezent. Folosind un element explicit < machineKey > și redistribuirea aplicației ar trebui să fie preferată peste activarea afinitate server.

Cauza 2: procesul de lucrător utilizează identitatea rezervor de aplicații IIS 7,0

Internet Information Services (IIS) 7,0 (Windows Vista, Windows Server 2008) a introdus identitate rezervor de aplicații, un nou mecanism de izolare care ajută la furnizarea de securitate sporită pentru serverele care execută aplicații ASP.net. Cu toate acestea, site-uri care se execută sub identitate rezervor de aplicații nu au acces la registry HKCU. Aceasta este în cazul în care ASP.NET Runtime stochează sale auto-generate < machineKey > chei. Rezultatul este că ASP.NET nu persistă cheia generat automat atunci când rezervorul de aplicații este resetat. De aceea, de fiecare dată când este resetat w3wp. exe, o nouă cheie temporară este generat. Notă Aceasta nu este o problemă în IIS 7,5 (Windows 7, Windows Server 2008 R2) și versiunile ulterioare. Pe aceste versiuni de IIS, ASP.NET poate persista sale auto-generate cheile într-o altă locație care supraviețuiește rezervor de aplicații resetează.

Rezoluția 2a: utilizați utilitarul Aspnet_regiis ASP.NET instalări conțin un utilitar, Aspnet_regiis. exe. Acest utilitar permite ASP.NET interfață cu IIS pentru a efectua configurațiile care sunt necesare pentru a executa o aplicație gestionată. Una dintre aceste configurații creează cheile necesare în secțiunea de registry pentru a permite persistența de auto-generate mașină chei. În primul rând, trebuie să determinați ce rezervor de aplicații utilizează site-ul dvs. Acest lucru poate fi determinată utilizând utilitarul inetmgr care este inclus în IIS. Selectați site-ul în vizualizarea arborescentă din stânga, faceți clic dreapta pe Gestionați website, apoi faceți clic pe Setări complexe. Caseta de dialog care apare va afișa numele piscinei aplicației. Pentru a schelă cheile de registry corespunzătoare pentru o ASP.NET 4,0 rezervor de aplicații, urmați acești pași:
1. Deschideți un prompt de comandă administrativă.
2. Localizați directorul corespunzătoare, în funcție de dacă rezervorul de aplicații este 32-bit sau 64-bit:
  - 32-bit rezervor de aplicații: CD/d%WINDIR%\Microsoft.NET\Framework\v4.0.30319
  - 64-bit rezervor de aplicații: CD/d%WINDIR%\Microsoft.NET\Framework64\v4.0.30319
3. Mutați în directorul, tastați următoarea comandă, și apoi apăsați pe Enter:
  
  Aspnet_regiis-GA "IIS APPPOOL\app-pool-name"
Dacă rezervorul de aplicații este un ASP.NET 2,0 sau 3,5 rezervor de aplicații, urmați acești pași:
1. Deschideți un prompt de comandă administrativă.
2. Localizați directorul corespunzător, în funcție de dacă rezervorul de aplicații este 32-bit sau 64-bit:
  - 32-bit rezervor de aplicații: CD/d%WINDIR%\Microsoft.NET\Framework\v2.0.50727
  - 64-bit rezervor de aplicații: CD/d%WINDIR%\Microsoft.NET\Framework64\v2.0.50727
3. Mutați în directorul, tastați următoarea comandă, și apoi apăsați pe Enter:
  
  Aspnet_regiis-GA "IIS APPPOOL\app-pool-name"
De exemplu, dacă rezervorul de aplicații este denumit rezervor de aplicații (ca în imaginea anterioară), executați următoarea comandă:

Aspnet_regiis-GA "IIS APPPOOL\My App rezervor" Notă Consolidare servicii de sistem APPHOSTSVC și WAS mai have la spre a fi running pentru utilitarul Aspnet_regiis pentru a rezolva IIS APPPOOL \ * nume în mod corespunzător.
Rezoluția 2b: Creați un element explicit < machineKey > Adăugând un element explicit < machineKey > la fișierul web. config al aplicației, dezvoltatorul spune ASP.NET nu utilizați cheia criptografică generată automat. A se vedea apendicele a pentru instrucțiuni despre se generează un element < machinekey >.

Cauza 3: rezervorul de aplicații este configurat utilizând LoadUserProfile = false

Dacă rezervorul de aplicații se execută cu o identitate particularizată, este posibil ca IIS să nu fi încărcat profilul de utilizator pentru identitate. Acest lucru are efect secundar de a face registry HKCU indisponibil pentru ASP.NET să persiste auto-generate < machineKey >. De aceea, o nouă cheie generat automat va fi creat de fiecare dată când aplicația repornește. Consultați secțiunea profil utilizator de pe site-ul Web Microsoft pentru mai multe informații.

Rezoluția 3a: utilizați utilitarul Aspnet_regiis Instrucțiunile pentru acest lucru sunt identice cu rezoluția 2a. Consultați secțiunea respectivă pentru mai multe informații.
Rezolvare 3B: utilizați o < machineKey explicit > Adăugând un element explicit < machineKey > la fișierul web. config al aplicației, dezvoltatorul spune ASP.NET nu utilizați cheia criptografică generată automat. A se vedea apendicele a pentru instrucțiuni despre se generează un element < machinekey >.
Rezoluția 3c: furnizarea manuală a cheilor de registry HKCU necesare Dacă nu se poate executa utilitarul Aspnet_regiis, utilizați un script Windows PowerShell pentru a prevedea cheile de registry corespunzătoare în HKCU. A se vedea apendicele B pentru mai multe informații.
Rezolutie 3D: set LoadUserProfile = True pentru acest rezervor de aplicații De asemenea, puteți activa Încărcarea profilului de utilizator în cadrul acestui rezervor de aplicații. Acest lucru face stup de registry HKCU, folder temporar și alte locații de stocare specifice utilizatorului disponibile pentru aplicația. Cu toate acestea, acest lucru poate provoca creșterea disc sau memorie usage pentru procesul de lucrător. Consultați elementul pentru mai multe informații despre se activează această setare.

Cauza 4: proprietatea Page. ViewStateUserKey are o valoare incorectă

Dezvoltatorii de software pot decide să folosească pagina. ViewStateUserKey proprietate pentru a adăuga cross-site-ul de protecție falsificarea cerere la câmpul _ ViewState. Dacă utilizați pagina. ViewStateUserKey proprietate, acesta este de obicei setată la o valoare, ar fi numele utilizatorului curent sau identificatorul sesiunii utilizatorului. Șabloanele de proiect pentru aplicațiile WebForms din Microsoft Visual Studio 2012 și versiunile ulterioare conțin eșantioane care utilizează această proprietate. A se vedea pagina. ViewStateUserKey proprietate subiect pe site-ul Microsoft Developer Network (MSDN) pentru mai multe informații. Dacă este specificată proprietatea Viewstateuserkey , valoarea sa este arsă în _ ViewState în momentul generării. Când se consumă câmpul _ VIEWSTATE, serverul verifică proprietatea Viewstateuserkey a paginii curente și o validează împotriva valorii care a fost utilizată pentru a genera câmpul _ ViewState. Dacă valorile nu corespund, solicitarea este respinsă ca potențial rău intenționat. Un exemplu de o eroare de ViewStateUserKey legate ar fi un client care are două file deschise în browser-ul. Clientul este autentificat ca utilizator A și în prima filă, o pagină este randată cu un _ VIEWSTATE a cărui proprietate Viewstateuserkey conține "utilizatorul a." În a doua filă, clientul se conectează și apoi se conectează înapoi ca utilizator B. Clientul se întoarce la prima filă și prezintă formularul. Proprietatea Viewstateuserkey poate conține "utilizator B" (pentru că este ceea ce spune cookie-ul clientului de autentificare). Cu toate acestea, câmpul _ VIEWSTATE care clientul a prezentat conține "utilizatorul A." Această nepotrivire cauzează eșecul.

Rezoluția 4a: Verificați dacă ViewStateUserKey este setat corect Dacă aplicația utilizează proprietatea Viewstateuserkey , Verificați că valoarea proprietății este aceeași atât atunci când starea de vizualizare este generat și atunci când este consumat. Dacă utilizați numele de utilizator curent al utilizatorului conectat, asigurați-vă că utilizatorul este încă autentificat și că identitatea utilizatorului nu s-a modificat la momentul postback. Dacă utilizați identificatorul de sesiune al utilizatorului curent, asigurați-vă că sesiunea nu a expirat. Dacă executați într-un mediu de fermă, asigurați-vă că se potrivesc < machineKey > elemente. A se vedea apendicele A pentru instrucțiuni despre se generează aceste elemente.

Apendicele A: se generează un element < machineKey >

Avertizare de securitate Există multe site-uri web care va genera un element < machineKey > pentru tine cu un clic de buton. Nu utilizați niciodată un element < machineKey > pe care l-ați obținut de la unul dintre aceste site-uri. Este imposibil de știut dacă aceste taste au fost create în siguranță sau dacă sunt înregistrate într-o bază de date secretă. Ar trebui să utilizați doar vreodată < machineKey > elementele de configurare pe care le-ați creat.

Pentru a genera un element < machineKey >, aveți posibilitatea să utilizați următorul script 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)
  }
}

Pentru ASP.NET 4,0 aplicații, puteți apela doar genera-machinekey fără parametri pentru a genera un element < machinekey > după urmează:

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

ASP.NET 2,0 și 3,5 aplicații nu acceptă HMACSHA256. În schimb, aveți posibilitatea să specificați SHA1 pentru a genera un element compatibil < machineKey > după urmează:

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

De îndată ce aveți un element < machineKey >, îl puteți pune în fișierul web. config. Elementul < machineKey > este valid numai în fișierul web. config la rădăcina aplicației și nu este validă la nivel de subfolder.

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

Pentru o listă completă de algoritmi acceptate, executați Ajutor generate-MachineKey din promptul Windows PowerShell.

Apendicele B: asigurarea accesului registry la persistarea cheilor generate automat

În mod implicit, deoarece ASP. NETs cheile generate automat sunt persistente în registry HKCU, aceste taste pot fi pierdute dacă profilul de utilizator nu a fost încărcat în procesul de lucrător IIS și apoi rezervorul de aplicații recicla. Acest scenariu ar putea afecta shared hosting furnizori care execută aplicarea bazine ca standard de utilizator Windows conturi. Pentru a rezolva această situație, ASP.net permite persistente auto-generate cheile în registry HKLM în loc de HKCU registry. Acest lucru se efectuează de obicei utilizând utilitarul Aspnet_regiis (consultați instrucțiunile din secțiunea "rezoluția 2a: utilizați utilitarul Aspnet_regiis"). Cu toate acestea, pentru administratorii care nu doresc să executați acest utilitar, următorul script Windows PowerShell poate fi utilizat în schimb:

# 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)
    }
  }
}

Următorul exemplu arată să prevadă intrările de registry HKLM corespunzătoare pentru un rezervor de aplicații care se execută ca utilizator, example@contoso.com (aceasta este UPN din contul de utilizator Windows). Acest rezervor de aplicații este un rezervor de aplicații 32-bit care se execută CLR v 2.0 (ASP.NET 2,0 sau 3,5).

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

Dacă rezervorul de aplicații în schimb este un rezervor de aplicații 64-bit care se execută CLR v 4.0 (ASP.NET 4,0 sau 4,5), comanda este după urmează:

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

Chiar dacă cheile generate automat sunt stocate în HKLM, subcheia de registry care deține materialul criptografic secret al fiecărui cont de utilizator se adaugă la o listă de control acces (ACL) astfel încât materialul criptografic să nu poată fi citit de alte conturi de utilizator.

Apendicele C: criptarea elementului < machineKey > în fișierele de configurare

Administratorii de server nu doresc informații extrem de sensibile, ar fi < machineKey > material cheie pentru a fi în formă de text în fișiere de configurare. În acest caz, administratorii pot decide să profite de o caracteristică .NET Framework cunoscută sub numele de "configurație protejată". Această caracteristică vă permite să criptați anumite secțiuni ale fișierelor. config. În cazul în care conținutul acestor fișiere de configurare sunt divulgate vreodată, conținutul acestor secțiuni va rămâne în continuare secret. Puteți găsi o scurtă prezentare a configurației protejate pe site-ul MSDN. De asemenea, conține un tutorial despre să protejați < connectionStrings > și < machineKey > elemente ale fișierului web. config.