Cryptography Security
A version of this page is also available for
4/8/2010
CryptoAPI handles credentials and other assets that unauthorized users can access. The following list summarizes the best practices for protecting these assets.
Best Practices
Call CryptGetKeyParam to get key length
Your application should verify the key length of the encryption algorithm before using the default service provider. This ensures that the application is using the correct provider. The application can delete or reset the default provider for a device by changing the registry or by calling CryptSetProviderEx. Avoid using CryptSetProviderEx, except as a part of the administrative setup of a device. CryptSetProviderEx affects the behavior of applications that rely on the default behavior of CryptoAPI.
Check certificate status
Applications calling CryptoAPI must check the certificate status retrieved by certain cryptography functions. This will prevent an attacker from using a key pair or certificate that has been revoked to sign digital data. Possible certificate statuses are defined for the CERT_TRUST_STATUS structure.
Protect private keys and user credentials
CryptoAPI stores private keys and applications store user credentials on each device. To prevent hackers from tampering with private keys and/or extracting the user credentials, you must implement a device locking capability that requires a password to access the device when it is powered on. Also, for optimum protection, you can use a smart card to store private keys and use the Smart Card CSP. Implementing proper device protection mechanisms is crucial to the safety of private keys and user credentials.
Do not create your own random number generator
Use CryptGenRandom to generate random data.
Protect application data
To protect sensitive information and to prevent data tampering, use CryptProtectData and CryptUnprotectData. When appropriate, the application should obtain an additional password or other secret data from the user, and then use pOptionalEntropy to supply the information to CryptProtectData and CryptUnprotectData.
Note
Although CryptProtectData and CryptUnprotectData use entropy, the encryption is only as strong as the user data supplied for encryption. It is important for the user to supply a strong password. A user who supplies a weak password can weaken the effectiveness of encryption.
Clear data from temporary storage after use
Your application should clear data from temporary storage after use by calling SecureZeroMemory. In addition, the application should not store a secret key itself. For example, if the application needs to verify that a user knows a password, it can compare the hash of the secret key entered by the user with the hash of the application-stored secret key. In this case, the application only needs to store the hash.
Save sensitive data
If possible, do not save sensitive data in RAM, the file system, or the registry. Instead, cache the data to process memory. Give the user a choice whether to save sensitive information, such as credentials. The registry setting HKEY_LOCAL_MACHINE\Comm\Security\DisallowSavedNetworkPasswords identifies whether the option to save credentials is displayed. When the value is 1, the user interface (UI) does not display an option to save credentials. When the value is 0, the UI allows the user to save credentials.
Default Registry Settings
You should be aware of the registry settings that apply to security. If a value has security implications, you will find a Security Note in the registry settings documentation.
For information about cryptography registry settings, see Cryptography Registry Settings.
It is important to note that if you have the encryption keys forCryptProtectData andCryptUnprotectData stored in the registry, an unauthorized user can gain access to them more easily.
See Also
Concepts
Microsoft Enhanced Cryptographic Provider