Vaade oleku sõnumi autentimise koodi (MAC) tõrgete lahendamine

Mis on vaateolek?

Vaade riik on teave, mis on ümardatud vahel WebForms (. aspx) lehed ASP.NET rakendus. _ VIEWSTATE välja HTML-märgistust meenutab järgmist:

< sisend tüüp = "peidetud" nimi = "_ _ VIEWSTATE" ID = "_ VIEWSTATE" väärtus = "..."/>Üks näide üksuse, mis võib olla salvestatud _ VIEWSTATE väljale on nupu juhtelemendi tekst. Kui kasutaja klõpsab nuppu, Button_Click sündmuseohjuri saab ekstraktida nupu teksti vaatevälja riik. Vaadake teemat ASP.net View State ülevaade teema Microsoft Developer Networki (MSDN) veebisaiti palju üksikasjalikuma ülevaate ASP.net Kuva olekut. Kuna _ _ VIEWSTATE väli sisaldab olulist teavet, mida kasutatakse taastada lehe postback, veenduge, et ründaja ei saa selle väljaga manipuleer. Kui ründaja esitas pahatahtlik _-i-ja VIEWSTATE-i lasti, võib ründaja potentsiaalselt trikk rakenduse sooritamisel tegevus, mida ta muidu ei oleks teinud. Seda tüüpi omavolilise rünnaku vältimiseks on "_ VIEWSTATE" väli kaitstud sõnumi autentimise koodiga (MAC). ASP.net valideerib Mac, mis on esitatud koos "_ ViewState", kui tagasipostitamise ilmneb. Võti, mida kasutatakse MAC arvutamiseks on määratud rakenduse element failis web. config. Kuna ründaja ei saa arvata < machineKey > elemendi sisu, ründaja ei saa pakkuda kehtivat MAC, kui ründaja üritab võltsija _ _ VIEWSTATE lasti. ASP.NET tuvastab, et kehtivat MAC-i ei ole esitatud ja ASP.NET hülgavad pahatahtliku taotluse.

Mis põhjustab MAC valideerimisvigu?

MAC valideerimise tõrge näeb välja järgmine näide:

Serveri tõrge '/' rakenduses. ViewState MAC valideerimine nurjus. Kui see rakendus on majutatud Web Farm või klastri, veenduge, et < machineKey > Konfiguratsioon määrab sama validationKey ja valideerimise algoritmi. AutoGenerate ei saa kasutada klastri. Kirjeldus: praeguse veebipäringu täitmisel ilmnes töötlemata erand. Palun vaadake stack trace lisateabe saamiseks tõrke ja kust see pärineb koodi. Erandite üksikasjad: System. Web. HttpException: ViewState MAC valideerimine nurjus. Kui see rakendus on majutatud Web Farm või klastri, veenduge, et < machineKey > Konfiguratsioon määrab sama validationKey ja valideerimise algoritmi. AutoGenerate ei saa kasutada klastri. Allika tõrge: [asjakohaseid lähteridu pole] Lähtefail:... Rida: 0 Pinu jälg: [ViewStateException: sobimatu vaateolek. Kliendi IP::: 1 Sadam: 40653 Referer: http://localhost:40643/MyPage.aspx Tee:/MyPage.aspx Kasutaja agent: Mozilla/5.0 (ühilduv; MSIE 10,0; Windows NT 6,2; WOW64 Trident/6.0) ViewState:...] [HttpException (0x80004005): ViewState MAC valideerimine nurjus. Kui see rakendus on majutatud Web Farm või klastri, veenduge, et < machineKey > Konfiguratsioon määrab sama validationKey ja valideerimise algoritmi. AutoGenerate ei saa kasutada klastri. Lisateabe saamiseks vaadake http://go.microsoft.com/fwlink/?LinkID=314055.] System. Web. UI. ViewStateException. ThrowError (erand sisemine, string persistedState, stringi errorPageMessage, Boolean macValidationError) + 190 System. Web. UI. ViewStateException. ThrowMacValidationError (erand sisemine, string persistedState) + 46 System. Web. UI. Objectstateforese. Deserialize (string inputString, eesmärgi eesmärk) + 861 System. Web. UI. Objectstateforese. System. Web. UI. IStateFormatter2. Deserialize (stringi serializedState, eesmärgi eesmärk) + 51 System. Web. UI. util. DeserializeWithAssert (IStateFormatter2 forasi, string serializedState, eesmärgi eesmärk) + 67 System. Web. UI. Hiddenfieldpagestateperõde. load () + 444 System. Web. UI. Page. LoadPageStateFromPersistenceMedium () + 368 System. Web. UI. Page. LoadAllState () + 109 System. Web. UI. Page. ProcessRequestMain (Boolean Includestagesbeforeasyncpointi, Boolean includeStagesAfterAsyncPoint) + 7959 System. Web. UI. Page. ProcessRequest (Boolean Includestagesbeforeasyncpointi, Boolean includeStagesAfterAsyncPoint) + 429 System. Web. UI. Page. ProcessRequest () + 125 System. Web. UI. Page. ProcessRequestWithNoAssert (HttpContext kontekstis) + 48 System. Web. UI. Page. ProcessRequest (HttpContext kontekstis) + 234 ASP. mypage_aspx. ProcessRequest (http-konteksti kontekst)...: 0 System. Web. CallHandlerExecutionStep. System. Web. HttpApplication. IExecutionStep. Execute () + 1300 System. Web. HttpApplication. ExecuteStep (IExecutionStep samm, Boolean & Completedsünkroonselt) + 140

1. põhjus: veebirakendus töötab pargi (mitme serveri keskkonnas)

ASP.NET automaatselt genereerib krüptograafiline võti iga rakenduse ja salvestab võtme HKCU registritaru. See automaatselt genereeritud võtit kasutatakse, kui ei ole selgesõnaline < machineKey > element rakenduse konfiguratsioon. Kuid kuna see automaatselt genereeritud võti on kohaliku arvuti, mis lõi võtme, see stsenaarium põhjustab probleemi rakendused, mis töötavad pargi. Iga serveripargi Server loob oma kohaliku võtme ja ükski serveripargi serveritest ei nõustu, millist võtit kasutada. Tulemuseks on see, et kui üks server loob _ VIEWSTATE lasti, et teine server tarbib, tarbija kogeda MAC valideerimise tõrge.

Lahendus 1a: luua selgesõnaline < machineKey > element Lisades selgesõnalise < machineKey > element rakenduse faili Web. config, arendaja ütleb ASP.NET mitte kasutada automaatselt genereeritud krüptograafiline võti. < MachineKey > elemendi loomise juhiste saamiseks vt lisa A . Pärast seda, kui see element on lisatud faili Web. config, juurutada uuesti rakenduse iga serveripargi. Märkus Mõned veebihostingu teenused, näiteks Microsofti Azure ' i veebisaidid, võtavad meetmeid iga rakenduse automaatselt genereeritud võtme sünkroonimiseks oma back-end serverites. See võimaldab rakendusi, mis on määratud selgesõnaline < machineKey > element jätkata töötamist nendes keskkondades, isegi siis, kui rakendus töötab pargi. Kui teie rakendus töötab kolmanda osapoole hostinguteenusega, võtke ühendust oma hostingupakkujaga, et teha kindlaks, kas see olukord kehtib teie kohta.
Lahendus 1b: Lubage ühtivus Load koormusetasakaalustusteenuse Kui teie saidid töötavad koormuse koormusetasakaalustuse taga, saate lubada serveri ühtivus ajutiselt selle probleemi lahendamiseks. See aitab tagada, et iga klient suhtleb ainult ühe füüsilise serveri taga Load koormusetasakaalustusteenuse nii, et kõik krüptograafiliste lasti on loodud ja tarbida sama server. Seda ei tohiks pidada probleemile pikaajaliseks lahenduseks. Isegi siis, kui serveri afiinsus on lubatud, enamik load tasakaalustajad suunata kliendi teise füüsilise serveri kui algne server, kuhu load tasakaalustajad on affinitized läheb ühenduseta. See põhjustab uue serveri hüljata krüptograafiliste lasti (nt _ _ VIEWSTATE, vormide autentimine piletid, MVCs võltsimisvastased load ja muud teenused), mis on kliendi praegu. Kasutades selgesõnaline < machineKey > element ja uuesti juurutamine rakendus peaks eelistus server afiinsust.

2. põhjus: töötaja protsess kasutab IIS 7,0 rakendusekausta identiteet

Internet Information Services (IIS) 7,0 (Windows Vista, Windows Server 2008) kasutusele rakendusekausta identiteedi, uus isolatsiooni mehhanism, mis aitab pakkuda suuremat turvalisust serverid, mis töötavad ASP.net rakendused. Kuid saidid, mis töötavad rakendusekausta identiteedi all ei ole juurdepääsu HKCU registrile. See on koht, kus ASP.NET Runtime salvestab selle automaatselt genereeritud < machineKey > võtmed. Tulemuseks on see, et ASP.NET ei saa püsivad automaatselt genereeritud võtme rakendusekausta lähtestamisel. Seetõttu iga kord, kui w3wp. exe lähtestatakse, luuakse uus ajutine võti. Märkus See ei ole probleem IIS 7,5 (Windows 7, Windows Server 2008 R2) ja uuemad versioonid. Nende versioonide IIS-i, ASP.NET võib püsida oma automaatselt genereeritud võtmed teises kohas, mis jääb ellu rakendusekausta lähtestab.

Lahendus 2a: kasutage aspnet_regiis utiliit ASP.NET seadmed sisaldavad utiliiti, aspnet_regiis. exe. See utiliit võimaldab ASP.NET liides IIS-i teha konfiguratsioone, mis on vajalikud hallatud rakenduse käivitamiseks. Üks neist konfiguratsioonide loob vajalikud võtmed registritaru, et võimaldada püsivust automaatselt genereeritud masin võtmed. Esmalt peate määratlema, millist rakendusekausta teie sait kasutab. Seda saab määrata inetmgr utiliidi, mis on kaasatud IIS-i abil. Valige oma sait vasakul puuvaates, paremklõpsake Halda Website ja seejärel klõpsake Täpsemad sätted. Kuvatav dialoogiboks kuvab rakendusekausta nime. Tellingud sobivad registrivõtmed ASP.NET 4,0 rakendusekausta, toimige järgmiselt.
1. Avage administratiivse Käsuviip.
2. Leidke sobiv kataloog, sõltuvalt sellest, kas teie rakendusekaust on 32-bitine või 64-bitine:
  - 32-bitise rakendusekausta: CD/d%windir%\Microsoft.NET\Framework\v4.0.30319
  - 64-bitise rakendusekausta: CD/d%windir%\Microsoft.NET\Framework64\v4.0.30319
3. Liikuge kataloogi, tippige järgmine käsk ja vajutage sisestusklahvi Enter:
  
  aspnet_regiis-ga "IIS-i APPPOOL\app-pool-name"
Kui rakendusekausta on ASP.NET 2,0 või 3,5 rakendusekausta, toimige järgmiselt.
1. Avage administratiivse Käsuviip.
2. Leidke sobiv kataloog, sõltuvalt sellest, kas teie rakendusekaust on 32-bitine või 64-bitine:
  - 32-bitise rakendusekausta: CD/d%windir%\Microsoft.NET\Framework\v2.0.50727
  - 64-bitise rakendusekausta: CD/d%windir%\Microsoft.NET\Framework64\v2.0.50727
3. Liikuge kataloogi, tippige järgmine käsk ja vajutage sisestusklahvi Enter:
  
  aspnet_regiis-ga "IIS-i APPPOOL\app-pool-name"
Näiteks kui teie rakendusekausta nimi on minu rakendusekaust (nagu eelmises pildil), käivitage järgmine käsk:

aspnet_regiis-ga "IIS-i APPPOOL\My app pool" Märkus Süsteemiteenused APPHOSTSVC ja oli võib-olla töötab aspnet_regiis utiliidi IIS-i APPPOOL \ * nimede sobivalt lahendada.
Lahendus 2b: luua selgesõnaline < machineKey > element Lisades selgesõnalise < machineKey > element rakenduse faili Web. config, arendaja ütleb ASP.NET mitte kasutada automaatselt genereeritud krüptograafiline võti. < MachineKey > elemendi loomise juhiste saamiseks vt lisa A .

3. põhjus: rakendusekaust on konfigureeritud, kasutades LoadUserProfile = FALSE

Kui rakendusekaust töötab kohandatud identiteedi, IIS-i ei pruugi olla laaditud identiteedi kasutajaprofiil. See on kõrvalmõju teha HKCU register pole saadaval ASP.NET püsivad automaatselt genereeritud < machineKey >. Seetõttu luuakse uus automaatselt genereeritud võti iga kord, kui rakendus taaskäivitub. Lisateabe saamiseks vaadake Microsofti veebisaidil jaotist kasutajaprofiil .

3. lahendus: kasutage aspnet_regiis kasulikkust Juhised on samad kui resolutsioon 2a. Vaadake seda jaotist lisateabe saamiseks.
Lahendus 3b: kasutage selgesõnaline < machineKey > Lisades selgesõnalise < machineKey > element rakenduse faili Web. config, arendaja ütleb ASP.NET mitte kasutada automaatselt genereeritud krüptograafiline võti. < MachineKey > elemendi loomise juhiste saamiseks vt lisa A .
Resolutsioon 3c: ette nõutud HKCU registrivõtmed käsitsi Kui te ei saa käivitada aspnet_regiis utiliit, saate kasutada Windows PowerShelli skripti ette vastavad registrivõtmed HKCU. Lisateabe saamiseks vt lisa B .
Lahendus 3D: Seadke LoadUserProfile = True selle rakendusekausta Samuti saate lubada selle rakendusekausta kasutajaprofiili laadimist. See muudab HKCU registritaru, ajutise kausta ja muud kasutaja teatud ladustamise asukohad saadaval rakenduse. Kuid see võib põhjustada suurenenud ketta või mälu hõivatus töötaja protsessi. Selle sätte lubamise kohta lisateabe saamiseks vaadake elementi .

4. põhjus: The Page. ViewStateUserKey atribuut on ebaõige väärtus

Tarkvaraarendajad saavad otsustada kasutada lehte. ViewStateUserKey atribuut saitidevahelise taotluse võltsimiskaitse LISAMISEKS _ ViewState välja. Kui kasutate lehte. ViewStateUserKey atribuut, see on tavaliselt seatud väärtus nagu praeguse kasutaja kasutajanimi või kasutaja seansi identifikaator. Projekti Mallid WebForms rakenduste Microsoft Visual Studio 2012 ja uuemad versioonid sisaldavad näidised, mis kasutavad seda atribuuti. Lisateabe saamiseks vaadake lehte. ViewStateUserKey atribuut Microsoft Developer NETWORKI (MSDN) veebisaiti. Kui on määratud Viewstateuserkey atribuut, selle väärtus on põletatud _ ViewState põlvkonna ajal. "_ VIEWSTATE" välja tarbitakse server kontrollib praeguse lehe Viewstateuserkey atribuut ja kinnitab selle väärtuse, mida KASUTATI _ ViewState välja genereerida. Kui väärtused ei kattu, lükatakse taotlus potentsiaalselt pahatahtlikuks. ViewStateUserKey seotud tõrke näide oleks klient, kellel on kaks vahekaarti avatud brauseris. Klient on sisse logitud kasutajana A ja esimesel vahekaardil leht on renderdada _ VIEWSTATE, kelle Viewstateuserkey atribuut sisaldab "kasutaja a." Teise vahekaardi Klient logib välja ja seejärel logib sisse kasutajana B. Klient läheb tagasi esimese vahekaardi ja esitab vormi. Viewstateuserkey atribuut võib sisaldada "kasutaja B" (sest see on, mida kliendi autentimine küpsis ütleb). Siiski _ "kasutaja A.", mille klient esitas kuvatakse "User A." See mittevastavus põhjustab tõrke.

Lahendus 4a: Veenduge, et ViewStateUserKey on õigesti seatud Kui teie rakendus kasutab Viewstateuserkey atribuuti, veenduge, et atribuudi väärtus on sama, kui vaate olek on loodud ja kui see on tarbitud. Kui kasutate praegust sisselogitud kasutaja kasutajanime, veenduge, et kasutaja on endiselt sisse logitud ja et kasutaja identiteet pole postback ajal muutunud. Kui kasutate praegust kasutaja seansi identifikaatorit, veenduge, et seanss pole aegunud. Kui kasutate pargi keskkonnas, veenduge, et < machineKey > elemente sobitada. Nende elementide genereerimiseks juhiste saamiseks vt lisa A .

A liide: kuidas luua < machineKey > element

Turvahoiatus On palju veebisaite, mis loovad < machineKey > element teile nupu klõpsamisel. Ärge kunagi kasutage < machineKey > element, mille saite ühest neist saitidelt. On võimatu teada, kas need võtmed loodi turvaliselt või kui need salvestatakse salajaseks andmebaasi. Kasutage ainult < machineKey > konfiguratsioonielemente, mille olete ise loonud.

< MachineKey > element ise loomiseks võite kasutada järgmist Windows PowerShelli skripti:

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

ASP.NET 4,0 rakenduste puhul saate lihtsalt helistada luua-machinekey ilma parameetriteta luua < machinekey > element järgmiselt:

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

ASP.NET 2,0 ja 3,5 rakendused ei toeta HMACSHA256. Selle asemel saate määrata SHA1 luua ühilduv < machineKey > element järgmiselt:

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

Niipea, kui teil on < machineKey > element, saate panna see faili Web. config. < MachineKey > element kehtib ainult rakenduse root faili Web. config ja alamkausta tasemel ei kehti.

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

Toetatud algoritmide täieliku loendi käivitada spikri Genereeri MachineKey Windows PowerShelli viip.

Lisa B: registri ettevalmistamine automaatselt genereeritud võtmete püsimisel

Vaikimisi, kuna ASP. NETs automaatselt genereeritud võtmed on püsivaid HKCU registris, need võtmed võib kaduda, kui kasutaja profiil ei ole laaditud IIS-i töötaja protsessi ja seejärel rakendusekausta recycles. See stsenaarium võib mõjutada ühiskasutuses hosting pakkujad, kes töötavad Rakendusekaustad Standard Windowsi Kasutajakontod. Selle olukorra lahendamiseks ASP.NET võimaldab püsiv automaatselt genereeritud võtmed HKLM registri asemel HKCU registri. Seda tehakse tavaliselt aspnet_regiis utiliidi abil (vt juhiseid jaotises "eraldusvõime 2a: kasutage aspnet_regiis utiliidi"). Kuid administraatoritele, kes ei soovi seda utiliidi käitada, võib selle asemel kasutada järgmist Windows PowerShelli skripti:

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

Järgmises näites kirjeldatakse, kuidas ette näha sobiv HKLM registrikirjete rakendusekausta, mis töötab kasutajana, example@contoso.com (see on Windowsi kasutajakonto UPN). See rakendusekaust on 32-bitise rakendusekausta, kus töötab CLR v 2.0 (ASP.NET 2,0 või 3,5).

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

Kui rakendusekausta asemel on 64-bitise rakendusekausta, kus töötab CLR v 4.0 (ASP.NET 4,0 või 4,5), käsk on järgmine:

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

Kuigi automaatselt genereeritud võtmed on salvestatud HKLM, lisatakse registri alamvõti, mis hoiab iga kasutajakonto salajane krüptograafiline materjal pääsuloend (ACL), et krüptograafiline materjal ei saa lugeda teiste kasutajakontode.

Lisa C: krüpteerimine < machineKey > element konfiguratsioonifailides

Serveri administraatorid ei pruugi olla väga tundlik teave, näiteks < machineKey > võtmematerjali Bein ruudeline vormi konfiguratsioonifailid. Sellisel juhul võivad administraatorid otsustada ära kasutada .NET Frameworki funktsiooni, mida tuntakse "kaitstud konfiguratsiooniga". See funktsioon võimaldab teil krüptida teatud sektsioonid. config faile. Kui nende konfiguratsioonifailide sisu on kunagi avalikustatud, jääb nende sektsioonide sisu endiselt saladuseks. Leiate lühiülevaate kaitstud konfiguratsioonist MSDN-i veebisaidil. See sisaldab ka õpetus, kuidas kaitsta < connectionStrings > ja < machineKey > elemendid faili Web. config.