2 out of 5 rated this helpful - Rate this topic

Threat Mitigation Techniques

There are a number of threat-mitigation techniques available that you can use to better secure passwords. These techniques are implemented by using one or more of the following four, primary technologies.

TechnologyDescription
CryptoAPICryptoAPI provides a set of functions that help you apply cryptographic routines to target entities. CryptoAPI can provide hashes, digests, encryption, and decryption, to mention its primary functionality. CryptoAPI also has other features. To learn about cryptography and the CryptoAPI, see Cryptography Essentials.
Access control listsAn access control list (ACL) is a list of security protections that applies to an object. An object can be a file, process, event, or anything else that has a security descriptor. For more information on ACLs see Access Control Lists (ACLs).
Data protection APIThe data protection API (DPAPI) provides the following four functions that you use to encrypt and decrypt sensitive data: CryptProtectData, CryptUnprotectData, CryptProtectMemory, and CryptUnprotectMemory.
Stored user names and passwordsStorage functionality that makes handling users' passwords and other credentials, such as private keys, easier, more consistent, and safer. For more information on this functionality, see CredUIPromptForCredentials.

 

These technologies are not available on all operating systems. Therefore, the extent to which security can be improved depends on which operating systems are involved. Here are the technologies that are available in each operating system.

Operating systemTechnology
Windows Server 2003 and Windows XP
  • CryptoAPI
  • Access control lists
  • Data protection API
  • Stored user names and passwords
Windows 2000

 

The following threat-mitigation techniques use one or more of the four technologies. Techniques that require the use of technologies that are not included in the operating system cannot be used.

Getting Passwords from the User

When you allow the user to set up a password, force the use of strong passwords. For example, require that passwords be a minimum length such as eight characters or more. Passwords should also be required to include uppercase and lowercase letters, numbers, and other keyboard characters such as the dollar sign ($), exclamation point (!), or greater than (>).

After you get a password, use it quickly (using as little code as possible), and then erase all vestiges of the password. This minimizes the time available to an intruder to "trap" the password. The tradeoff with this technique is the frequency with which the password must be retrieved from the user; however, the principle should be employed wherever possible. For information about how to properly get passwords, see Asking the User for Credentials.

Avoid providing "remember my password" user interface options. Often, users will demand to have this option. If you must provide it, then at minimum, ensure that the password gets saved in a secure fashion. For information, see the Storing Passwords section, later in this topic.

Limit password entry tries. After a certain number of tries without success, lock out the user for a certain length of time. Optionally, lengthen the response time for each try over a maximum. This technique is aimed at defeating a guessing attack.

Storing Passwords

Never store passwords in plaintext (unencrypted). Encrypting passwords significantly increases their security. For information about storing encrypted passwords, see CryptProtectData. For information about encrypting passwords in memory, see CryptProtectMemory. Store passwords in as few places as possible. The more places a password is stored, the greater the chance that an intruder might find it. Never store passwords in a webpage or in a web-based file. Storing passwords in a webpage or in a web-based file allows them to be easily compromised.

After you have encrypted a password and stored it, use secure ACLs to limit access to the file. Alternatively, you can store passwords and encryption keys on removable devices. Storing passwords and encryption keys on a removable media, such as a smart card, helps create a more secure system. After a password is retrieved for a given session, the card can be removed, thereby removing the possibility that an intruder can gain access to it.

 

 

Send comments about this topic to Microsoft

Build date: 3/6/2012

Did you find this helpful?
(1500 characters remaining)
Community Content Add
Annotations FAQ
Don't store passwords at all (not even encrypted)!
Storing passwords just to be able to compare them to passwords coming from users or other programs, no matter how well you encrypt them (whether using DAPI or not) is not good practice. Any password that is encrypted can be decrypted, and you are better off to eliminate the risk of decryption completely. The preferred method is to store a salted iteratively hashed verifier. For a .NET example, see System.Security.Cryptography.Rfc2898DeriveBytes. For a more classic example, note that Windows (any NT-based version) itself stores only hashes of the users password in the local users database (SAM) and on the Active Directory Servers. However because recovering human-chosen or simple passwords from hash values is a routine attack technique, protecting and encrypting the stored hash value is still best practice.

However replacing a password by a one-way hash is useless if you are storing the password because you need your program to authenticate itself to some other program or service which wants a password from your program to let it in. In that case you simply need to recover the actual password value for a brief moment during the actual authentication, and the options are to store the password completely unprotected (bad idea) or to protect it with as many layers of encryption and obfuscation as you can afford.

In summary: The best practices on this page applies to plain passwords needed to authenticate your program to other programs and to one-way hash values used by your program to authenticate requests from other programs.