Biztonsági keret: Kriptográfia | Mérséklés

Termék/szolgáltatás Cikk
Webalkalmazás
Adatbázis
IoT-eszköz
IoT Cloud Gateway
Dynamics CRM mobil kliens
Dynamics CRM Outlook ügyfél
Identitáskiszolgáló

Csak jóváhagyott szimmetrikus blokktitkosításokat és kulcshosszakat használjon

Cím Részletek
Komponens Webalkalmazás
SDL-fázis Épít
Alkalmazható technológiák Általános
Attribútumok Nincs adat.
hivatkozások Nincs adat.
Lépések

A termékek csak azokat a szimmetrikus blokktitkosításokat és a hozzájuk tartozó kulcshosszakat használhatják, amelyeket a szervezet Crypto Advisorja kifejezetten jóváhagyott. A Microsoft jóváhagyott szimmetrikus algoritmusai a következő blokktitkosításokat tartalmazzák:

  • Az új kód esetében az AES-128, AES-192 és AES-256 elfogadható
  • A meglévő kóddal való visszamenőleges kompatibilitás érdekében a háromgombos 3DES elfogadható
  • Szimmetrikus blokkjeleket használó termékek esetén:
    • Az új kódhoz Advanced Encryption Standard (AES) szükséges
    • A háromkulcsos hármas adattitkosítási szabvány (3DES) megengedett a meglévő kódban a visszamenőleges kompatibilitás érdekében
    • Az összes többi blokkrejtjel, beleértve az RC2, DES, 2 Key 3DES, DESX és Skipjack titkosítást, csak a régi adatok visszafejtésére használható, és titkosítás esetén ki kell cserélni
  • A szimmetrikus blokktitkosítási algoritmusokhoz legalább 128 bites kulcshossz szükséges. Az új kódhoz csak az AES ajánlott blokktitkosítási algoritmus (AES-128, AES-192 és AES-256 mind elfogadható)
  • A háromkulcsos 3DES jelenleg elfogadható, ha már használatban van a meglévő kódban; AES-re való áttérés ajánlott. A DES, a DESX, az RC2 és a Skipjack már nem tekinthető biztonságosnak. Ezek az algoritmusok csak a meglévő adatok visszafejtésére használhatók a visszamenőleges kompatibilitás érdekében, és az adatokat egy ajánlott blokktitkosítással kell újra titkosítani

Kérjük, vegye figyelembe, hogy minden szimmetrikus blokktitkosítást jóváhagyott titkosítási móddal kell használni, amely megfelelő inicializálási vektor (IV) használatát igényli. A megfelelő IV általában véletlen szám, és soha nem állandó érték

A régi vagy más módon nem jóváhagyott titkosítási algoritmusok és a meglévő adatok olvasására szolgáló kisebb kulcshosszak használata (az új adatok írásával szemben) engedélyezhető a szervezet Crypto Board felülvizsgálata után. Azonban kivételt kell benyújtania e követelmény alól. Emellett a vállalati telepítések során a termékeknek figyelembe kell venniük a rendszergazdák figyelmeztetését, ha gyenge kriptográfiát használnak az adatok olvasására. Az ilyen figyelmeztetéseknek magyarázónak és végrehajthatónak kell lenniük. Bizonyos esetekben helyénvaló lehet, hogy a csoportházirend szabályozza a gyenge kriptográfia használatát

Engedélyezett .NET algoritmusok a felügyelt titkosítási agilitáshoz (preferencia sorrendben)

  • AesCng (FIPS-kompatibilis)
  • AuthenticatedAesCng (FIPS-kompatibilis)
  • AESCryptoServiceProvider (FIPS-kompatibilis)
  • AESManaged (nem FIPS-kompatibilis)

Felhívjuk figyelmét, hogy ezen algoritmusok egyike sem adható meg a SymmetricAlgorithm.Create vagy CryptoConfig.CreateFromName metódusokkal anélkül, hogy módosítaná a machine.config fájlt. Azt is vegye figyelembe, hogy a .NET 3.5 előtti verzióiban az AES neve RijndaelManaged, és AesCngAuthenticatedAesCng a CodePlexen keresztül érhető el >, és CNG-t igényel a mögöttes operációs rendszerben

Jóváhagyott blokktitkosítási módok és inicializálási vektorok használata szimmetrikus titkosításokhoz

Cím Részletek
Komponens Webalkalmazás
SDL-fázis Épít
Alkalmazható technológiák Általános
Attribútumok Nincs adat.
hivatkozások Nincs adat.
Lépések Minden szimmetrikus blokkrejtjelet jóváhagyott szimmetrikus titkosítási móddal kell használni. Az egyetlen jóváhagyott mód a CBC és a CTS. Különösen az elektronikus kódkönyv (EKB) működési módját kell kerülni; az EKB használatához a szervezet Crypto Board felülvizsgálata szükséges. Az OFB, CFB, CTR, CCM és GCM vagy bármely más titkosítási mód minden használatát a szervezet Crypto Boardjának felül kell vizsgálnia. Ugyanazon inicializálási vektor (IV) blokktitkosítással történő újrafelhasználása "adatfolyam-titkosítási módokban", például CTR-ben, titkosított adatok felfedését okozhatja. Minden szimmetrikus blokkrejtjelet megfelelő inicializálási vektorral (IV) kell használni. A megfelelő IV kriptográfiailag erős, véletlenszerű szám, és soha nem állandó érték.

Használjon jóváhagyott aszimmetrikus algoritmusokat, kulcshosszokat és kitöltéseket

Cím Részletek
Komponens Webalkalmazás
SDL-fázis Épít
Alkalmazható technológiák Általános
Attribútumok Nincs adat.
hivatkozások Nincs adat.
Lépések

A tiltott kriptográfiai algoritmusok használata jelentős kockázatot jelent a termékbiztonságra nézve, ezért kerülni kell. A termékek csak azokat a titkosítási algoritmusokat és a hozzájuk tartozó kulcshosszakat és kitöltéseket használhatják, amelyeket a szervezet titkosítási testülete kifejezetten jóváhagyott.

  • RSA- titkosításra, kulcscserére és aláírásra használható. Az RSA-titkosítás csak OAEP vagy RSA-KEM kitöltési módot használhat. A meglévő kód csak a kompatibilitás érdekében használhatja a PKCS #1 v1.5 kitöltési módot. A null kitöltés használata kifejezetten tilos. Kulcsok >= 2048 bit szükséges az új kódhoz. A meglévő kód csak a visszamenőleges kompatibilitás érdekében támogathatja a 2048 bites kulcsokat < , miután a szervezet Crypto Board felülvizsgálta. Az 1024 bites kulcsok < csak a régi adatok visszafejtésére/ellenőrzésére használhatók, és titkosítási vagy aláírási műveletekhez való használat esetén ki kell cserélni
  • ECDSA- csak aláírásra használható. Az új kódhoz =256 bites kulcsokkal rendelkező ECDSA >szükséges. Az ECDSA-alapú aláírásoknak a három NIST által jóváhagyott görbe egyikét kell használniuk (P-256, P-384 vagy P521). Az alaposan elemzett görbék csak a szervezet Crypto Boardjával végzett felülvizsgálat után használhatók.
  • Az ECDH- csak kulcscserére használható. Az új kódhoz =256 bites kulcsokkal rendelkező ECDH >szükséges. Az ECDH-alapú kulcscserének a három NIST által jóváhagyott görbe egyikét kell használnia (P-256, P-384 vagy P521). Az alaposan elemzett görbék csak a szervezet Crypto Boardjával végzett felülvizsgálat után használhatók.
  • A DSA – elfogadható lehet a szervezet kriptográfiai testületének felülvizsgálata és jóváhagyása után. Vegye fel a kapcsolatot biztonsági tanácsadójával a szervezet Crypto Board felülvizsgálatának ütemezéséhez. Ha a DSA használatát jóváhagyják, vegye figyelembe, hogy meg kell tiltania a 2048 bitnél rövidebb kulcsok használatát. A CNG a Windows 8-tól kezdve támogatja a 2048 bites és annál hosszabb kulcsokat.
  • A Diffie-Hellman- csak munkamenetkulcs-kezelésre használható. Az új kódhoz kulcshossz >= 2048 bit szükséges. A meglévő kód csak a visszamenőleges kompatibilitás érdekében támogathatja a < 2048 bites kulcsokat, miután a szervezet Crypto Board felülvizsgálta. Az 1024 bites kulcsok < nem használhatók.

    Használjon jóváhagyott véletlenszám-generátorokat

    Cím Részletek
    Komponens Webalkalmazás
    SDL-fázis Épít
    Alkalmazható technológiák Általános
    Attribútumok Nincs adat.
    hivatkozások Nincs adat.
    Lépések

    A termékeknek jóváhagyott véletlenszám-generátorokat kell használniuk. Ezért soha nem szabad ilyen kódban használni az olyan pszeudovéletlen függvényeket, mint a rand C futásidejű függvényt, a .NET Framework System.Random osztályt vagy a rendszerfüggvényeket, például a GetTickCount-t. Tilos a kettős elliptikus görbe véletlenszám-generátor (DUAL_EC_DRBG) algoritmus használata

    • CNG- BCryptGenRandom(a BCRYPT_USE_SYSTEM_PREFERRED_RNG jelző használata ajánlott, kivéve, ha a hívó 0-nál nagyobb IRQL-en fut [azaz PASSIVE_LEVEL])
    • CAPI- cryptGenRandom
    • Win32/64- RtlGenRandom (az új implementációknak BCryptGenRandom vagy CryptGenRandom kell használniuk) * rand_s * SystemPrng (kernel módhoz)
    • . NET- RNGCryptoServiceProvider vagy RNGCng
    • Windows Áruházbeli alkalmazások- Windows.Security.Cryptography.CryptographicBuffer.GenerateRandom vagy . Véletlenszám generálása
    • Apple OS X (10.7+)/iOS(2.0+)- int SecRandomCopyBytes (SecRandomRef véletlenszerű, size_t szám, uint8_t *bájt)
    • Apple OS X (<10.7) – Véletlen számok lekéréséhez használja a /dev/random parancsot
    • Java (beleértve a Google Android Java kódot) - java.security.SecureRandom osztály. Vegye figyelembe, hogy az Android 4.3 (Jelly Bean) esetében a fejlesztőknek követniük kell az Android által ajánlott megoldást, és frissíteniük kell alkalmazásaikat, hogy explicit módon inicializálják a PRNG-t a /dev/urandom vagy a /dev/random entrópiájával

    Ne használjon szimmetrikus adatfolyam-rejtjeleket

    Cím Részletek
    Komponens Webalkalmazás
    SDL-fázis Épít
    Alkalmazható technológiák Általános
    Attribútumok Nincs adat.
    hivatkozások Nincs adat.
    Lépések Szimmetrikus adatfolyam-rejtjeleket, például RC4-et nem szabad használni. A szimmetrikus adatfolyam-rejtjelek helyett a termékeknek blokkrejtjelet kell használniuk, különösen az AES-t, amelynek kulcshossza legalább 128 bit.

    Használjon jóváhagyott MAC/HMAC/kulcsos kivonatoló algoritmusokat

    Cím Részletek
    Komponens Webalkalmazás
    SDL-fázis Épít
    Alkalmazható technológiák Általános
    Attribútumok Nincs adat.
    hivatkozások Nincs adat.
    Lépések

    A termékek csak jóváhagyott üzenethitelesítési kód (MAC) vagy kivonatalapú üzenethitelesítési kód (HMAC) algoritmusokat használhatnak.

    Az üzenethitelesítési kód (MAC) egy üzenethez csatolt információ, amely lehetővé teszi a címzett számára, hogy titkos kulcs használatával ellenőrizze mind a feladó hitelességét, mind az üzenet integritását. A hash-alapú MAC (HMAC) vagy a blokk-rejtjel alapú MAC használata megengedett, amennyiben az összes mögöttes hash vagy szimmetrikus titkosítási algoritmus használatát is jóváhagyják; jelenleg ez magában foglalja a HMAC-SHA2 függvényeket (HMAC-SHA256, HMAC-SHA384 és HMAC-SHA512), valamint a CMAC/OMAC1 és OMAC2 blokk rejtjel alapú MAC-eket (ezek AES-en alapulnak).

    A HMAC-SHA1 használata megengedett lehet a platformkompatibilitás érdekében, de kivételt kell benyújtania ez alól az eljárás alól, és át kell esnie a szervezet kriptográfiai felülvizsgálatán. A HMAC-ok 128 bitnél kisebbre történő csonkítása nem megengedett. Az ügyfélmódszerek használata a kulcs és az adatok kivonatolásához nem engedélyezett, és használat előtt át kell esnie a szervezet Crypto Board felülvizsgálatán.

    Csak jóváhagyott kriptográfiai kivonatfüggvényeket használjon

    Cím Részletek
    Komponens Webalkalmazás
    SDL-fázis Épít
    Alkalmazható technológiák Általános
    Attribútumok Nincs adat.
    hivatkozások Nincs adat.
    Lépések

    A termékeknek az SHA-2 kivonatoló algoritmuscsaládot (SHA256, SHA384 és SHA512) kell használniuk. Ha rövidebb kivonatra van szükség, például 128 bites kimeneti hosszra, hogy illeszkedjen a rövidebb MD5-kivonatot szem előtt tartva tervezett adatstruktúrához, a termékcsapatok csonkolhatják az egyik SHA2-kivonatot (általában SHA256). Vegye figyelembe, hogy az SHA384 az SHA512 csonka változata. A kriptográfiai hash-ek biztonsági okokból 128 bitnél kisebbre csonkítása nem megengedett. Az új kód nem használhatja az MD2, MD4, MD5, SHA-0, SHA-1 vagy RIPEMD kivonatoló algoritmusokat. A hash-ütközések számítási szempontból megvalósíthatók ezeknél az algoritmusoknál, ami gyakorlatilag megszakítja őket.

    Engedélyezett .NET kivonatoló algoritmusok a felügyelt titkosítási agilitáshoz (preferencia sorrendben):

    • SHA512Cng (FIPS-kompatibilis)
    • SHA384Cng (FIPS-kompatibilis)
    • SHA256Cng (FIPS-kompatibilis)
    • SHA512Managed (nem FIPS-kompatibilis) (használja az SHA512-t algoritmusnévként a HashAlgorithm.Create vagy a CryptoConfig.CreateFromName hívásaiban)
    • SHA384Managed (nem FIPS-kompatibilis) (használja az SHA384-et algoritmusnévként a HashAlgorithm.Create vagy a CryptoConfig.CreateFromName hívásaiban)
    • SHA256Managed (nem FIPS-kompatibilis) (használja az SHA256-ot algoritmusnévként a HashAlgorithm.Create vagy a CryptoConfig.CreateFromName hívásaiban)
    • SHA512CryptoServiceProvider (FIPS-kompatibilis)
    • SHA256CryptoServiceProvider (FIPS-kompatibilis)
    • SHA384CryptoServiceProvider (FIPS-kompatibilis)

    Erős titkosítási algoritmusok használata az adatbázisban lévő adatok titkosításához

    Cím Részletek
    Komponens Adatbázis
    SDL-fázis Épít
    Alkalmazható technológiák Általános
    Attribútumok Nincs adat.
    hivatkozások Titkosítási algoritmus kiválasztása
    Lépések A titkosítási algoritmusok olyan adatátalakításokat határoznak meg, amelyeket jogosulatlan felhasználók nem tudnak könnyen visszafordítani. Az SQL Server lehetővé teszi a rendszergazdák és a fejlesztők számára, hogy számos algoritmus közül válasszanak, beleértve a DES, a Triple DES, a TRIPLE_DES_3KEY, az RC2, az RC4, a 128 bites RC4, a DESX, a 128 bites AES, a 192 bites AES és a 256 bites AES algoritmusokat

    Az SSIS-csomagokat titkosítani és digitálisan aláírni kell

    Cím Részletek
    Komponens Adatbázis
    SDL-fázis Épít
    Alkalmazható technológiák Általános
    Attribútumok Nincs adat.
    hivatkozások Digitális aláírással, fenyegetés- és sebezhetőségcsökkentéssel rendelkező csomagok forrásának azonosítása (Integration Services)
    Lépések A csomag forrása a csomagot létrehozó személy vagy szervezet. A csomagok ismeretlen vagy nem megbízható forrásból történő futtatása kockázatos lehet. Az SSIS-csomagok jogosulatlan manipulációjának megakadályozása érdekében digitális aláírásokat kell használni. A csomagok titkosságának biztosítása érdekében a tárolás/átvitel során az SSIS-csomagokat titkosítani kell

    Digitális aláírás hozzáadása a kritikus adatbázis-biztonsági eszközökhöz

    Cím Részletek
    Komponens Adatbázis
    SDL-fázis Épít
    Alkalmazható technológiák Általános
    Attribútumok Nincs adat.
    hivatkozások ALÁÍRÁS HOZZÁADÁSA (Transact-SQL)
    Lépések Azokban az esetekben, amikor egy kritikus fontosságú adatbázis sértetlenségét ellenőrizni kell, digitális aláírást kell használni. Az adatbázis biztonságos elemei, például egy tárolt eljárás, függvény, szerelvény vagy eseményindító digitálisan aláírhatók. Az alábbiakban egy példa látható arra, hogy ez mikor lehet hasznos: Tegyük fel, hogy egy független szoftverszállító támogatást nyújtott az egyik ügyfelének szállított szoftverhez. A támogatás nyújtása előtt az ISV-nek meg kell győződnie arról, hogy a szoftverben biztosított adatbázist nem módosították sem véletlenül, sem rosszindulatú kísérlettel. Ha a biztonságos eszköz digitálisan alá van írva, az ISV ellenőrizheti a digitális aláírását, és ellenőrizheti annak integritását.

    SQL Server EKM használata a titkosítási kulcsok védelméhez

    Cím Részletek
    Komponens Adatbázis
    SDL-fázis Épít
    Alkalmazható technológiák Általános
    Attribútumok Nincs adat.
    hivatkozások SQL Server bővíthető kulcskezelés (EKM),bővíthető kulcskezelés az Azure Key Vault használatával (SQL Server)
    Lépések SQL Server bővíthető kulcskezelés lehetővé teszi, hogy az adatbázisfájlokat védő titkosítási kulcsok egy beépített eszközön, például intelligens kártyán, USB-eszközön vagy EKM/HSM-modulon legyenek tárolva. Ez lehetővé teszi az adatbázis-rendszergazdák adatvédelmét is (kivéve a rendszergazdai csoport tagjait). Az adatok titkosítási kulcsokkal titkosíthatók, amelyekhez csak az adatbázis felhasználója férhet hozzá a külső EKM/HSM modulon.

    Használja az AlwaysEncrypted funkciót, ha a titkosítási kulcsokat nem szabad felfedni az adatbázismotor számára

    Cím Részletek
    Komponens Adatbázis
    SDL-fázis Épít
    Alkalmazható technológiák SQL Azure, OnPrem
    Attribútumok SQL-verzió – V12, MsSQL2016
    hivatkozások Always Encrypted (adatbázismotor)
    Lépések Az Always Encrypted egy olyan funkció, amely a bizalmas adatok, például a hitelkártyaszámok vagy a nemzeti/regionális azonosítószámok (például az Egyesült Államok társadalombiztosítási számai) védelmére szolgál, amelyek Azure SQL Database vagy SQL Server adatbázisokban tárolódnak. Az Always Encrypted lehetővé teszi, hogy az ügyfelek titkosítsanak bizalmas adatokat az ügyfélalkalmazások között, és soha ne fedik fel a titkosítási kulcsokat az adatbázismotor (SQL Database vagy SQL Server) számára. Ennek eredményeként az Always Encrypted elkülöníti azokat, akik az adatok tulajdonosai (és megtekinthetik azokat) és azokat, akik kezelik az adatokat (de nem férhetnek hozzá)

    Titkosítási kulcsok biztonságos tárolása IoT-eszközön

    Cím Részletek
    Komponens IoT-készülék
    SDL-fázis Épít
    Alkalmazható technológiák Általános
    Attribútumok Eszköz operációs rendszere – Windows IoT Core, eszközkapcsolat – Azure IoT eszközoldali SDK-k
    hivatkozások TPM Windows IoT Core-on, TPM beállítása Windows IoT Core-on, Azure IoT Device SDK TPM
    Lépések Szimmetrikus vagy tanúsítvány Privát kulcsok biztonságosan hardveresen védett tárolóban, például TPM-ben vagy intelligenskártya-chipekben. Windows 10 IoT Core támogatja a TPM felhasználóját, és számos kompatibilis TPM használható: Diszkrét TPM (dTPM). Javasoljuk, hogy használjon firmware-t vagy különálló TPM-et. A szoftveres TPM csak fejlesztési és tesztelési célokra használható. Ha egy TPM elérhetővé válik, és a kulcsok ki vannak építve benne, a jogkivonatot létrehozó kódot bizalmas információk kódolása nélkül kell megírni.

    példa

    TpmDevice myDevice = new TpmDevice(0);
    // Use logical device 0 on the TPM 
    string hubUri = myDevice.GetHostName(); 
    string deviceId = myDevice.GetDeviceId(); 
    string sasToken = myDevice.GetSASToken(); 
    
    var deviceClient = DeviceClient.Create( hubUri, AuthenticationMethodFactory. CreateAuthenticationWithToken(deviceId, sasToken), TransportType.Amqp); 
    

    Mint látható, az eszköz elsődleges kulcsa nincs jelen a kódban. Ehelyett a TPM-ben tárolja a 0. tárolóhelyen. A TPM-eszköz létrehoz egy rövid élettartamú SAS-jogkivonatot, amely ezután a IoT Hubhoz való csatlakozáshoz használható.

    Megfelelő hosszúságú véletlenszerű szimmetrikus kulcs létrehozása a IoT Hub hitelesítéséhez

    Cím Részletek
    Komponens IoT Cloud Gateway
    SDL-fázis Épít
    Alkalmazható technológiák Általános
    Attribútumok Átjáróválasztás – Azure IoT Hub
    hivatkozások Nincs adat.
    Lépések IoT Hub tartalmaz egy eszközidentitás-nyilvántartást, és az eszköz kiépítése közben automatikusan létrehoz egy véletlenszerű szimmetrikus kulcsot. Javasoljuk, hogy használja a Azure IoT Hub Identity Registry ezen funkcióját a hitelesítéshez használt kulcs létrehozásához. IoT Hub lehetővé teszi egy kulcs megadását is az eszköz létrehozásakor. Ha egy kulcs a IoT Hubon kívül jön létre az eszköz kiépítése során, javasoljuk, hogy hozzon létre egy véletlenszerű szimmetrikus kulcsot vagy legalább 256 bitet.

    Győződjön meg arról, hogy van olyan eszközkezelési szabályzat, amely PIN-kódot igényel, és lehetővé teszi a távoli törlést

    Cím Részletek
    Komponens Dynamics CRM mobil kliens
    SDL-fázis Telepítés
    Alkalmazható technológiák Általános
    Attribútumok Nincs adat.
    hivatkozások Nincs adat.
    Lépések Győződjön meg arról, hogy van olyan eszközkezelési szabályzat, amely PIN-kódot igényel, és lehetővé teszi a távoli törlést

    Győződjön meg arról, hogy van olyan eszközkezelési szabályzat, amely PIN-kódot/jelszót/automatikus zárolást igényel, és titkosítja az összes adatot (pl. BitLocker)

    Cím Részletek
    Komponens Dynamics CRM Outlook ügyfél
    SDL-fázis Épít
    Alkalmazható technológiák Általános
    Attribútumok Nincs adat.
    hivatkozások Nincs adat.
    Lépések Győződjön meg arról, hogy van olyan eszközkezelési szabályzat, amely PIN-kódot/jelszót/automatikus zárolást igényel, és titkosítja az összes adatot (pl. BitLocker)

    Győződjön meg arról, hogy az aláírókulcsok át vannak állítva az identitáskiszolgáló használatakor

    Cím Részletek
    Komponens Identitáskiszolgáló
    SDL-fázis Telepítés
    Alkalmazható technológiák Általános
    Attribútumok Nincs adat.
    hivatkozások Nincs adat.
    Lépések Győződjön meg arról, hogy az aláíró kulcsok át vannak állítva az Identity Server használatakor. A hivatkozások szakaszban található hivatkozás ismerteti, hogyan kell ezt megtervezni anélkül, hogy kimaradásokat okozna az Identity Serverre támaszkodó alkalmazásokban.

    Győződjön meg arról, hogy kriptográfiailag erős ügyfél-azonosítót és titkos ügyfélkódot használ az identitáskiszolgáló

    Cím Részletek
    Komponens Identitáskiszolgáló
    SDL-fázis Épít
    Alkalmazható technológiák Általános
    Attribútumok Nincs adat.
    hivatkozások Nincs adat.
    Lépések

    Győződjön meg arról, hogy a rendszer kriptográfiailag erős ügyfél-azonosítót és titkos ügyfélkódot használ az Identity Server. Az ügyfél-azonosító és a titkos kód létrehozásakor a következő irányelveket kell használni:

    • Véletlenszerű GUID azonosító létrehozása ügyfél-azonosítóként
    • Kriptográfiailag véletlenszerű 256 bites kulcs generálása titkosként