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. CryptSetProviderExaffects 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_STATUSstructure.

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 CryptGenRandomto generate random data.

Protect application data

To protect sensitive information and to prevent data tampering, use CryptProtectDataand CryptUnprotectData. When appropriate, the application should obtain an additional password or other secret data from the user, and then use pOptionalEntropyto supply the information to CryptProtectDataand CryptUnprotectData.

Note:
Although CryptProtectDataand CryptUnprotectDatause 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\DisallowSavedNetworkPasswordsidentifies 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.

You should be aware of the registry settings that apply to security. If a value has security implications, you will find a Security Notein 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 for CryptProtectDataand CryptUnprotectDatastored in the registry, an unauthorized user can gain access to them more easily.