OWASP - User contributions [en]

Cryptographic Storage Cheat Sheet

2011-01-14T06:58:19Z

Kkenan: Cleaning up.

= Introduction =

This article provides a simple model to follow when implementing solutions for data at rest. 

== Architectural Decision ==

An architectural decision must be made to determine the appropriate method to protect data at rest. There are such wide variety of products, methods and mechanisms for cryptographic storage that this cheat sheet will only focus on low-level guidelines for developers and architects who are implementing cryptographic solutions. We will not address specific vendor solutions, nor will we address the design of cryptographic algorithms.

= Providing Cryptographic Functionality =

== Benefits ==

== Basic Requirements ==

== Secure Cryptographic Storage Design ==

=== Rule - Only store sensitive data that you need ===

Many eCommerce businesses use payment providers that store the credit card for recurring billing. This offloads the burden of keeping credit card numbers safe.

=== Rule - Only use strong cryptographic algorithms ===

Only use approved public algorithms such as AES, RSA public key cryptography, and SHA-256 or better for hashing. Do not use weak algorithms, such as MD5 / SHA1/ Favor safer. The definition of a "strong" cryptographic algorithms change over time.

http://csrc.nist.gov/groups/STM/cavp/index.html

This is a good default if one doesn't have AES and one of the authenticated encryption modes that provide confidentiality and authenticity (i.e., data origin authentication) such as CCM, EAX, CMAC, etc. For Java, if you are using SunJCE that will be the case. The cipher modes supported in JDK 1.5 and later are CBC, CFB, CFBx, CTR, CTS, ECB, OFB, OFBx, PCBC, None of these cipher modes are authentication encryption modes. (That's why I added it explicitly.) If you are using an alternate JCE provider such as Bouncy Castle, RSA JSafe, IAIK, etc then some of these authentication encryption modes probably should be preferred.

Use salts when appropriate. Note that integrity should use a MAC such as HMAC-SHA1 or even better, HMAC-SHA256.

==== Rule - Ensure that random numbers are cryptographically strong ====

Ensure that all random numbers, random file names, random GUIDs, and random strings are generated in a cryptographically strong fashion. Also ensure that random algorithms are seeded with sufficient entropy.

==== Rule - Only use widely accepted implementations of cryptographic algorithms ====

Do not implement an existing cryptographic algorithm on your own, no matter how easy it appears. Use widely accepted algorithms and widely accepted implementations only. Ensure that an implementation has, at least, had some cryptography experts involved in its creation. If possible, use an implementation that is FIPS 140-2 certified.

==== Rule - Prefer authenticated encryption modes ====

Use cryptographic cipher modes that offer both confidentiality and authenticity. Recommended modes include counter with CBC-MAC (CCM) mode and Galois/counter mode (GCM). These authenticated encryption (AE) modes resist padding oracle attacks which can be used in many cases to recover plaintext from ciphertext without knowledge of the encryption key.

If an authenticated encryption mode is not available, then the best option is to consult with a professional cryptographer. Ask the cryptographer to review and customize the system to counter padding oracle attacks. This customization will typically involve the use of a message authentication code (MAC) that must be carefully employed in order to be effective.

In the worst case, where neither an AE mode nor a professional cryptographer is available, then the cryptography is definitely vulnerable to a padding oracle attack. The best that can be done in this situation is to design the overall system so that the decryption function is only given ciphertext retrieved directly from a canonical source which must itself be protected by other integrity controls. While this technique will help reduce the risk of a padding oracle attack, it does not eliminate the risk, and it should be treated as a temporary workaround until an AE-based solution can be implemented.

When selecting a cryptographic mode for this worse case, cipher-block chaining (CBC) mode is a strong choice as it has been carefully studied, is well understood, and is readily available in many cryptographic APIs. In all cases avoid the electronic codebook (ECB) mode. If using cipher modes that create streaming ciphers from block ciphers, such as the output feedback (OFB) or cipher feedback (CFB) modes, be careful not to repeat the IV for the same encryption key.

See [http://www.cryptopp.com/wiki/Authenticated_Encryption Authenticated Encryption] on the Crypto++ wiki for a more complete discussion of the technique. NIST's CRSC [http://csrc.nist.gov/groups/ST/toolkit/BCM/current_modes.html Current Modes] and [http://csrc.nist.gov/groups/ST/toolkit/BCM/modes_development.html Modes Development] documents offer an abbreviated list of cipher modes. Additional block cipher modes can be found in Wikipedia's [http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation Block cipher modes of operation] article.

=== Rule - Store the hashed and salted value of passwords ===

Store the salted hashed value of the password. Salt each hash. Use a different random salt for each password hash. Never store the clear text password or an encrypted version of the password.

Cryptographic framework for password hashing is described in [http://www.rsa.com/rsalabs/node.asp?id=2127 PKCS #5 v2.1: Password-Based Cryptography Standard]. Specific secure password hashing algorithms exist such as [http://www.usenix.org/events/usenix99/provos/provos_html/node1.html bcrypt], [http://www.tarsnap.com/scrypt/scrypt.pdf scrypt]. Implementations of secure password hashing exist for PHP ([http://www.openwall.com/phpass/ phpass]), ASP.NET ([http://msdn.microsoft.com/en-us/library/ms998372.aspx#pagpractices0001_sensitivedata ASP.NET 2.0 Security Practices]), Java ([http://www.owasp.org/index.php/Hashing_Java OWASP Hashing Java]).

=== Rule - Ensure that the cryptographic protection remains secure even if access controls fail ===

This rule supports the principle of defense in depth. Access
controls (usernames, passwords, privileges, etc.) are one layer of
protection. Storage encryption should add an additional layer of
protection that will continue protecting the data even if an
attacker subverts the database access control layer.

=== Rule - Ensure that any secret key is protected from unauthorized access ===

==== Rule - Define a key lifecycle ====

The key lifecycle details the various states that a key will move through during its life. The lifecycle will specify when a key should no longer be used for encryption, when a key should no longer be used for decryption (these are not necessarily coincident), whether data must be rekeyed when a new key is introduced, and when a key should be removed from use all together.

==== Rule - Store unencrypted keys away from the encrypted data ====

If the keys are stored with the data then any compromise of the data will easily compromise the keys as well. Unencrypted keys should never reside on the same machine or cluster as the data.

==== Rule - Use independent keys when multiple keys are required ====

Ensure that key material is independent. That is, do not choose a second key which is easily related to the first (or any preceeding) keys.

==== Rule - Protect keys in a key vault ====

Keys should remain in a protected key vault at all times. In particular, ensure that there is a gap between the threat vectors with direct access to the data and the threat vectors with direct access to the keys. This implies that keys should not be stored on the application or web server (assuming that application attackers are part of the relevant threat model).

==== Rule - Document concrete procedures for managing keys through the lifecycle ====

These procedures must be written down and the key custodians must be adequately trained.

==== Rule - Build support for changing keys periodically ====

Key rotation is a must as all good keys do come to an end either through expiration or revocation. So a developer will have to deal with rotating keys at some point -- better to have a system in place now rather than scrambling later. (From Bil Cory as a starting point).

==== Rule - Document concrete procedures to handle a key compromise ====

==== Rule - Rekey data at least every one to three years ====

Rekeying refers to the process of decrypting data and then re-encrypting it with a new key. Periodically rekeying data helps protect it from undetected compromises of older keys. The appropriate rekeying period depends on the security of the keys. Data protected by keys secured in dedicated hardware security modules might only need rekeying every three years. Data protected by keys that are split and stored on two application servers might need rekeying every year.

=== Rule - Follow applicable regulations on use of cryptography ===

==== Rule - Under PCI DSS requirement 3, you must protect cardholder data ====

The Payment Card Industry (PCI) Data Security Standard (DSS) was developed to encourage and enhance cardholder data security and facilitate the broad adoption of consistent data security measures globally. The standard was introduced in 2005 and replaced individual compliance standards from Visa, Mastercard, Amex, JCB and Diners. The current version of the standard was introduced in 2008 and an update to the standard is expected in 2010.

PCI DSS requirement 3 covers secure storage of credit card data. This requirement covers several aspects of secure storage including the data you must never store but we are covering Cryptographic Storage which is covered in requirements 3.4, 3.5 and 3.6 as you can see below:

'''3.4 Render PAN (Primary Account Number), at minimum, unreadable anywhere it is stored'''

Compliance with requirement 3.4 can be met by implementing any of the four types of secure storage described in the standard which includes encrypting and hashing data. These two approaches will often be the most popular choices from the list of options. The standard doesn't refer to any specific algorithms but it mandates the use of '''Strong Cryptography'''. The glossary document from the PCI council defines '''Strong Cryptography''' as:

''Cryptography based on industry-tested and accepted algorithms, along with strong key lengths and proper key-management practices. Cryptography is a method to protect data and includes both encryption (which is reversible) and hashing (which is not reversible, or “one way”). SHA-1 is an example of an industry-tested and accepted hashing algorithm. Examples of industry-tested and accepted standards and algorithms for encryption include AES (128 bits and higher), TDES (minimum double-length keys), RSA (1024 bits and higher), ECC (160 bits and higher), and ElGamal (1024 bits and higher).''

If you have implemented the second rule in this cheat sheet you will have implemented a strong cryptographic algorithm which is compliant with or stronger than the requirements of PCI DSS requirement 3.4 You need to ensure that you identify all locations that card data could be stored including logs and apply the appropriate level of protection. This could range from encrypting the data to replacing the card number in logs.

This requirement can also be met by implementing disk encryption rather than file or column level encryption. The requirements for '''Strong Cryptography''' are the same for disk encryption and backup media. The card data should never be stored in the clear and by following the guidance in this cheat sheet you will be able to securely store your data in a manner which is compliant with PCI DSS requirement 3.4

'''3.5 Protect cryptographic keys used for encryption of cardholder data against both disclosure and misuse'''

As the requirement name above indicates we are required to securely store the encryption keys themselves. This will mean implementing strong access control, auditing and logging for your keys. The keys must be stored in a location which is both secure and "away" from the encrypted data, this means key data shouldn't be stored on web servers, database servers etc

Access to the keys must be restricted to the smallest amount of users possible. This group of users will ideally be users who are highly trusted and trained to perform Key Custodian duties. There will obviously be a requirement for system/service accounts to access the key data to perform encryption/decryption of data.

The keys themselves shouldn't be stored in the clear but encrypted with a KEK (Key Encrypting Key). The KEK must not be stored in the same location as the encryption keys it is encrypting.

'''3.6 Fully document and implement all key-management processes and procedures for cryptographic keys used for encryption of cardholder data'''

Requirement 3.6 mandates that key management processes within a PCI compliant company cover 8 specific key lifecycle steps:

'''3.6.1 Generation of strong cryptographic keys'''

As we have previously described in this cheat sheet we need to use algorithms which offer high levels of data security. We must also generate strong keys so that the security of the data isn't undermined by weak cryptographic keys. A strong key is generated by using a key length which is sufficient for your data security requirements and compliant with the PCI DSS. The key size alone isn't a measure of the strength of a key. The data used to generate the key must be sufficiently random ("sufficient" often being determined by your data security requirements) and the entropy of the key data itself must be high. 

'''3.6.2 Secure cryptographic key distribution'''

The method used to distribute keys must be secure to prevent the theft of keys in transit. The use of a protocol such as Diffie Hellman can help secure the distribution of keys, the use of secure transport such as SSLv3, TLS and SSHv2 can also secure the keys in transit. 

'''3.6.3 Secure cryptographic key storage'''

The secure storage of encryption keys including KEK's has been touched on in our description of requirement 3.5 (see above).

'''3.6.4 Periodic cryptographic key changes'''

The PCI DSS standard mandates that keys used for encryption must be rotated at least annually. The key rotation process must remove an old key from the encryption/decryption process and replace it with a new key. All new data entering the system must encrypted with the new key. While it is recommended that existing data be rekeyed with the new key, as per the Rekey data at least every one to three years rule above, it is not clear that the PCI DSS requires this.

'''3.6.5 Retirement or replacement of old or suspected compromised cryptographic keys'''

The key management processes must cater for archived, retired or compromised keys. The process of securely storing and replacing these keys will more than likely be covered by your processes for requirements 3.6.2, 3.6.3 and 3.6.4

'''3.6.6 Split knowledge and establishment of dual control of cryptographic keys'''

The requirement for split knowledge and/or dual control for key management prevents an individual user performing key management tasks such as key rotation or deletion. The system should require two individual users to perform an action (i.e. entering a value from their own OTP) which creates to separate values which are concatenated to create the final key data.

'''3.6.7 Prevention of unauthorized substitution of cryptographic keys'''

The system put in place to comply with requirement 3.6.6 can go a long way to preventing unauthorised substitution of key data. In addition to the dual control process you should implement strong access control, auditing and logging for key data so that unauthorised access attempts are prevented and logged.

'''3.6.8 Requirement for cryptographic key custodians to sign a form stating that they understand and accept their key-custodian responsibilities'''

To perform the strong key management functions we have seen in requirement 3.6 we must have highly trusted and trained key custodians who understand how to perform key management duties. The key custodians must also sign a form stating they understand the responsibilities that come with this role.

= Related Articles =

OWASP - [[Testing for SSL-TLS (OWASP-CM-001)|Testing for SSL-TLS]], and OWASP [[Guide to Cryptography]]

OWASP – [http://www.owasp.org/index.php/ASVS Application Security Verification Standard (ASVS) – Communication Security Verification Requirements (V10)]

{{Cheatsheet_Navigation}}

= Authors and Primary Editors =

Kevin Kenan - kevin[at]k2dd.com

David Rook - david.a.rook[at]gmail.com

Kevin Wall - kevin.w.wall[at]gmail.com

Jim Manico - jim[at]manico.net

[[Category:How_To]] [[Category:Cheatsheets]] [[Category:OWASP_Document]] [[Category:OWASP_Top_Ten_Project]]

Cryptographic Storage Cheat Sheet

2011-01-14T00:09:38Z

Kkenan: /* Rule - Prefer authenticated encryption modes */

= Introduction =

This article provides a simple model to follow when implementing solutions for data at rest. 

== Architectural Decision ==

An architectural decision must be made to determine the appropriate method to protect data at rest. There are such wide variety of products, methods and mechanisms for cryptographic storage that this cheat sheet will only focus on low-level guidelines for developers and architects who are implementing cryptographic solutions. We will not address specific vendor solutions, nor will we address the design of cryptographic algorithms.

= Providing Cryptographic Functionality =

== Benefits ==

== Basic Requirements ==

== Secure Cryptographic Storage Design ==

=== Rule - Only store sensitive data that you need ===

Many eCommerce businesses use payment providers that store the credit card for recurring billing. This offloads the burden of keeping credit card numbers safe.

=== Rule - Only use strong cryptographic algorithms ===

Only use approved public algorithms such as AES, RSA public key cryptography, and SHA-256 or better for hashing. Do not use weak algorithms, such as MD5 / SHA1/ Favor safer. The definition of a "strong" cryptographic algorithms change over time.

http://csrc.nist.gov/groups/STM/cavp/index.html

This is a good default if one doesn't have AES and one of the authenticated encryption modes that provide confidentiality and authenticity (i.e., data origin authentication) such as CCM, EAX, CMAC, etc. For Java, if you are using SunJCE that will be the case. The cipher modes supported in JDK 1.5 and later are CBC, CFB, CFBx, CTR, CTS, ECB, OFB, OFBx, PCBC, None of these cipher modes are authentication encryption modes. (That's why I added it explicitly.) If you are using an alternate JCE provider such as Bouncy Castle, RSA JSafe, IAIK, etc then some of these authentication encryption modes probably should be preferred.

Use salts when appropriate. Note that integrity should use a MAC such as HMAC-SHA1 or even better, HMAC-SHA256.

==== Rule - Ensure that random numbers are cryptographically strong ====

Ensure that all random numbers, random file names, random GUIDs, and random strings are generated in a cryptographically strong fashion. Also ensure that random algorithms are seeded with sufficient entropy.

==== Rule - Only use widely accepted implementations of cryptographic algorithms ====

Do not implement an existing cryptographic algorithm on your own, no matter how easy it appears. Use widely accepted algorithms and widely accepted implementations only. Ensure that an implementation has, at least, had some cryptography experts involved in its creation. If possible, use an implementation that is FIPS 140-2 certified.

==== Rule - Prefer authenticated encryption modes ====

Use cryptographic cipher modes that offer both confidentiality and authenticity. Recommended modes include counter with CBC-MAC (CCM) mode and Galois/counter mode (GCM). These authenticated encryption (AE) modes resist padding oracle attacks which can be used in many cases to recover plaintext from encrypted text without knowledge of the encryption key.

If an authenticated encryption mode is not available, then the best option is to consult with a professional cryptographer. Ask the cryptographer to review and customize the system to counter padding oracle attacks. This customization will typically involve the use of a message authentication code (MAC) that must be carefully employed in order to be effective.

In the worst case, where neither an AE mode nor a professional cryptographer is available, then the cryptography is definitely vulnerable to a padding oracle attack. The best that can be done in this situation is to design the overall system so that the decryption function is only given ciphertext retrieved directly from a canonical source which must itself be protected by other integrity controls. While this technique will help reduce the risk of a padding oracle attack, it does not eliminate the risk, and it should be treated as a temporary workaround until an AE-based solution can be implemented.

When selecting a cryptographic mode for this worse case, cipher-block chaining (CBC) mode is a strong choice as it has been carefully studied, is well understood, and is readily available in many cryptographic APIs. In all cases avoid the electronic code book (ECB) mode. If using cipher modes that create streaming ciphers from block ciphers, such as the output feedback (OFB) or cipher feedback (CFB) modes, be careful not to repeat the IV for the same encryption key.

See [http://www.cryptopp.com/wiki/Authenticated_Encryption Authenticated Encryption] on the Crypto++ wiki for a more complete discussion of the technique. NIST's CRSC [http://csrc.nist.gov/groups/ST/toolkit/BCM/current_modes.html Current Modes] and [http://csrc.nist.gov/groups/ST/toolkit/BCM/modes_development.html Modes Dvelopment] offer an abbreviated list of cipher modes. Additional block cipher modes can be found at Wikipedia's [http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation Block cipher modes of operation].

=== Rule - Store the hashed and salted value of passwords ===

Store the salted hashed value of the password. Salt each hash. Use a different random salt for each password hash. Never store the clear text password or an encrypted version of the password.

Cryptographic framework for password hashing is described in [http://www.rsa.com/rsalabs/node.asp?id=2127 PKCS #5 v2.1: Password-Based Cryptography Standard]. Specific secure password hashing algorithms exist such as [http://www.usenix.org/events/usenix99/provos/provos_html/node1.html bcrypt], [http://www.tarsnap.com/scrypt/scrypt.pdf scrypt]. Implementations of secure password hashing exist for PHP ([http://www.openwall.com/phpass/ phpass]), ASP.NET ([http://msdn.microsoft.com/en-us/library/ms998372.aspx#pagpractices0001_sensitivedata ASP.NET 2.0 Security Practices]), Java ([http://www.owasp.org/index.php/Hashing_Java OWASP Hashing Java]).

=== Rule - Ensure that the cryptographic protection remains secure even if access controls fail ===

This rule supports the principle of defense in depth. Access
controls (usernames, passwords, privileges, etc.) are one layer of
protection. Storage encryption should add an additional layer of
protection that will continue protecting the data even if an
attacker subverts the database access control layer.

=== Rule - Ensure that any secret key is protected from unauthorized access ===

==== Rule - Define a key lifecycle ====

The key lifecycle details the various states that a key will move through during its life. The lifecycle will specify when a key should no longer be used for encryption, when a key should no longer be used for decryption (these are not necessarily coincident), whether data must be rekeyed when a new key is introduced, and when a key should be removed from use all together.

==== Rule - Store unencrypted keys away from the encrypted data ====

If the keys are stored with the data then any compromise of the data will easily compromise the keys as well. Unencrypted keys should never reside on the same machine or cluster as the data.

==== Rule - Use independent keys when multiple keys are required ====

Ensure that key material is independent. That is, do not choose a second key which is easily related to the first (or any preceeding) keys.

==== Rule - Protect keys in a key vault ====

Keys should remain in a protected key vault at all times. In particular, ensure that there is a gap between the threat vectors with direct access to the data and the threat vectors with direct access to the keys. This implies that keys should not be stored on the application or web server (assuming that application attackers are part of the relevant threat model).

==== Rule - Document concrete procedures for managing keys through the lifecycle ====

These procedures must be written down and the key custodians must be adequately trained.

==== Rule - Build support for changing keys periodically ====

Key rotation is a must as all good keys do come to an end either through expiration or revocation. So a developer will have to deal with rotating keys at some point -- better to have a system in place now rather than scrambling later. (From Bil Cory as a starting point).

==== Rule - Document concrete procedures to handle a key compromise ====

==== Rule - Rekey data at least every one to three years ====

Rekeying refers to the process of decrypting data and then re-encrypting it with a new key. Periodically rekeying data helps protect it from undetected compromises of older keys. The appropriate rekeying period depends on the security of the keys. Data protected by keys secured in dedicated hardware security modules might only need rekeying every three years. Data protected by keys that are split and stored on two application servers might need rekeying every year.

=== Rule - Follow applicable regulations on use of cryptography ===

==== Rule - Under PCI DSS requirement 3, you must protect cardholder data ====

The Payment Card Industry (PCI) Data Security Standard (DSS) was developed to encourage and enhance cardholder data security and facilitate the broad adoption of consistent data security measures globally. The standard was introduced in 2005 and replaced individual compliance standards from Visa, Mastercard, Amex, JCB and Diners. The current version of the standard was introduced in 2008 and an update to the standard is expected in 2010.

PCI DSS requirement 3 covers secure storage of credit card data. This requirement covers several aspects of secure storage including the data you must never store but we are covering Cryptographic Storage which is covered in requirements 3.4, 3.5 and 3.6 as you can see below:

'''3.4 Render PAN (Primary Account Number), at minimum, unreadable anywhere it is stored'''

Compliance with requirement 3.4 can be met by implementing any of the four types of secure storage described in the standard which includes encrypting and hashing data. These two approaches will often be the most popular choices from the list of options. The standard doesn't refer to any specific algorithms but it mandates the use of '''Strong Cryptography'''. The glossary document from the PCI council defines '''Strong Cryptography''' as:

''Cryptography based on industry-tested and accepted algorithms, along with strong key lengths and proper key-management practices. Cryptography is a method to protect data and includes both encryption (which is reversible) and hashing (which is not reversible, or “one way”). SHA-1 is an example of an industry-tested and accepted hashing algorithm. Examples of industry-tested and accepted standards and algorithms for encryption include AES (128 bits and higher), TDES (minimum double-length keys), RSA (1024 bits and higher), ECC (160 bits and higher), and ElGamal (1024 bits and higher).''

If you have implemented the second rule in this cheat sheet you will have implemented a strong cryptographic algorithm which is compliant with or stronger than the requirements of PCI DSS requirement 3.4 You need to ensure that you identify all locations that card data could be stored including logs and apply the appropriate level of protection. This could range from encrypting the data to replacing the card number in logs.

This requirement can also be met by implementing disk encryption rather than file or column level encryption. The requirements for '''Strong Cryptography''' are the same for disk encryption and backup media. The card data should never be stored in the clear and by following the guidance in this cheat sheet you will be able to securely store your data in a manner which is compliant with PCI DSS requirement 3.4

'''3.5 Protect cryptographic keys used for encryption of cardholder data against both disclosure and misuse'''

As the requirement name above indicates we are required to securely store the encryption keys themselves. This will mean implementing strong access control, auditing and logging for your keys. The keys must be stored in a location which is both secure and "away" from the encrypted data, this means key data shouldn't be stored on web servers, database servers etc

Access to the keys must be restricted to the smallest amount of users possible. This group of users will ideally be users who are highly trusted and trained to perform Key Custodian duties. There will obviously be a requirement for system/service accounts to access the key data to perform encryption/decryption of data.

The keys themselves shouldn't be stored in the clear but encrypted with a KEK (Key Encrypting Key). The KEK must not be stored in the same location as the encryption keys it is encrypting.

'''3.6 Fully document and implement all key-management processes and procedures for cryptographic keys used for encryption of cardholder data'''

Requirement 3.6 mandates that key management processes within a PCI compliant company cover 8 specific key lifecycle steps:

'''3.6.1 Generation of strong cryptographic keys'''

As we have previously described in this cheat sheet we need to use algorithms which offer high levels of data security. We must also generate strong keys so that the security of the data isn't undermined by weak cryptographic keys. A strong key is generated by using a key length which is sufficient for your data security requirements and compliant with the PCI DSS. The key size alone isn't a measure of the strength of a key. The data used to generate the key must be sufficiently random ("sufficient" often being determined by your data security requirements) and the entropy of the key data itself must be high. 

'''3.6.2 Secure cryptographic key distribution'''

The method used to distribute keys must be secure to prevent the theft of keys in transit. The use of a protocol such as Diffie Hellman can help secure the distribution of keys, the use of secure transport such as SSLv3, TLS and SSHv2 can also secure the keys in transit. 

'''3.6.3 Secure cryptographic key storage'''

The secure storage of encryption keys including KEK's has been touched on in our description of requirement 3.5 (see above).

'''3.6.4 Periodic cryptographic key changes'''

The PCI DSS standard mandates that keys used for encryption must be rotated at least annually. The key rotation process must remove an old key from the encryption/decryption process and replace it with a new key. All new data entering the system must encrypted with the new key. While it is recommended that existing data be rekeyed with the new key, as per the Rekey data at least every one to three years rule above, it is not clear that the PCI DSS requires this.

'''3.6.5 Retirement or replacement of old or suspected compromised cryptographic keys'''

The key management processes must cater for archived, retired or compromised keys. The process of securely storing and replacing these keys will more than likely be covered by your processes for requirements 3.6.2, 3.6.3 and 3.6.4

'''3.6.6 Split knowledge and establishment of dual control of cryptographic keys'''

The requirement for split knowledge and/or dual control for key management prevents an individual user performing key management tasks such as key rotation or deletion. The system should require two individual users to perform an action (i.e. entering a value from their own OTP) which creates to separate values which are concatenated to create the final key data.

'''3.6.7 Prevention of unauthorized substitution of cryptographic keys'''

The system put in place to comply with requirement 3.6.6 can go a long way to preventing unauthorised substitution of key data. In addition to the dual control process you should implement strong access control, auditing and logging for key data so that unauthorised access attempts are prevented and logged.

'''3.6.8 Requirement for cryptographic key custodians to sign a form stating that they understand and accept their key-custodian responsibilities'''

To perform the strong key management functions we have seen in requirement 3.6 we must have highly trusted and trained key custodians who understand how to perform key management duties. The key custodians must also sign a form stating they understand the responsibilities that come with this role.

= Related Articles =

OWASP - [[Testing for SSL-TLS (OWASP-CM-001)|Testing for SSL-TLS]], and OWASP [[Guide to Cryptography]]

OWASP – [http://www.owasp.org/index.php/ASVS Application Security Verification Standard (ASVS) – Communication Security Verification Requirements (V10)]

{{Cheatsheet_Navigation}}

= Authors and Primary Editors =

Kevin Kenan - kevin[at]k2dd.com

David Rook - david.a.rook[at]gmail.com

Kevin Wall - kevin.w.wall[at]gmail.com

Jim Manico - jim[at]manico.net

[[Category:How_To]] [[Category:Cheatsheets]] [[Category:OWASP_Document]] [[Category:OWASP_Top_Ten_Project]]

Cryptographic Storage Cheat Sheet

2011-01-13T23:51:49Z

Kkenan: Revised rule regarding AE.

= Introduction =

This article provides a simple model to follow when implementing solutions for data at rest. 

== Architectural Decision ==

An architectural decision must be made to determine the appropriate method to protect data at rest. There are such wide variety of products, methods and mechanisms for cryptographic storage that this cheat sheet will only focus on low-level guidelines for developers and architects who are implementing cryptographic solutions. We will not address specific vendor solutions, nor will we address the design of cryptographic algorithms.

= Providing Cryptographic Functionality =

== Benefits ==

== Basic Requirements ==

== Secure Cryptographic Storage Design ==

=== Rule - Only store sensitive data that you need ===

Many eCommerce businesses use payment providers that store the credit card for recurring billing. This offloads the burden of keeping credit card numbers safe.

=== Rule - Only use strong cryptographic algorithms ===

Only use approved public algorithms such as AES, RSA public key cryptography, and SHA-256 or better for hashing. Do not use weak algorithms, such as MD5 / SHA1/ Favor safer. The definition of a "strong" cryptographic algorithms change over time.

http://csrc.nist.gov/groups/STM/cavp/index.html

This is a good default if one doesn't have AES and one of the authenticated encryption modes that provide confidentiality and authenticity (i.e., data origin authentication) such as CCM, EAX, CMAC, etc. For Java, if you are using SunJCE that will be the case. The cipher modes supported in JDK 1.5 and later are CBC, CFB, CFBx, CTR, CTS, ECB, OFB, OFBx, PCBC, None of these cipher modes are authentication encryption modes. (That's why I added it explicitly.) If you are using an alternate JCE provider such as Bouncy Castle, RSA JSafe, IAIK, etc then some of these authentication encryption modes probably should be preferred.

Use salts when appropriate. Note that integrity should use a MAC such as HMAC-SHA1 or even better, HMAC-SHA256.

==== Rule - Ensure that random numbers are cryptographically strong ====

Ensure that all random numbers, random file names, random GUIDs, and random strings are generated in a cryptographically strong fashion. Also ensure that random algorithms are seeded with sufficient entropy.

==== Rule - Only use widely accepted implementations of cryptographic algorithms ====

Do not implement an existing cryptographic algorithm on your own, no matter how easy it appears. Use widely accepted algorithms and widely accepted implementations only. Ensure that an implementation has, at least, had some cryptography experts involved in its creation. If possible, use an implementation that is FIPS 140-2 certified.

==== Rule - Prefer authenticated encryption modes ====

Use cryptographic cipher modes that offer both confidentiality and authenticity such as counter with CBC-MAC (CCM) and Galois/counter mode (GCM). These authenticated encryption (AE) modes resist padding oracle attacks which can be used in many cases to recover plaintext from encrypted text without knowledge of the encryption key.

If an authenticated encryption mode is not available, then the best option is to consult with a professional cryptographer. Ask the cryptographer to review and customize the system to counter padding oracle attacks. This customization will typically involve the use of a message authentication code (MAC) that must be carefully employed in order to be effective.

In the worst case, where neither an AE mode nor a professional cryptographer is available, then the cryptography is definitely vulnerable to a padding oracle attack. The best that can be done in this situation is to design the overall system so that the decryption function is only given ciphertext retrieved directly from a canonical source which must itself be protected by other integrity controls. While this technique will help reduce the risk of a padding oracle attack, it does not eliminate the risk, and it should be treated as a temporary workaround until an AE-based solution can be implemented.

When selecting a cryptographic mode for this worse case, cipher-block chaining (CBC) mode is a strong choice as it has been carefully studied, is well understood, and is readily available in many cryptographic APIs. In all cases avoid the electronic code book (ECB) mode. If using cipher modes that create streaming ciphers from block ciphers, such as the output feedback (OFB) or cipher feedback (CFB) modes, be careful not to repeat the IV for the same encryption key.

See [http://www.cryptopp.com/wiki/Authenticated_Encryption Authenticated Encryption] on the Crypto++ wiki for a more complete discussion of the technique. NIST's CRSC [http://csrc.nist.gov/groups/ST/toolkit/BCM/current_modes.html Current Modes] and [http://csrc.nist.gov/groups/ST/toolkit/BCM/modes_development.html Modes Dvelopment] offer an abbreviated list of cipher modes. Additional block cipher modes can be found at Wikipedia's [http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation Block cipher modes of operation].

=== Rule - Store the hashed and salted value of passwords ===

Store the salted hashed value of the password. Salt each hash. Use a different random salt for each password hash. Never store the clear text password or an encrypted version of the password.

Cryptographic framework for password hashing is described in [http://www.rsa.com/rsalabs/node.asp?id=2127 PKCS #5 v2.1: Password-Based Cryptography Standard]. Specific secure password hashing algorithms exist such as [http://www.usenix.org/events/usenix99/provos/provos_html/node1.html bcrypt], [http://www.tarsnap.com/scrypt/scrypt.pdf scrypt]. Implementations of secure password hashing exist for PHP ([http://www.openwall.com/phpass/ phpass]), ASP.NET ([http://msdn.microsoft.com/en-us/library/ms998372.aspx#pagpractices0001_sensitivedata ASP.NET 2.0 Security Practices]), Java ([http://www.owasp.org/index.php/Hashing_Java OWASP Hashing Java]).

=== Rule - Ensure that the cryptographic protection remains secure even if access controls fail ===

This rule supports the principle of defense in depth. Access
controls (usernames, passwords, privileges, etc.) are one layer of
protection. Storage encryption should add an additional layer of
protection that will continue protecting the data even if an
attacker subverts the database access control layer.

=== Rule - Ensure that any secret key is protected from unauthorized access ===

==== Rule - Define a key lifecycle ====

The key lifecycle details the various states that a key will move through during its life. The lifecycle will specify when a key should no longer be used for encryption, when a key should no longer be used for decryption (these are not necessarily coincident), whether data must be rekeyed when a new key is introduced, and when a key should be removed from use all together.

==== Rule - Store unencrypted keys away from the encrypted data ====

If the keys are stored with the data then any compromise of the data will easily compromise the keys as well. Unencrypted keys should never reside on the same machine or cluster as the data.

==== Rule - Use independent keys when multiple keys are required ====

Ensure that key material is independent. That is, do not choose a second key which is easily related to the first (or any preceeding) keys.

==== Rule - Protect keys in a key vault ====

Keys should remain in a protected key vault at all times. In particular, ensure that there is a gap between the threat vectors with direct access to the data and the threat vectors with direct access to the keys. This implies that keys should not be stored on the application or web server (assuming that application attackers are part of the relevant threat model).

==== Rule - Document concrete procedures for managing keys through the lifecycle ====

These procedures must be written down and the key custodians must be adequately trained.

==== Rule - Build support for changing keys periodically ====

Key rotation is a must as all good keys do come to an end either through expiration or revocation. So a developer will have to deal with rotating keys at some point -- better to have a system in place now rather than scrambling later. (From Bil Cory as a starting point).

==== Rule - Document concrete procedures to handle a key compromise ====

==== Rule - Rekey data at least every one to three years ====

Rekeying refers to the process of decrypting data and then re-encrypting it with a new key. Periodically rekeying data helps protect it from undetected compromises of older keys. The appropriate rekeying period depends on the security of the keys. Data protected by keys secured in dedicated hardware security modules might only need rekeying every three years. Data protected by keys that are split and stored on two application servers might need rekeying every year.

=== Rule - Follow applicable regulations on use of cryptography ===

==== Rule - Under PCI DSS requirement 3, you must protect cardholder data ====

The Payment Card Industry (PCI) Data Security Standard (DSS) was developed to encourage and enhance cardholder data security and facilitate the broad adoption of consistent data security measures globally. The standard was introduced in 2005 and replaced individual compliance standards from Visa, Mastercard, Amex, JCB and Diners. The current version of the standard was introduced in 2008 and an update to the standard is expected in 2010.

PCI DSS requirement 3 covers secure storage of credit card data. This requirement covers several aspects of secure storage including the data you must never store but we are covering Cryptographic Storage which is covered in requirements 3.4, 3.5 and 3.6 as you can see below:

'''3.4 Render PAN (Primary Account Number), at minimum, unreadable anywhere it is stored'''

Compliance with requirement 3.4 can be met by implementing any of the four types of secure storage described in the standard which includes encrypting and hashing data. These two approaches will often be the most popular choices from the list of options. The standard doesn't refer to any specific algorithms but it mandates the use of '''Strong Cryptography'''. The glossary document from the PCI council defines '''Strong Cryptography''' as:

''Cryptography based on industry-tested and accepted algorithms, along with strong key lengths and proper key-management practices. Cryptography is a method to protect data and includes both encryption (which is reversible) and hashing (which is not reversible, or “one way”). SHA-1 is an example of an industry-tested and accepted hashing algorithm. Examples of industry-tested and accepted standards and algorithms for encryption include AES (128 bits and higher), TDES (minimum double-length keys), RSA (1024 bits and higher), ECC (160 bits and higher), and ElGamal (1024 bits and higher).''

If you have implemented the second rule in this cheat sheet you will have implemented a strong cryptographic algorithm which is compliant with or stronger than the requirements of PCI DSS requirement 3.4 You need to ensure that you identify all locations that card data could be stored including logs and apply the appropriate level of protection. This could range from encrypting the data to replacing the card number in logs.

This requirement can also be met by implementing disk encryption rather than file or column level encryption. The requirements for '''Strong Cryptography''' are the same for disk encryption and backup media. The card data should never be stored in the clear and by following the guidance in this cheat sheet you will be able to securely store your data in a manner which is compliant with PCI DSS requirement 3.4

'''3.5 Protect cryptographic keys used for encryption of cardholder data against both disclosure and misuse'''

As the requirement name above indicates we are required to securely store the encryption keys themselves. This will mean implementing strong access control, auditing and logging for your keys. The keys must be stored in a location which is both secure and "away" from the encrypted data, this means key data shouldn't be stored on web servers, database servers etc

Access to the keys must be restricted to the smallest amount of users possible. This group of users will ideally be users who are highly trusted and trained to perform Key Custodian duties. There will obviously be a requirement for system/service accounts to access the key data to perform encryption/decryption of data.

The keys themselves shouldn't be stored in the clear but encrypted with a KEK (Key Encrypting Key). The KEK must not be stored in the same location as the encryption keys it is encrypting.

'''3.6 Fully document and implement all key-management processes and procedures for cryptographic keys used for encryption of cardholder data'''

Requirement 3.6 mandates that key management processes within a PCI compliant company cover 8 specific key lifecycle steps:

'''3.6.1 Generation of strong cryptographic keys'''

As we have previously described in this cheat sheet we need to use algorithms which offer high levels of data security. We must also generate strong keys so that the security of the data isn't undermined by weak cryptographic keys. A strong key is generated by using a key length which is sufficient for your data security requirements and compliant with the PCI DSS. The key size alone isn't a measure of the strength of a key. The data used to generate the key must be sufficiently random ("sufficient" often being determined by your data security requirements) and the entropy of the key data itself must be high. 

'''3.6.2 Secure cryptographic key distribution'''

The method used to distribute keys must be secure to prevent the theft of keys in transit. The use of a protocol such as Diffie Hellman can help secure the distribution of keys, the use of secure transport such as SSLv3, TLS and SSHv2 can also secure the keys in transit. 

'''3.6.3 Secure cryptographic key storage'''

The secure storage of encryption keys including KEK's has been touched on in our description of requirement 3.5 (see above).

'''3.6.4 Periodic cryptographic key changes'''

The PCI DSS standard mandates that keys used for encryption must be rotated at least annually. The key rotation process must remove an old key from the encryption/decryption process and replace it with a new key. All new data entering the system must encrypted with the new key. While it is recommended that existing data be rekeyed with the new key, as per the Rekey data at least every one to three years rule above, it is not clear that the PCI DSS requires this.

'''3.6.5 Retirement or replacement of old or suspected compromised cryptographic keys'''

The key management processes must cater for archived, retired or compromised keys. The process of securely storing and replacing these keys will more than likely be covered by your processes for requirements 3.6.2, 3.6.3 and 3.6.4

'''3.6.6 Split knowledge and establishment of dual control of cryptographic keys'''

The requirement for split knowledge and/or dual control for key management prevents an individual user performing key management tasks such as key rotation or deletion. The system should require two individual users to perform an action (i.e. entering a value from their own OTP) which creates to separate values which are concatenated to create the final key data.

'''3.6.7 Prevention of unauthorized substitution of cryptographic keys'''

The system put in place to comply with requirement 3.6.6 can go a long way to preventing unauthorised substitution of key data. In addition to the dual control process you should implement strong access control, auditing and logging for key data so that unauthorised access attempts are prevented and logged.

'''3.6.8 Requirement for cryptographic key custodians to sign a form stating that they understand and accept their key-custodian responsibilities'''

To perform the strong key management functions we have seen in requirement 3.6 we must have highly trusted and trained key custodians who understand how to perform key management duties. The key custodians must also sign a form stating they understand the responsibilities that come with this role.

= Related Articles =

OWASP - [[Testing for SSL-TLS (OWASP-CM-001)|Testing for SSL-TLS]], and OWASP [[Guide to Cryptography]]

OWASP – [http://www.owasp.org/index.php/ASVS Application Security Verification Standard (ASVS) – Communication Security Verification Requirements (V10)]

{{Cheatsheet_Navigation}}

= Authors and Primary Editors =

Kevin Kenan - kevin[at]k2dd.com

David Rook - david.a.rook[at]gmail.com

Kevin Wall - kevin.w.wall[at]gmail.com

Jim Manico - jim[at]manico.net

[[Category:How_To]] [[Category:Cheatsheets]] [[Category:OWASP_Document]] [[Category:OWASP_Top_Ten_Project]]

OWASP Podcast

2010-04-23T05:26:18Z

Kkenan:

==== About ====

'''OWASP Podcast Series Hosted by Jim Manico'''

* The OWASP foundation presents the OWASP PODCAST SERIES hosted by [http://manico.net Jim Manico].
* Listen as Jim interviews OWASP volunteers, industry experts and leaders within the field of web application security.
* Questions? Comments? Please email [mailto:podcast@owasp.org podcast@owasp.org]
* Care to join our email list? Sign up here [https://lists.owasp.org/mailman/listinfo/owasp-podcast https://lists.owasp.org/mailman/listinfo/owasp-podcast]
* Want to see the process and equipment behind the show? [https://www.owasp.org/index.php/Talk:OWASP_Podcast click here]

<table border="0"><tr><td>
[http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewPodcast?id=300769012 http://www.owasp.org/download/jmanico/OWASP_Podcast_200x200.jpg]
</td><td align="center" width="150">
Subscribe [http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewPodcast?id=300769012 http://www.owasp.org/download/jmanico/itunes.jpg] [http://www.owasp.org/download/jmanico/podcast.xml https://www.owasp.org/images/d/d3/Feed-icon-32x32.png]
</td>
</tr>
</table>

<paypal>OWASP Podcast</paypal>

==== Latest Shows====

<table class="wikitable" border="1">

<tr>
<th>#</th>
<th>Date</th>
<th>Actions</th>
<th>Description</th>
</tr>

<tr>
<td NOWRAP VALIGN="TOP">71</td>
<td NOWRAP VALIGN="TOP">April 19, 2010</td>
<td NOWRAP VALIGN="TOP">[http://www.owasp.org/download/jmanico/owasp_podcast_71.mp3 Listen Now]</td>
<td VALIGN="TOP">Top Ten with Robert Hansen (Redirects)</td>
</tr>

<tr>
<td NOWRAP VALIGN="TOP">70</td>
<td NOWRAP VALIGN="TOP">April 19, 2010</td>
<td NOWRAP VALIGN="TOP">[http://www.owasp.org/download/jmanico/owasp_podcast_70.mp3 Listen Now]</td>
<td VALIGN="TOP">Top Ten with Michael Coates (TLS)</td>
</tr>

<tr>
<td NOWRAP VALIGN="TOP">69</td>
<td NOWRAP VALIGN="TOP">April 19, 2010</td>
<td NOWRAP VALIGN="TOP">[http://www.owasp.org/download/jmanico/owasp_podcast_69.mp3 Listen Now]</td>
<td VALIGN="TOP">Top Ten with Eric Sheridan (CSRF)</td>
</tr>

<tr>
<td NOWRAP VALIGN="TOP">68</td>
<td NOWRAP VALIGN="TOP">April 19, 2010</td>
<td NOWRAP VALIGN="TOP">[http://www.owasp.org/download/jmanico/owasp_podcast_68.mp3 Listen Now]</td>
<td VALIGN="TOP">Top Ten with Kevin Kenan (Cryptographic Storage)</td>
</tr>

<tr>
<td NOWRAP VALIGN="TOP">67</td>
<td NOWRAP VALIGN="TOP">April 19, 2010</td>
<td NOWRAP VALIGN="TOP">[http://www.owasp.org/download/jmanico/owasp_podcast_67.mp3 Listen Now]</td>
<td VALIGN="TOP">Top Ten with Jeff Williams (XSS)</td>
</tr>

<tr>
<td NOWRAP VALIGN="TOP">66</td>
<td NOWRAP VALIGN="TOP">April 14, 2010</td>
<td NOWRAP VALIGN="TOP">[http://www.owasp.org/download/jmanico/owasp_podcast_66.mp3 Listen Now]</td>
<td VALIGN="TOP">Interview with Brad Arkin (Adobe)</td>
</tr>

<tr>
<td NOWRAP VALIGN="TOP">65</td>
<td NOWRAP VALIGN="TOP">April 13, 2010</td>
<td NOWRAP VALIGN="TOP">[http://www.owasp.org/download/jmanico/owasp_podcast_65.mp3 Listen Now]</td>
<td VALIGN="TOP">AppSec Roundtable with Boaz Gelbord, Dan Cornell, Jeff Williams, Johannes Ullrich and Jim Manico (File Upload)</td>
</tr>

<tr>
<td NOWRAP VALIGN="TOP">64</td>
<td NOWRAP VALIGN="TOP">March 30, 2010</td>
<td NOWRAP VALIGN="TOP">[http://www.owasp.org/download/jmanico/owasp_podcast_64.mp3 Listen Now]</td>
<td VALIGN="TOP">Interview with Andy Ellis (Availability)</td>
</tr>

<tr>
<td NOWRAP VALIGN="TOP">63</td>
<td NOWRAP VALIGN="TOP">March 17, 2010</td>
<td NOWRAP VALIGN="TOP">[http://www.owasp.org/download/jmanico/owasp_podcast_63.mp3 Listen Now]</td>
<td VALIGN="TOP">Interview with Ed Bellis (eCommerce)</td>
</tr>

<tr>
<td NOWRAP VALIGN="TOP">62</td>
<td NOWRAP VALIGN="TOP">March 12, 2010</td>
<td NOWRAP VALIGN="TOP">[http://www.owasp.org/download/jmanico/owasp_podcast_62.mp3 Listen Now] | [[Podcast_62|Show Notes]]</td>
<td VALIGN="TOP">Interview with Amichai Shulman (WAF)</td>
</tr>

<tr>
<td NOWRAP VALIGN="TOP">61</td>
<td NOWRAP VALIGN="TOP">March 10, 2010</td>
<td NOWRAP VALIGN="TOP">[http://www.owasp.org/download/jmanico/owasp_podcast_61.mp3 Listen Now] | [[Podcast_61|Show Notes]]</td>
<td VALIGN="TOP">Interview with Richard Bejtlich (Network Monitoring)</td>
</tr>

<tr>
<td NOWRAP VALIGN="TOP">60</td>
<td NOWRAP VALIGN="TOP">February 5, 2010</td>
<td NOWRAP VALIGN="TOP">[http://www.owasp.org/download/jmanico/owasp_podcast_60.mp3 Listen Now]</td>
<td VALIGN="TOP">Interview with Jeremiah Grossman and Robert Hansen (Google pays for vulns)</td>
</tr>

<tr>
<td NOWRAP VALIGN="TOP">59</td>
<td NOWRAP VALIGN="TOP">February 3, 2010</td>
<td NOWRAP VALIGN="TOP">[http://www.owasp.org/download/jmanico/owasp_podcast_59.mp3 Listen Now]</td>
<td VALIGN="TOP">AppSec Roundtable with Boaz Gelbord, Ben Tomhave, Dan Cornell, Jeff Williams, Andrew van der Stock and Jim Manico (Aurora+)</td>
</tr>

<tr>
<td NOWRAP VALIGN="TOP">58</td>
<td NOWRAP VALIGN="TOP">February 2, 2010</td>
<td NOWRAP VALIGN="TOP">[http://www.owasp.org/download/jmanico/owasp_podcast_58.mp3 Listen Now]</td>
<td VALIGN="TOP">Interview with Ron Gula (Web Server Scanning, IDS/IPS)</td>
</tr>

<tr>
<td NOWRAP VALIGN="TOP">57</td>
<td NOWRAP VALIGN="TOP">December 21, 2009</td>
<td NOWRAP VALIGN="TOP">[http://www.owasp.org/download/jmanico/owasp_podcast_57.mp3 Listen Now] | [[Podcast_57|Show Notes]]</td>
<td VALIGN="TOP">Interview with David Linthicum (Cloud Computing)</td>
</tr>

<tr>
<td NOWRAP VALIGN="TOP">56</td>
<td NOWRAP VALIGN="TOP">December 7, 2009</td>
<td NOWRAP VALIGN="TOP">[http://www.owasp.org/download/jmanico/owasp_podcast_56.mp3 Listen Now] | [[Podcast_56|Show Notes]]</td>
<td VALIGN="TOP">Interview with Adar Weidman (Regular Expression DOS)</td>
</tr>

<tr>
<td NOWRAP VALIGN="TOP">55</td>
<td NOWRAP VALIGN="TOP">November 26, 2009</td>
<td NOWRAP VALIGN="TOP">[http://www.owasp.org/download/jmanico/owasp_podcast_55.mp3 Listen Now] | [[Podcast_55|Show Notes]]</td>
<td VALIGN="TOP">AppSec Roundtable with Boaz Gelbord, Jason Lam, Jim Manico and Jeff Williams (AppSec Justification)</td>
</tr>

<tr>
<td NOWRAP VALIGN="TOP">54</td>
<td NOWRAP VALIGN="TOP">November 24, 2009</td>
<td NOWRAP VALIGN="TOP">[http://www.owasp.org/download/jmanico/owasp_podcast_54.mp3 Listen Now]</td>
<td VALIGN="TOP">Interview with George Hesse (German Chapter Leader)</td>
</tr>

<tr>
<td NOWRAP VALIGN="TOP">53</td>
<td NOWRAP VALIGN="TOP">November 24, 2009</td>
<td NOWRAP VALIGN="TOP">[http://www.owasp.org/download/jmanico/owasp_podcast_53.mp3 Listen Now]</td>
<td VALIGN="TOP">Interview with Amichai Shulman (WAF)</td>
</tr>

<tr>
<td NOWRAP VALIGN="TOP">52</td>
<td NOWRAP VALIGN="TOP">November 5, 2009</td>
<td NOWRAP VALIGN="TOP">[http://www.owasp.org/download/jmanico/owasp_podcast_52.mp3 Listen Now]</td>
<td VALIGN="TOP">Sandro Gauci ([http://code.google.com/p/waffit/ wafw00f])</td>
</tr>

<tr>
<td NOWRAP VALIGN="TOP">51</td>
<td NOWRAP VALIGN="TOP">October 30, 2009</td>
<td NOWRAP VALIGN="TOP">[http://www.owasp.org/download/jmanico/owasp_podcast_51.mp3 Listen Now]</td>
<td VALIGN="TOP">Interview with Michael Coates (Real Time Defenses, [http://www.owasp.org/index.php/Category:OWASP_AppSensor_Project OWASP AppSensor])</td>
</tr>

<tr>
<td NOWRAP VALIGN="TOP">50</td>
<td NOWRAP VALIGN="TOP">October 30, 2009</td>
<td NOWRAP VALIGN="TOP">[http://www.owasp.org/download/jmanico/owasp_podcast_50.mp3 Listen Now]</td>
<td VALIGN="TOP">Interview with Eldad Chai (Business Logic Attacks)</td>
</tr>

<tr>
<td NOWRAP VALIGN="TOP">49</td>
<td NOWRAP VALIGN="TOP">October 30, 2009</td>
<td NOWRAP VALIGN="TOP">[http://www.owasp.org/download/jmanico/owasp_podcast_49.mp3 Listen Now]</td>
<td VALIGN="TOP">Interview with Andre Riancho (OWASP w3af)</td>
</tr>

<tr>
<td NOWRAP VALIGN="TOP">48</td>
<td NOWRAP VALIGN="TOP">October 30, 2009</td>
<td NOWRAP VALIGN="TOP">[http://www.owasp.org/download/jmanico/owasp_podcast_48.mp3 Listen Now]</td>
<td VALIGN="TOP">Interview with Giorgio Fedon (Browser Security in Banking)</td>
</tr>

<tr>
<td NOWRAP VALIGN="TOP">47</td>
<td NOWRAP VALIGN="TOP">October 23, 2009</td>
<td NOWRAP VALIGN="TOP">[http://www.owasp.org/download/jmanico/owasp_podcast_47.mp3 Listen Now]</td>
<td VALIGN="TOP">Interview with Erlend Oftedal (Agile)</td>
</tr>

<tr>
<td NOWRAP VALIGN="TOP">46</td>
<td NOWRAP VALIGN="TOP">October 23, 2009</td>
<td NOWRAP VALIGN="TOP">[http://www.owasp.org/download/jmanico/owasp_podcast_46.mp3 Listen Now]</td>
<td VALIGN="TOP">Interview with Luca Carettoni and Stefano Di Paola (HTTP Parameter Pollution)</td>
</tr>

<tr>
<td NOWRAP VALIGN="TOP">45</td>
<td NOWRAP VALIGN="TOP">October 16, 2009</td>
<td NOWRAP VALIGN="TOP">[http://www.owasp.org/download/jmanico/owasp_podcast_45.mp3 Listen Now] | [[Podcast_45|Show Notes]]</td>
<td VALIGN="TOP">Interview with Buanzo ([http://www.buanzo.com.ar/pro/eng.html Enigform ])</td>
</tr>

<tr>
<td NOWRAP VALIGN="TOP">44</td>
<td NOWRAP VALIGN="TOP">October 8, 2009</td>
<td NOWRAP VALIGN="TOP">[http://www.owasp.org/download/jmanico/owasp_podcast_44.mp3 Listen Now] | [[Podcast_44|Show Notes]]</td>
<td VALIGN="TOP">Interview with Andy Steingruebl (PayPal Secure Development Manager)</td>
</tr>

<tr>
<td NOWRAP VALIGN="TOP">43</td>
<td NOWRAP VALIGN="TOP">October 2, 2009</td>
<td NOWRAP VALIGN="TOP">[http://www.owasp.org/download/jmanico/owasp_podcast_43.mp3 Listen Now] | [[Podcast_43|Show Notes]]</td>
<td VALIGN="TOP">Interview with Mike Smith (http://www.guerilla-ciso.com/)</td>
</tr>

<tr>
<td NOWRAP VALIGN="TOP">42</td>
<td NOWRAP VALIGN="TOP">October 1, 2009</td>
<td NOWRAP VALIGN="TOP">[http://www.owasp.org/download/jmanico/owasp_podcast_42.mp3 Listen Now] | [[Podcast_42|Show Notes]]</td>
<td VALIGN="TOP">Roundtable with Matt Fisher, Jim Manico, Dan Philpott, Jack Whitsitt and Doug Wilson (FISMA, US Federal Cybersecurity)</td>
</tr>

<tr>
<td NOWRAP VALIGN="TOP">41</td>
<td NOWRAP VALIGN="TOP">September 26, 2009</td>
<td NOWRAP VALIGN="TOP">[http://www.owasp.org/download/jmanico/owasp_podcast_41.mp3 Listen Now] | [[Podcast_41|Show Notes]]</td>
<td VALIGN="TOP">Interview with David Rice (Author of Geekonomics)</td>
</tr>

<tr>
<td NOWRAP VALIGN="TOP">40</td>
<td NOWRAP VALIGN="TOP">September 23, 2009</td>
<td NOWRAP VALIGN="TOP">[http://www.owasp.org/download/jmanico/owasp_podcast_40.mp3 Listen Now] | [[Podcast_40|Show Notes]]</td>
<td VALIGN="TOP">Interview with Rohit Sethi (OWASP J2EE Pattern Project)</td>
</tr>

<tr>
<td NOWRAP VALIGN="TOP">39</td>
<td NOWRAP VALIGN="TOP">August 25, 2009</td>
<td NOWRAP VALIGN="TOP">[http://www.owasp.org/download/jmanico/owasp_podcast_39.mp3 Listen Now] | [[Podcast_39|Show Notes]]</td>
<td VALIGN="TOP">Interview with Gunnar Peterson (Webservices)</td>
</tr>

<tr>
<td NOWRAP VALIGN="TOP">38</td>
<td NOWRAP VALIGN="TOP">August 25, 2009</td>
<td NOWRAP VALIGN="TOP">[http://www.owasp.org/download/jmanico/owasp_podcast_38.mp3 Listen Now] | [[Podcast_38|Show Notes]]</td>
<td VALIGN="TOP">Interview with the OWASP Global Education Committee</td>
</tr>

<tr>
<td NOWRAP VALIGN="TOP">37</td>
<td NOWRAP VALIGN="TOP">August 22, 2009</td>
<td NOWRAP VALIGN="TOP">[http://www.owasp.org/download/jmanico/owasp_podcast_37.mp3 Listen Now] | [[Podcast_37|Show Notes]]</td>
<td VALIGN="TOP">Interview with Jason Lam and Johannes Ullrich (SANS Institute)</td>
</tr>

<tr>
<td NOWRAP VALIGN="TOP">36</td>
<td NOWRAP VALIGN="TOP">August 15, 2009</td>
<td NOWRAP VALIGN="TOP">[http://www.owasp.org/download/jmanico/owasp_podcast_36.mp3 Listen Now] | [[Podcast_36|Show Notes]]</td>
<td VALIGN="TOP">May 2009 News Commentary Recorded July 23 with Boaz Gelbord, Andre Gironda, Jason Lam, Jim Manico, Alex Smolen, Ben Tomhave, Andrew van der Stock and Jeff Williams (part 2)</td>
</tr>

<tr>
<td NOWRAP VALIGN="TOP">35</td>
<td NOWRAP VALIGN="TOP">August 4, 2009</td>
<td NOWRAP VALIGN="TOP">[http://www.owasp.org/download/jmanico/owasp_podcast_35.mp3 Listen Now] | [[Podcast_35|Show Notes]]</td>
<td VALIGN="TOP">Interview with Anton Chuvakin, Ph.D (PCI)</td>
</tr>

<tr>
<td NOWRAP VALIGN="TOP">34</td>
<td NOWRAP VALIGN="TOP">July 30, 2009</td>
<td NOWRAP VALIGN="TOP">[http://www.owasp.org/download/jmanico/owasp_podcast_34.mp3 Listen Now] | [[Podcast_34|Show Notes]]</td>
<td VALIGN="TOP">Interview with Amichai Shulman (WAF)</td>
</tr>

<tr>
<td NOWRAP VALIGN="TOP">33</td>
<td NOWRAP VALIGN="TOP">July 25, 2009</td>
<td NOWRAP VALIGN="TOP">[http://www.owasp.org/download/jmanico/owasp_podcast_33.mp3 Listen Now] | [[Podcast_33|Show Notes]]</td>
<td VALIGN="TOP">Interview with Paolo Perego (OWASP Orizon)</td>
</tr>

<tr>
<td NOWRAP VALIGN="TOP">32</td>
<td NOWRAP VALIGN="TOP">July 21, 2009</td>
<td NOWRAP VALIGN="TOP">[http://www.owasp.org/download/jmanico/owasp_podcast_32.mp3 Listen Now] | [[Podcast_32|Show Notes]]</td>
<td VALIGN="TOP">May 2009 News Commentary Recorded June 11 with Arshan Dabirsiaghi, Boaz Gelbord, Jim Manico, Andrew van der Stock and Jeff Williams (part 1)</td>
</tr>

<tr>
<td NOWRAP VALIGN="TOP">31</td>
<td NOWRAP VALIGN="TOP">July 4, 2009</td>
<td NOWRAP VALIGN="TOP">[http://www.owasp.org/download/jmanico/owasp_podcast_31.mp3 Listen Now] | [[Podcast_31|Show Notes]]</td>
<td VALIGN="TOP">Interview with Mark Curphey (OWASP Founder)</td>
</tr>

<tr>
<td NOWRAP VALIGN="TOP">30</td>
<td NOWRAP VALIGN="TOP">July 2, 2009</td>
<td NOWRAP VALIGN="TOP">[http://www.owasp.org/download/jmanico/owasp_podcast_30.mp3 Listen Now] | [[Podcast_30|Show Notes]]</td>
<td VALIGN="TOP">Interview with Billy Hoffman and Matt Wood (HP Application Security Research)</td>
</tr>

<tr>
<td NOWRAP VALIGN="TOP">29</td>
<td NOWRAP VALIGN="TOP">June 30, 2009</td>
<td NOWRAP VALIGN="TOP">[http://www.owasp.org/download/jmanico/owasp_podcast_29.mp3 Listen Now] | [[Podcast_29|Show Notes]]</td>
<td VALIGN="TOP">Interview with Justin Clarke (SQL Injection)</td>
</tr>

<tr>
<td NOWRAP VALIGN="TOP">28</td>
<td NOWRAP VALIGN="TOP">June 26, 2009</td>
<td NOWRAP VALIGN="TOP">[http://www.owasp.org/download/jmanico/owasp_podcast_28.mp3 Listen Now] | [[Podcast_28|Show Notes]]</td>
<td VALIGN="TOP">Interview with Ross J. Anderson</td>
</tr>

<tr>
<td NOWRAP VALIGN="TOP">27</td>
<td NOWRAP VALIGN="TOP">June 26, 2009</td>
<td NOWRAP VALIGN="TOP">[http://www.owasp.org/download/jmanico/owasp_podcast_27.mp3 Listen Now] | [[Podcast_27|Show Notes]]</td>
<td VALIGN="TOP">Interview with Rafal Los (The Skeletor of AppSec)</td>
</tr>

<tr>
<td NOWRAP VALIGN="TOP">26</td>
<td NOWRAP VALIGN="TOP">June 17, 2009</td>
<td NOWRAP VALIGN="TOP">[http://www.owasp.org/download/jmanico/owasp_podcast_26.mp3 Listen Now] | [[Podcast_26|Show Notes]]</td>
<td VALIGN="TOP">April 2009 News Commentary Recorded May 28 with Tom Brennan, Andre Gironda, Jim Manico, Alex Smolen and Jeff Williams (part 2)</td>
</tr>

<tr>
<td NOWRAP VALIGN="TOP">25</td>
<td NOWRAP VALIGN="TOP">June 15, 2009</td>
<td NOWRAP VALIGN="TOP">[http://www.owasp.org/download/jmanico/owasp_podcast_25.mp3 Listen Now] | [[Podcast_25|Show Notes]]</td>
<td VALIGN="TOP">Interview with James McGovern</td>
</tr>

<tr>
<td NOWRAP VALIGN="TOP">24</td>
<td NOWRAP VALIGN="TOP">June 12, 2009</td>
<td NOWRAP VALIGN="TOP">[http://www.owasp.org/download/jmanico/owasp_podcast_24.mp3 Listen Now] | [[Podcast_24|Show Notes]]</td>
<td VALIGN="TOP">April 2009 News Commentary Recorded May 14 with Andre Gironda, Jim Manico, Alex Smolen and Jeff Williams (part 1)</td>
</tr>

<tr>
<td NOWRAP VALIGN="TOP">23</td>
<td NOWRAP VALIGN="TOP">June 1, 2009</td>
<td NOWRAP VALIGN="TOP">[http://www.owasp.org/download/jmanico/owasp_podcast_23.mp3 Listen Now] | [[Podcast_23|Show Notes]]</td>
<td VALIGN="TOP">Interview with Dr. Boaz Gelbord</td>
</tr>

<tr>
<td NOWRAP VALIGN="TOP">22</td>
<td NOWRAP VALIGN="TOP">May 22, 2009</td>
<td NOWRAP VALIGN="TOP">[http://www.owasp.org/download/jmanico/owasp_podcast_22.mp3 Listen Now] | [[Podcast_22|Show Notes]]</td>
<td VALIGN="TOP">Interview with Dan Cornell (Membership Committee)</td>
</tr>

<tr>
<td NOWRAP VALIGN="TOP">21</td>
<td NOWRAP VALIGN="TOP">May 20, 2009</td>
<td NOWRAP VALIGN="TOP">[http://www.owasp.org/download/jmanico/owasp_podcast_21.ogg Listen Now] | [[Podcast_21|Show Notes]]</td>
<td VALIGN="TOP">Interview with Richard Stallman</td>
</tr>

<tr>
<td NOWRAP VALIGN="TOP">20</td>
<td NOWRAP VALIGN="TOP">May 13, 2009</td>
<td NOWRAP VALIGN="TOP">[http://www.owasp.org/download/jmanico/owasp_podcast_20.mp3 Listen Now] | [[Podcast_20|Show Notes]]</td>
<td VALIGN="TOP">Interview with Mike Bailey</td>
</tr>

<tr>
<td NOWRAP VALIGN="TOP">19</td>
<td NOWRAP VALIGN="TOP">May 11, 2009</td>
<td NOWRAP VALIGN="TOP">[http://www.owasp.org/download/jmanico/owasp_podcast_19.mp3 Listen Now] | [[Podcast_19|Show Notes]] </td>
<td VALIGN="TOP">March 2009 News Commentary by Arshan Dabirsiaghi, Andre Gironda, Jim Manico and Jeff Williams (part 2)</td>
</tr>

<tr>
<td NOWRAP VALIGN="TOP">18</td>
<td NOWRAP VALIGN="TOP">April 30, 2009</td>
<td NOWRAP VALIGN="TOP">[http://www.owasp.org/download/jmanico/owasp_podcast_18.mp3 Listen Now] | [[Podcast_18|Show Notes]] </td>
<td VALIGN="TOP">Interview with Jeremiah Grossman</td>
</tr>

<tr>
<td NOWRAP VALIGN="TOP">17</td>
<td NOWRAP VALIGN="TOP">April 21, 2009</td>
<td NOWRAP VALIGN="TOP">[http://www.owasp.org/download/jmanico/owasp_podcast_17.mp3 Listen Now] | [[Podcast_17|Show Notes]] </td>
<td VALIGN="TOP">Interview with Robert Hansen</td>
</tr>

<tr>
<td NOWRAP VALIGN="TOP">16</td>
<td NOWRAP VALIGN="TOP">April 9, 2009</td>
<td NOWRAP VALIGN="TOP">[http://www.owasp.org/download/jmanico/owasp_podcast_16.mp3 Listen Now] | [[Podcast_16|Show Notes]]</td>
<td VALIGN="TOP">Dave Aitel (Demonstrates Cool)</td>
</tr>

<tr>
<td NOWRAP VALIGN="TOP">15</td>
<td NOWRAP VALIGN="TOP">April 4, 2009</td>
<td NOWRAP VALIGN="TOP">[http://www.owasp.org/download/jmanico/owasp_podcast_15.mp3 Listen Now] | [[Podcast_15|Show Notes]]</td>
<td VALIGN="TOP">Brian Chess (BSIMM)</td>
</tr>

<tr>
<td NOWRAP VALIGN="TOP">14</td>
<td NOWRAP VALIGN="TOP">March 25, 2009</td>
<td NOWRAP VALIGN="TOP">[http://www.owasp.org/download/jmanico/owasp_podcast_14.mp3 Listen Now] | [[Podcast_14|Show Notes]]</td>
<td VALIGN="TOP">Pravir Chandra (OWASP SAMM)</td>
</tr>

<tr>
<td NOWRAP VALIGN="TOP">13</td>
<td NOWRAP VALIGN="TOP">March 23, 2009</td>
<td NOWRAP VALIGN="TOP">[http://www.owasp.org/download/jmanico/owasp_podcast_13.mp3 Listen Now] | [[Podcast_13|Show Notes]]</td>
<td VALIGN="TOP">March 2009 News Commentary by Arshan Dabirsiaghi, Andre Gironda, Jim Manico and Jeff Williams (part 1)</td>
</tr>

<tr>
<td NOWRAP VALIGN="TOP">12</td>
<td NOWRAP VALIGN="TOP">March 11, 2009</td>
<td NOWRAP VALIGN="TOP">[http://www.owasp.org/download/jmanico/owasp_podcast_12.mp3 Listen Now] | [[Podcast_12|Show Notes]]</td>
<td VALIGN="TOP">Interview with Ryan Barnett (OWASP ModSecurity Core Ruleset)</td>
</tr>

<tr>
<td NOWRAP VALIGN="TOP">11</td>
<td NOWRAP VALIGN="TOP">March 4, 2009</td>
<td NOWRAP VALIGN="TOP">[http://www.owasp.org/download/jmanico/owasp_podcast_11.mp3 Listen Now] | [[Podcast_11|Show Notes]]</td>
<td VALIGN="TOP">Interview with MITRE (Steve Christey and Bob Martin)</td>
</tr>

<tr>
<td NOWRAP VALIGN="TOP">10</td>
<td NOWRAP VALIGN="TOP">February 26, 2009</td>
<td NOWRAP VALIGN="TOP">[http://www.owasp.org/download/jmanico/owasp_podcast_10.mp3 Listen Now] | [[Podcast_10|Show Notes]]</td>
<td VALIGN="TOP">Interview with Ken van Wyk</td>
</tr>

<tr>
<td NOWRAP VALIGN="TOP">9</td>
<td NOWRAP VALIGN="TOP">February 20, 2009</td>
<td NOWRAP VALIGN="TOP">[http://www.owasp.org/download/jmanico/owasp_podcast_9.mp3 Listen Now] | [[Podcast_9|Show Notes]]</td>
<td VALIGN="TOP">February 2009 News Commentary by Arshan Dabirsiaghi, Andre Gironda, Jim Manico and Jeff Williams (part 2)</td>
</tr>

<tr>
<td NOWRAP VALIGN="TOP">8</td>
<td NOWRAP VALIGN="TOP">February 20, 2009</td>
<td NOWRAP VALIGN="TOP">[http://www.owasp.org/download/jmanico/owasp_podcast_8.mp3 Listen Now] | [[Podcast_8|Show Notes]]</td>
<td VALIGN="TOP">February 2009 News Commentary by Arshan Dabirsiaghi, Andre Gironda, Jim Manico and Jeff Williams (part 1)</td>
</tr>

<tr>
<td NOWRAP VALIGN="TOP">7</td>
<td NOWRAP VALIGN="TOP">January 30, 2009</td>
<td NOWRAP VALIGN="TOP">[http://www.owasp.org/download/jmanico/owasp_podcast_7.mp3 Listen Now] | [[Podcast_7|Show Notes]]</td>
<td VALIGN="TOP">Interview with Jeff Williams</td>
</tr>

<tr>
<td NOWRAP VALIGN="TOP">6</td>
<td NOWRAP VALIGN="TOP">January 24, 2009</td>
<td NOWRAP VALIGN="TOP">[http://www.owasp.org/download/jmanico/owasp_podcast_6.mp3 Listen Now] | [[Podcast_6|Show Notes]]</td>
<td VALIGN="TOP">Roundtable with Andre Gironda, Brian Holyfield, Jim Manico, Marcin Wielgoszewski</td>
</tr>

<tr>
<td NOWRAP VALIGN="TOP">5</td>
<td NOWRAP VALIGN="TOP">January 15, 2009</td>
<td NOWRAP VALIGN="TOP">[http://www.owasp.org/download/jmanico/owasp_podcast_5.mp3 Listen Now] | [[Podcast_5|Show Notes]]</td>
<td VALIGN="TOP">Interview with Gary McGraw</td>
</tr>

<tr>
<td NOWRAP VALIGN="TOP">4</td>
<td NOWRAP VALIGN="TOP">January 13, 2009</td>
<td NOWRAP VALIGN="TOP">[http://www.owasp.org/download/jmanico/owasp_podcast_4.mp3 Listen Now] | [[Podcast_4|Show Notes]]</td>
<td VALIGN="TOP">Interview with Andrew van der Stock (OWASP Developers Guide)</td>
</tr>

<tr>
<td NOWRAP VALIGN="TOP">3</td>
<td NOWRAP VALIGN="TOP">December 30, 2009</td>
<td NOWRAP VALIGN="TOP">[http://www.owasp.org/download/jmanico/owasp_podcast_3.mp3 Listen Now] | [[Podcast_3|Show Notes]]</td>
<td VALIGN="TOP">Interview with Matt Tesauro (OWASP Live CD)</td>
</tr>

<tr>
<td NOWRAP VALIGN="TOP">2</td>
<td NOWRAP VALIGN="TOP">December 20, 2008</td>
<td NOWRAP VALIGN="TOP">[http://www.owasp.org/download/jmanico/owasp_podcast_2.mp3 Listen Now] | [[Podcast_2|Show Notes]]</td>
<td VALIGN="TOP">Interview with Stephen Craig Evans (OWASP WebGoat/ModSecurity Project)</td>
</tr>

<tr>
<td NOWRAP VALIGN="TOP">1</td>
<td NOWRAP VALIGN="TOP">November 21, 2008</td>
<td NOWRAP VALIGN="TOP">[http://www.owasp.org/download/jmanico/owasp_podcast_1.mp3 Listen Now] | [[Podcast_1|Show Notes]]</td>
<td VALIGN="TOP">News Commentary by Arshan Dabirsiaghi, Jeremiah Grossman, Jim Manico and Jeff Williams</td>
</tr>

</table>

==== Contributors and Sponsors ====

'''Host and Executive Producer'''
* [[User:Jmanico|Jim Manico]]

'''Host and Producer'''
* Matt Tesauro

'''Mastering, Effects, Audio Tech, Producer'''
* Kevin Coons from ManaTribe

'''News Commentary Copy Editors'''
* [[User:dre|Andre Gironda]]
* Mike Boberski

'''Audio Editors'''
* [[User:Jmanico|Jim Manico]]
* [[User:Marcin|Marcin Wielgoszewski]]
* Kevin Coons from ManaTribe

'''News Commentary Team'''
* Mike Boberski
* [[User:brennan|Tom Brennan]]
* Arshan Dabirsiaghi
* Andre Gironda
* [[User:Jmanico|Jim Manico]]
* Alex Smolen
* Andrew van der Stock
* Jeff Williams

'''Artwork'''
* Larry Casey
* Gareth Heyes

'''Sponsors'''
* The OWASP Foundation
* Music by [http://www.twistedmusic.com/artists/shpongle/ Shpongle] courtesy of [http://www.twistedmusic.com/ Twisted Records]

'''Illuminati-like influence over the Podcast'''
* Tom Brennan
* Jeff Williams
* Dinis Druz
* Kate Hartmann
* [[User:Marcin|Marcin Wielgoszewski]]
* Tracey Schavone
* The OWASP Leadership eList

==== Twitter ====

[http://twitter.com/owasp_podcast http://twitter.com/owasp_podcast]

<twitter>20208646</twitter>

==== Artwork ====

<table border="0">
<tr>
<td>
[http://www.owasp.org/download/jmanico/OWASP_Podcast_200x200.jpg http://www.owasp.org/download/jmanico/OWASP_Podcast_200x200.jpg]
</td>
<td>
Larry Casey
</td>
</tr>
<tr>
<td>
[http://www.owasp.org/download/jmanico/OWASP_Podcast2_200x200.jpg http://www.owasp.org/download/jmanico/OWASP_Podcast2_200x200.jpg]
</td>
<td>
Gareth Heyes
</td>
</tr>
</table>

__NOTOC__
<headertabs/>

Cryptographic Storage Cheat Sheet

2010-01-14T05:56:56Z

Kkenan: /* Secure Cryptographic Storage Design */

= Introduction =

This article provides a simple model to follow when implementing solutions for data at rest. 

== Architectural Decision ==

An architectural decision must be made to determine the appropriate method to protect data at rest. There are such wide variety of products, methods and mechanisms for cryptographic storage that this cheat sheet will only focus on low-level guidelines for developers and architects who are implementing cryptographic solutions. We will not address specific vendor solutions, nor will we address the design of cryptographic algorithms.

= Providing Cryptographic Functionality =

== Benefits ==

== Basic Requirements ==

== Secure Cryptographic Storage Design ==

=== Rule - Only store sensitive data that you need ===

Many eCommerce businesses use payment providers that store the credit card for recurring billing. This offloads the burden of keeping credit card numbers safe.

=== Rule - Only use strong cryptographic algorithms ===

Only use approved public algorithms such as AES, RSA public key cryptography, and SHA-256 or better for hashing. Do not use weak algorithms, such as MD5 / SHA1/ Favor safer. The definition of a "strong" cryptographic algorithms change over time.

http://csrc.nist.gov/groups/STM/cavp/index.html

This is a good default if one doesn't have AES and one of the authenticated encryption modes that provide confidentiality and authenticity (i.e., data origin authentication) such as CCM, EAX, CMAC, etc. For Java, if you are using SunJCE that will be the case. The cipher modes supported in JDK 1.5 and later are CBC, CFB, CFBx, CTR, CTS, ECB, OFB, OFBx, PCBC, None of these cipher modes are authentication encryption modes. (That's why I added it explicitly.) If you are using an alternate JCE provider such as Bouncy Castle, RSA JSafe, IAIK, etc then some of these authentication encryption modes probably should be preferred.

Use salts when appropriate. Should note that integrity should be use a MAC (i.e., a keyed hash) and not a MIC (message integrity code). A MIC can be used as a keyed hash via

MIC(msg) = Secure_Hash( salt + msg )

but that is not as good as using something like HMAC-SHA1 or even better, HMAC-SHA256.

==== Rule - Store the hash value of passwords ====

Store the hashed value of the password. Salt each hash. Use a different random salt for each password hash. Never store the clear text password or an encrypted version of the password.

Cryptographic framework for password hashing is described in [http://www.rsa.com/rsalabs/node.asp?id=2127 PKCS #5 v2.1: Password-Based Cryptography Standard]. Specific secure password hashing algorithms exist such as [http://www.usenix.org/events/usenix99/provos/provos_html/node1.html bcrypt], [http://www.tarsnap.com/scrypt/scrypt.pdf scrypt]. Implementations of secure password hashing exist for PHP ([http://www.openwall.com/phpass/ phpass]), ASP.NET ([http://msdn.microsoft.com/en-us/library/ms998372.aspx#pagpractices0001_sensitivedata ASP.NET 2.0 Security Practices]), Java ([http://www.owasp.org/index.php/Hashing_Java OWASP Hashing Java]).

==== Rule - Ensure that random numbers are cryptographically strong ====

Ensure that all random numbers, random file names, random GUIDs, and random strings are generated in a cryptographically strong fashion.

TODO: This probably could use further explanation especially how entropy used to seed PRNGs plays an important role as well.

=== Rule - Only use widely accepted implementations of cryptographic algorithms ===

Do not implement an existing cryptographic algorithm on your own, no matter how easy it appears. Use widely accepted algorithms and widely accepted implementations only. Ensure that an implementation has, at least, had some cryptography experts involved in its creation. If possible, use an implementation that is FIPS 140-2 certified.

==== Rule - Only use strong cryptographic cipher modes ====

Use cryptographic cipher modes that offer both authenticity and confidentiality

ECB should almost unequivocally be avoided. If you use a cipher mode that treats a block cipher as a streaming mode, such as OFB or CFB, be careful you don't repeat the IV for the same encryption key. In general CBC is a decent cipher mode to use if message authenticity is not an issue and it a cipher mode that is almost always available. Better cipher modes are ones that offer
both authenticity and confidentiality such as those mentioned under the Wikipedia "Authenticated Encryption" article. See the "see also" section of <http://en.wikipedia.org/wiki/Authenticated_encryption> for a list of such cipher modes.

http://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet#Rule_-_Only_Support_Strong_Cryptographic_Ciphers

=== Rule - Ensure that the cryptographic protection remains secure even if the database access controls fail ===

This rule supports the principle of defense in depth. Access
controls (usernames, passwords, privileges, etc.) are one layer of
protection. Storage encryption should add an additional layer of
protection that will continue protecting the data even if an
attacker subverts the database access control layer.

=== Rule - Ensure that any secret key is protected from unauthorized access ===

==== Rule - Define a key lifecycle ====

The key lifecycle details the various states that a key will move through during its life. The lifecycle will specify when a key should no longer be used for encryption, when a key should no longer be used for decryption (these are not necessarily coincident), whether data must be rekeyed when a new key is introduced, and when a key should be removed from use all together.

==== Rule - Store unencrypted keys away from the encrypted data ====

If the keys are stored with the data then any compromise of the data will easily compromise the keys as well. Unencrypted keys should never reside on the same machine or cluster as the data.

==== Rule - Protect keys in a key vault ====

Ideally, keys should remain in a protected key vault at all times. In particular ensure that there is a gap between the threat vectors with direct access to the data and the threat vectors with direct access to the keys. This implies that keys should not be stored on the application or web server (assuming that application attackers are part of the relevant threat model).

==== Rule - Document concrete procedures for managing keys through the lifecycle ====

These procedures must be written down and the key custodians must be adequately trained.

==== Rule - Build support for changing keys periodically ====

Key rotation is a must as all good keys do come to an end either through expiration or revocation. So a developer will have to deal with rotating keys at some point -- better to have a system in place now rather than scrambling later. (From Bil Cory as a starting point).

==== Rule - Document concrete procedures to handle a key compromise ====

=== Rule - Rekey data at least every one to three years ===

Rekeying refers to the process of decrypting data and then re-encrypting it with a new key. Periodically rekeying data helps protect it from undetected compromises of older keys. The appropriate rekeying period depends on the security of the keys. Data protected by keys secured in dedicated hardware security modules might only need rekeying every three years. Data protected by keys that are split and stored on two application servers might need rekeying every year.

=== Rule - Follow applicable regulations on use of cryptography ===

==== Rule - Under PCI DSS requirement 3, you must protect cardholder data ====

The Payment Card Industry (PCI) Data Security Standard (DSS) was developed to encourage and enhance cardholder data security and facilitate the broad adoption of consistent data security measures globally. The standard was introduced in 2005 and replaced individual compliance standards from Visa, Mastercard, Amex, JCB and Diners. The current version of the standard was introduced in 2008 and an update to the standard is expected in 2010.

PCI DSS requirement 3 covers secure storage of credit card data. This requirement covers several aspects of secure storage including the data you must never store but we are covering Cryptographic Storage which is covered in requirements 3.4, 3.5 and 3.6 as you can see below:

'''3.4 Render PAN (Primary Account Number), at minimum, unreadable anywhere it is stored'''

Compliance with requirement 3.4 can be met by implementing any of the four types of secure storage described in the standard which includes encrypting and hashing data. These two approaches will often be the most popular choices from the list of options. The standard doesn't refer to any specific algorithms but it mandates the use of '''Strong Cryptography'''. The glossary document from the PCI council defines '''Strong Cryptography''' as:

''Cryptography based on industry-tested and accepted algorithms, along with strong key lengths and proper key-management practices. Cryptography is a method to protect data and includes both encryption (which is reversible) and hashing (which is not reversible, or “one way”). SHA-1 is an example of an industry-tested and accepted hashing algorithm. Examples of industry-tested and accepted standards and algorithms for encryption include AES (128 bits and higher), TDES (minimum double-length keys), RSA (1024 bits and higher), ECC (160 bits and higher), and ElGamal (1024 bits and higher).''

If you have implemented the second rule in this cheat sheet you will have implemented a strong cryptographic algorithm which is compliant with or stronger than the requirements of PCI DSS requirement 3.4 You need to ensure that you identify all locations that card data could be stored including logs and apply the appropriate level of protection. This could range from encrypting the data to replacing the card number in logs.

This requirement can also be met by implementing disk encryption rather than file or column level encryption. The requirements for '''Strong Cryptography''' are the same for disk encryption and backup media. The card data should never be stored in the clear and by following the guidance in this cheat sheet you will be able to securely store your data in a manner which is compliant with PCI DSS requirement 3.4

'''3.5 Protect cryptographic keys used for encryption of cardholder data against both disclosure and misuse'''

As the requirement name above indicates we are required to securely store the encryption keys themselves. This will mean implementing strong access control, auditing and logging for your keys. The keys must be stored in a location which is both secure and "away" from the encrypted data, this means key data shouldn't be stored on web servers, database servers etc

Access to the keys must be restricted to the smallest amount of users possible. This group of users will ideally be users who are highly trusted and trained to perform Key Custodian duties. There will obviously be a requirement for system/service accounts to access the key data to perform encryption/decryption of data.

The keys themselves shouldn't be stored in the clear but encrypted with a KEK (Key Encrypting Key). The KEK must not be stored in the same location as the encryption keys it is encrypting.

'''3.6 Fully document and implement all key-management processes and procedures for cryptographic keys used for encryption of cardholder data'''

Requirement 3.6 mandates that key management processes within a PCI compliant company cover 8 specific key lifecycle steps:

'''3.6.1 Generation of strong cryptographic keys'''

As we have previously described in this cheat sheet we need to use algorithms which offer high levels of data security. We must also generate strong keys so that the security of the data isn't undermined by weak cryptographic keys. A strong key is generated by using a key length which is sufficient for your data security requirements and compliant with the PCI DSS. The key size alone isn't a measure of the strength of a key. The data used to generate the key must be sufficiently random ("sufficient" often being determined by your data security requirements) and the entropy of the key data itself must be high. 

'''3.6.2 Secure cryptographic key distribution'''

The method used to distribute keys must be secure to prevent the theft of keys in transit. The use of a protocol such as Diffie Hellman can help secure the distribution of keys, the use of secure transport such as SSLv3, TLS and SSHv2 can also secure the keys in transit. 

'''3.6.3 Secure cryptographic key storage'''

The secure storage of encryption keys including KEK's has been touched on in our description of requirement 3.5 (see above).

'''3.6.4 Periodic cryptographic key changes'''

The PCI DSS standard mandates that keys used for encryption must be rotated at least annually. The key rotation process must remove an old key from the encryption/decryption process and replace it with a new key. The new key will be used to encrypt all of the existing data with the new key.

'''3.6.5 Retirement or replacement of old or suspected compromised cryptographic keys'''

The key management processes must cater for archived, retired or compromised keys. The process of securely storing and replacing these keys will more than likely be covered by your processes for requirements 3.6.2, 3.6.3 and 3.6.4

'''3.6.6 Split knowledge and establishment of dual control of cryptographic keys'''

The requirement for split knowledge and/or dual control for key management prevents an individual user performing key management tasks such as key rotation or deletion. The system should require two individual users to perform an action (i.e. entering a value from their own OTP) which creates to separate values which are concatenated to create the final key data.

'''3.6.7 Prevention of unauthorized substitution of cryptographic keys'''

The system put in place to comply with requirement 3.6.6 can go a long way to preventing unauthorised substitution of key data. In addition to the dual control process you should implement strong access control, auditing and logging for key data so that unauthorised access attempts are prevented and logged.

'''3.6.8 Requirement for cryptographic key custodians to sign a form stating that they understand and accept their key-custodian responsibilities'''

To perform the strong key management functions we have seen in requirement 3.6 we must have highly trusted and trained key custodians who understand how to perform key management duties. The key custodians must also sign a form stating they understand the responsibilities that come with this role.

= Related Articles =

OWASP - [[Testing for SSL-TLS (OWASP-CM-001)|Testing for SSL-TLS]], and OWASP [[Guide to Cryptography]]

OWASP – [http://www.owasp.org/index.php/ASVS Application Security Verification Standard (ASVS) – Communication Security Verification Requirements (V10)]

{{Cheatsheet_Navigation}}

= Authors and Primary Editors =

Jim Manico - jim[at]manico.net

Kevin Wall - kevin.w.wall[at]gmail.com

Kevin Kenan - kevin[at]k2dd.com

David Rook - david.a.rook[at]gmail.com

[[Category:How_To]] [[Category:Cheatsheets]] [[Category:OWASP_Document]] [[Category:OWASP_Top_Ten_Project]]

Cryptographic Storage Cheat Sheet

2010-01-14T05:55:18Z

Kkenan: /* Rule - Rekey data at least every one to three years */

= Introduction =

This article provides a simple model to follow when implementing solutions for data at rest. 

== Architectural Decision ==

An architectural decision must be made to determine the appropriate method to protect data at rest. There are such wide variety of products, methods and mechanisms for cryptographic storage that this cheat sheet will only focus on low-level guidelines for developers and architects who are implementing cryptographic solutions. We will not address specific vendor solutions, nor will we address the design of cryptographic algorithms.

= Providing Cryptographic Functionality =

== Benefits ==

== Basic Requirements ==

== Secure Cryptographic Storage Design ==

=== Rule - Only store sensitive data that you need ===

Many eCommerce businesses use payment providers that store the credit card for recurring billing. This offloads the burden of keeping credit card numbers safe.

=== Rule - Only use strong cryptographic algorithms ===

Only use approved public algorithms such as AES, RSA public key cryptography, and SHA-256 or better for hashing. Do not use weak algorithms, such as MD5 / SHA1/ Favor safer. The definition of a "strong" cryptographic algorithms change over time.

http://csrc.nist.gov/groups/STM/cavp/index.html

This is a good default if one doesn't have AES and one of the authenticated encryption modes that provide confidentiality and authenticity (i.e., data origin authentication) such as CCM, EAX, CMAC, etc. For Java, if you are using SunJCE that will be the case. The cipher modes supported in JDK 1.5 and later are CBC, CFB, CFBx, CTR, CTS, ECB, OFB, OFBx, PCBC, None of these cipher modes are authentication encryption modes. (That's why I added it explicitly.) If you are using an alternate JCE provider such as Bouncy Castle, RSA JSafe, IAIK, etc then some of these authentication encryption modes probably should be preferred.

Use salts when appropriate. Should note that integrity should be use a MAC (i.e., a keyed hash) and not a MIC (message integrity code). A MIC can be used as a keyed hash via

MIC(msg) = Secure_Hash( salt + msg )

but that is not as good as using something like HMAC-SHA1 or even better, HMAC-SHA256.

==== Rule - Store the hash value of passwords ====

Store the hashed value of the password. Salt each hash. Use a different random salt for each password hash. Never store the clear text password or an encrypted version of the password.

Cryptographic framework for password hashing is described in [http://www.rsa.com/rsalabs/node.asp?id=2127 PKCS #5 v2.1: Password-Based Cryptography Standard]. Specific secure password hashing algorithms exist such as [http://www.usenix.org/events/usenix99/provos/provos_html/node1.html bcrypt], [http://www.tarsnap.com/scrypt/scrypt.pdf scrypt]. Implementations of secure password hashing exist for PHP ([http://www.openwall.com/phpass/ phpass]), ASP.NET ([http://msdn.microsoft.com/en-us/library/ms998372.aspx#pagpractices0001_sensitivedata ASP.NET 2.0 Security Practices]), Java ([http://www.owasp.org/index.php/Hashing_Java OWASP Hashing Java]).

==== Rule - Ensure that random numbers are cryptographically strong ====

Ensure that all random numbers, random file names, random GUIDs, and random strings are generated in a cryptographically strong fashion.

TODO: This probably could use further explanation especially how entropy used to seed PRNGs plays an important role as well.

=== Rule - Only use widely accepted implementations of cryptographic algorithms ===

Do not implement an existing cryptographic algorithm on your own, no matter how easy it appears. Use widely accepted algorithms and widely accepted implementations only. Ensure that an implementation has, at least, had some cryptography experts involved in its creation. If possible, use an implementation that is FIPS 140-2 certified.

==== Rule - Only use strong cryptographic cipher modes ====

Use cryptographic cipher modes that offer both authenticity and confidentiality

ECB should almost unequivocally be avoided. If you use a cipher mode that treats a block cipher as a streaming mode, such as OFB or CFB, be careful you don't repeat the IV for the same encryption key. In general CBC is a decent cipher mode to use if message authenticity is not an issue and it a cipher mode that is almost always available. Better cipher modes are ones that offer
both authenticity and confidentiality such as those mentioned under the Wikipedia "Authenticated Encryption" article. See the "see also" section of <http://en.wikipedia.org/wiki/Authenticated_encryption> for a list of such cipher modes.

http://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet#Rule_-_Only_Support_Strong_Cryptographic_Ciphers

=== Rule - Rekey data at least every one to three years ===

Rekeying refers to the process of decrypting data and then re-encrypting it with a new key. Periodically rekeying data helps protect it from undetected compromises of older keys. The appropriate rekeying period depends on the security of the keys. Data protected by keys secured in dedicated hardware security modules might only need rekeying every three years. Data protected by keys that are split and stored on two application servers might need rekeying every year.

=== Rule - Ensure that the cryptographic protection remains secure even if the database access controls fail ===

This rule supports the principle of defense in depth. Access
controls (usernames, passwords, privileges, etc.) are one layer of
protection. Storage encryption should add an additional layer of
protection that will continue protecting the data even if an
attacker subverts the database access control layer.

=== Rule - Ensure that any secret key is protected from unauthorized access ===

==== Rule - Define a key lifecycle ====

The key lifecycle details the various states that a key will move through during its life. The lifecycle will specify when a key should no longer be used for encryption, when a key should no longer be used for decryption (these are not necessarily coincident), whether data must be rekeyed when a new key is introduced, and when a key should be removed from use all together.

==== Rule - Store unencrypted keys away from the encrypted data ====

If the keys are stored with the data then any compromise of the data will easily compromise the keys as well. Unencrypted keys should never reside on the same machine or cluster as the data.

==== Rule - Protect keys in a key vault ====

Ideally, keys should remain in a protected key vault at all times. In particular ensure that there is a gap between the threat vectors with direct access to the data and the threat vectors with direct access to the keys. This implies that keys should not be stored on the application or web server (assuming that application attackers are part of the relevant threat model).

==== Rule - Document concrete procedures for managing keys through the lifecycle ====

These procedures must be written down and the key custodians must be adequately trained.

==== Rule - Build support for changing keys periodically ====

Key rotation is a must as all good keys do come to an end either through expiration or revocation. So a developer will have to deal with rotating keys at some point -- better to have a system in place now rather than scrambling later. (From Bil Cory as a starting point).

==== Rule - Document concrete procedures to handle a key compromise ====

=== Rule - Follow applicable regulations on use of cryptography ===

==== Rule - Under PCI DSS requirement 3, you must protect cardholder data ====

The Payment Card Industry (PCI) Data Security Standard (DSS) was developed to encourage and enhance cardholder data security and facilitate the broad adoption of consistent data security measures globally. The standard was introduced in 2005 and replaced individual compliance standards from Visa, Mastercard, Amex, JCB and Diners. The current version of the standard was introduced in 2008 and an update to the standard is expected in 2010.

PCI DSS requirement 3 covers secure storage of credit card data. This requirement covers several aspects of secure storage including the data you must never store but we are covering Cryptographic Storage which is covered in requirements 3.4, 3.5 and 3.6 as you can see below:

'''3.4 Render PAN (Primary Account Number), at minimum, unreadable anywhere it is stored'''

Compliance with requirement 3.4 can be met by implementing any of the four types of secure storage described in the standard which includes encrypting and hashing data. These two approaches will often be the most popular choices from the list of options. The standard doesn't refer to any specific algorithms but it mandates the use of '''Strong Cryptography'''. The glossary document from the PCI council defines '''Strong Cryptography''' as:

''Cryptography based on industry-tested and accepted algorithms, along with strong key lengths and proper key-management practices. Cryptography is a method to protect data and includes both encryption (which is reversible) and hashing (which is not reversible, or “one way”). SHA-1 is an example of an industry-tested and accepted hashing algorithm. Examples of industry-tested and accepted standards and algorithms for encryption include AES (128 bits and higher), TDES (minimum double-length keys), RSA (1024 bits and higher), ECC (160 bits and higher), and ElGamal (1024 bits and higher).''

If you have implemented the second rule in this cheat sheet you will have implemented a strong cryptographic algorithm which is compliant with or stronger than the requirements of PCI DSS requirement 3.4 You need to ensure that you identify all locations that card data could be stored including logs and apply the appropriate level of protection. This could range from encrypting the data to replacing the card number in logs.

This requirement can also be met by implementing disk encryption rather than file or column level encryption. The requirements for '''Strong Cryptography''' are the same for disk encryption and backup media. The card data should never be stored in the clear and by following the guidance in this cheat sheet you will be able to securely store your data in a manner which is compliant with PCI DSS requirement 3.4

'''3.5 Protect cryptographic keys used for encryption of cardholder data against both disclosure and misuse'''

As the requirement name above indicates we are required to securely store the encryption keys themselves. This will mean implementing strong access control, auditing and logging for your keys. The keys must be stored in a location which is both secure and "away" from the encrypted data, this means key data shouldn't be stored on web servers, database servers etc

Access to the keys must be restricted to the smallest amount of users possible. This group of users will ideally be users who are highly trusted and trained to perform Key Custodian duties. There will obviously be a requirement for system/service accounts to access the key data to perform encryption/decryption of data.

The keys themselves shouldn't be stored in the clear but encrypted with a KEK (Key Encrypting Key). The KEK must not be stored in the same location as the encryption keys it is encrypting.

'''3.6 Fully document and implement all key-management processes and procedures for cryptographic keys used for encryption of cardholder data'''

Requirement 3.6 mandates that key management processes within a PCI compliant company cover 8 specific key lifecycle steps:

'''3.6.1 Generation of strong cryptographic keys'''

As we have previously described in this cheat sheet we need to use algorithms which offer high levels of data security. We must also generate strong keys so that the security of the data isn't undermined by weak cryptographic keys. A strong key is generated by using a key length which is sufficient for your data security requirements and compliant with the PCI DSS. The key size alone isn't a measure of the strength of a key. The data used to generate the key must be sufficiently random ("sufficient" often being determined by your data security requirements) and the entropy of the key data itself must be high. 

'''3.6.2 Secure cryptographic key distribution'''

The method used to distribute keys must be secure to prevent the theft of keys in transit. The use of a protocol such as Diffie Hellman can help secure the distribution of keys, the use of secure transport such as SSLv3, TLS and SSHv2 can also secure the keys in transit. 

'''3.6.3 Secure cryptographic key storage'''

The secure storage of encryption keys including KEK's has been touched on in our description of requirement 3.5 (see above).

'''3.6.4 Periodic cryptographic key changes'''

The PCI DSS standard mandates that keys used for encryption must be rotated at least annually. The key rotation process must remove an old key from the encryption/decryption process and replace it with a new key. The new key will be used to encrypt all of the existing data with the new key.

'''3.6.5 Retirement or replacement of old or suspected compromised cryptographic keys'''

The key management processes must cater for archived, retired or compromised keys. The process of securely storing and replacing these keys will more than likely be covered by your processes for requirements 3.6.2, 3.6.3 and 3.6.4

'''3.6.6 Split knowledge and establishment of dual control of cryptographic keys'''

The requirement for split knowledge and/or dual control for key management prevents an individual user performing key management tasks such as key rotation or deletion. The system should require two individual users to perform an action (i.e. entering a value from their own OTP) which creates to separate values which are concatenated to create the final key data.

'''3.6.7 Prevention of unauthorized substitution of cryptographic keys'''

The system put in place to comply with requirement 3.6.6 can go a long way to preventing unauthorised substitution of key data. In addition to the dual control process you should implement strong access control, auditing and logging for key data so that unauthorised access attempts are prevented and logged.

'''3.6.8 Requirement for cryptographic key custodians to sign a form stating that they understand and accept their key-custodian responsibilities'''

To perform the strong key management functions we have seen in requirement 3.6 we must have highly trusted and trained key custodians who understand how to perform key management duties. The key custodians must also sign a form stating they understand the responsibilities that come with this role.

= Related Articles =

OWASP - [[Testing for SSL-TLS (OWASP-CM-001)|Testing for SSL-TLS]], and OWASP [[Guide to Cryptography]]

OWASP – [http://www.owasp.org/index.php/ASVS Application Security Verification Standard (ASVS) – Communication Security Verification Requirements (V10)]

{{Cheatsheet_Navigation}}

= Authors and Primary Editors =

Jim Manico - jim[at]manico.net

Kevin Wall - kevin.w.wall[at]gmail.com

Kevin Kenan - kevin[at]k2dd.com

David Rook - david.a.rook[at]gmail.com

[[Category:How_To]] [[Category:Cheatsheets]] [[Category:OWASP_Document]] [[Category:OWASP_Top_Ten_Project]]

Cryptographic Storage Cheat Sheet

2010-01-14T05:53:16Z

Kkenan: /* Secure Cryptographic Storage Design */

= Introduction =

This article provides a simple model to follow when implementing solutions for data at rest. 

== Architectural Decision ==

An architectural decision must be made to determine the appropriate method to protect data at rest. There are such wide variety of products, methods and mechanisms for cryptographic storage that this cheat sheet will only focus on low-level guidelines for developers and architects who are implementing cryptographic solutions. We will not address specific vendor solutions, nor will we address the design of cryptographic algorithms.

= Providing Cryptographic Functionality =

== Benefits ==

== Basic Requirements ==

== Secure Cryptographic Storage Design ==

=== Rule - Only store sensitive data that you need ===

Many eCommerce businesses use payment providers that store the credit card for recurring billing. This offloads the burden of keeping credit card numbers safe.

=== Rule - Only use strong cryptographic algorithms ===

Only use approved public algorithms such as AES, RSA public key cryptography, and SHA-256 or better for hashing. Do not use weak algorithms, such as MD5 / SHA1/ Favor safer. The definition of a "strong" cryptographic algorithms change over time.

http://csrc.nist.gov/groups/STM/cavp/index.html

This is a good default if one doesn't have AES and one of the authenticated encryption modes that provide confidentiality and authenticity (i.e., data origin authentication) such as CCM, EAX, CMAC, etc. For Java, if you are using SunJCE that will be the case. The cipher modes supported in JDK 1.5 and later are CBC, CFB, CFBx, CTR, CTS, ECB, OFB, OFBx, PCBC, None of these cipher modes are authentication encryption modes. (That's why I added it explicitly.) If you are using an alternate JCE provider such as Bouncy Castle, RSA JSafe, IAIK, etc then some of these authentication encryption modes probably should be preferred.

Use salts when appropriate. Should note that integrity should be use a MAC (i.e., a keyed hash) and not a MIC (message integrity code). A MIC can be used as a keyed hash via

MIC(msg) = Secure_Hash( salt + msg )

but that is not as good as using something like HMAC-SHA1 or even better, HMAC-SHA256.

==== Rule - Store the hash value of passwords ====

Store the hashed value of the password. Salt each hash. Use a different random salt for each password hash. Never store the clear text password or an encrypted version of the password.

Cryptographic framework for password hashing is described in [http://www.rsa.com/rsalabs/node.asp?id=2127 PKCS #5 v2.1: Password-Based Cryptography Standard]. Specific secure password hashing algorithms exist such as [http://www.usenix.org/events/usenix99/provos/provos_html/node1.html bcrypt], [http://www.tarsnap.com/scrypt/scrypt.pdf scrypt]. Implementations of secure password hashing exist for PHP ([http://www.openwall.com/phpass/ phpass]), ASP.NET ([http://msdn.microsoft.com/en-us/library/ms998372.aspx#pagpractices0001_sensitivedata ASP.NET 2.0 Security Practices]), Java ([http://www.owasp.org/index.php/Hashing_Java OWASP Hashing Java]).

==== Rule - Ensure that random numbers are cryptographically strong ====

Ensure that all random numbers, random file names, random GUIDs, and random strings are generated in a cryptographically strong fashion.

TODO: This probably could use further explanation especially how entropy used to seed PRNGs plays an important role as well.

=== Rule - Only use widely accepted implementations of cryptographic algorithms ===

Do not implement an existing cryptographic algorithm on your own, no matter how easy it appears. Use widely accepted algorithms and widely accepted implementations only. Ensure that an implementation has, at least, had some cryptography experts involved in its creation. If possible, use an implementation that is FIPS 140-2 certified.

==== Rule - Only use strong cryptographic cipher modes ====

Use cryptographic cipher modes that offer both authenticity and confidentiality

ECB should almost unequivocally be avoided. If you use a cipher mode that treats a block cipher as a streaming mode, such as OFB or CFB, be careful you don't repeat the IV for the same encryption key. In general CBC is a decent cipher mode to use if message authenticity is not an issue and it a cipher mode that is almost always available. Better cipher modes are ones that offer
both authenticity and confidentiality such as those mentioned under the Wikipedia "Authenticated Encryption" article. See the "see also" section of <http://en.wikipedia.org/wiki/Authenticated_encryption> for a list of such cipher modes.

http://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet#Rule_-_Only_Support_Strong_Cryptographic_Ciphers

=== Rule - Rekey data at least every one to three years ===

Periodically rekeying data helps protect it from undetected key compromises. The rekeying period depends on the security of the keys. Data protected by keys secured in dedicated hardware security modules might only need rekeying every three years. Data protected by keys that are split and stored on two application servers might need rekeying every year.

=== Rule - Ensure that the cryptographic protection remains secure even if the database access controls fail ===

This rule supports the principle of defense in depth. Access
controls (usernames, passwords, privileges, etc.) are one layer of
protection. Storage encryption should add an additional layer of
protection that will continue protecting the data even if an
attacker subverts the database access control layer.

=== Rule - Ensure that any secret key is protected from unauthorized access ===

==== Rule - Define a key lifecycle ====

The key lifecycle details the various states that a key will move through during its life. The lifecycle will specify when a key should no longer be used for encryption, when a key should no longer be used for decryption (these are not necessarily coincident), whether data must be rekeyed when a new key is introduced, and when a key should be removed from use all together.

==== Rule - Store unencrypted keys away from the encrypted data ====

If the keys are stored with the data then any compromise of the data will easily compromise the keys as well. Unencrypted keys should never reside on the same machine or cluster as the data.

==== Rule - Protect keys in a key vault ====

Ideally, keys should remain in a protected key vault at all times. In particular ensure that there is a gap between the threat vectors with direct access to the data and the threat vectors with direct access to the keys. This implies that keys should not be stored on the application or web server (assuming that application attackers are part of the relevant threat model).

==== Rule - Document concrete procedures for managing keys through the lifecycle ====

These procedures must be written down and the key custodians must be adequately trained.

==== Rule - Build support for changing keys periodically ====

Key rotation is a must as all good keys do come to an end either through expiration or revocation. So a developer will have to deal with rotating keys at some point -- better to have a system in place now rather than scrambling later. (From Bil Cory as a starting point).

==== Rule - Document concrete procedures to handle a key compromise ====

=== Rule - Follow applicable regulations on use of cryptography ===

==== Rule - Under PCI DSS requirement 3, you must protect cardholder data ====

The Payment Card Industry (PCI) Data Security Standard (DSS) was developed to encourage and enhance cardholder data security and facilitate the broad adoption of consistent data security measures globally. The standard was introduced in 2005 and replaced individual compliance standards from Visa, Mastercard, Amex, JCB and Diners. The current version of the standard was introduced in 2008 and an update to the standard is expected in 2010.

PCI DSS requirement 3 covers secure storage of credit card data. This requirement covers several aspects of secure storage including the data you must never store but we are covering Cryptographic Storage which is covered in requirements 3.4, 3.5 and 3.6 as you can see below:

'''3.4 Render PAN (Primary Account Number), at minimum, unreadable anywhere it is stored'''

Compliance with requirement 3.4 can be met by implementing any of the four types of secure storage described in the standard which includes encrypting and hashing data. These two approaches will often be the most popular choices from the list of options. The standard doesn't refer to any specific algorithms but it mandates the use of '''Strong Cryptography'''. The glossary document from the PCI council defines '''Strong Cryptography''' as:

''Cryptography based on industry-tested and accepted algorithms, along with strong key lengths and proper key-management practices. Cryptography is a method to protect data and includes both encryption (which is reversible) and hashing (which is not reversible, or “one way”). SHA-1 is an example of an industry-tested and accepted hashing algorithm. Examples of industry-tested and accepted standards and algorithms for encryption include AES (128 bits and higher), TDES (minimum double-length keys), RSA (1024 bits and higher), ECC (160 bits and higher), and ElGamal (1024 bits and higher).''

If you have implemented the second rule in this cheat sheet you will have implemented a strong cryptographic algorithm which is compliant with or stronger than the requirements of PCI DSS requirement 3.4 You need to ensure that you identify all locations that card data could be stored including logs and apply the appropriate level of protection. This could range from encrypting the data to replacing the card number in logs.

This requirement can also be met by implementing disk encryption rather than file or column level encryption. The requirements for '''Strong Cryptography''' are the same for disk encryption and backup media. The card data should never be stored in the clear and by following the guidance in this cheat sheet you will be able to securely store your data in a manner which is compliant with PCI DSS requirement 3.4

'''3.5 Protect cryptographic keys used for encryption of cardholder data against both disclosure and misuse'''

As the requirement name above indicates we are required to securely store the encryption keys themselves. This will mean implementing strong access control, auditing and logging for your keys. The keys must be stored in a location which is both secure and "away" from the encrypted data, this means key data shouldn't be stored on web servers, database servers etc

Access to the keys must be restricted to the smallest amount of users possible. This group of users will ideally be users who are highly trusted and trained to perform Key Custodian duties. There will obviously be a requirement for system/service accounts to access the key data to perform encryption/decryption of data.

The keys themselves shouldn't be stored in the clear but encrypted with a KEK (Key Encrypting Key). The KEK must not be stored in the same location as the encryption keys it is encrypting.

'''3.6 Fully document and implement all key-management processes and procedures for cryptographic keys used for encryption of cardholder data'''

Requirement 3.6 mandates that key management processes within a PCI compliant company cover 8 specific key lifecycle steps:

'''3.6.1 Generation of strong cryptographic keys'''

As we have previously described in this cheat sheet we need to use algorithms which offer high levels of data security. We must also generate strong keys so that the security of the data isn't undermined by weak cryptographic keys. A strong key is generated by using a key length which is sufficient for your data security requirements and compliant with the PCI DSS. The key size alone isn't a measure of the strength of a key. The data used to generate the key must be sufficiently random ("sufficient" often being determined by your data security requirements) and the entropy of the key data itself must be high. 

'''3.6.2 Secure cryptographic key distribution'''

The method used to distribute keys must be secure to prevent the theft of keys in transit. The use of a protocol such as Diffie Hellman can help secure the distribution of keys, the use of secure transport such as SSLv3, TLS and SSHv2 can also secure the keys in transit. 

'''3.6.3 Secure cryptographic key storage'''

The secure storage of encryption keys including KEK's has been touched on in our description of requirement 3.5 (see above).

'''3.6.4 Periodic cryptographic key changes'''

The PCI DSS standard mandates that keys used for encryption must be rotated at least annually. The key rotation process must remove an old key from the encryption/decryption process and replace it with a new key. The new key will be used to encrypt all of the existing data with the new key.

'''3.6.5 Retirement or replacement of old or suspected compromised cryptographic keys'''

The key management processes must cater for archived, retired or compromised keys. The process of securely storing and replacing these keys will more than likely be covered by your processes for requirements 3.6.2, 3.6.3 and 3.6.4

'''3.6.6 Split knowledge and establishment of dual control of cryptographic keys'''

The requirement for split knowledge and/or dual control for key management prevents an individual user performing key management tasks such as key rotation or deletion. The system should require two individual users to perform an action (i.e. entering a value from their own OTP) which creates to separate values which are concatenated to create the final key data.

'''3.6.7 Prevention of unauthorized substitution of cryptographic keys'''

The system put in place to comply with requirement 3.6.6 can go a long way to preventing unauthorised substitution of key data. In addition to the dual control process you should implement strong access control, auditing and logging for key data so that unauthorised access attempts are prevented and logged.

'''3.6.8 Requirement for cryptographic key custodians to sign a form stating that they understand and accept their key-custodian responsibilities'''

To perform the strong key management functions we have seen in requirement 3.6 we must have highly trusted and trained key custodians who understand how to perform key management duties. The key custodians must also sign a form stating they understand the responsibilities that come with this role.

= Related Articles =

OWASP - [[Testing for SSL-TLS (OWASP-CM-001)|Testing for SSL-TLS]], and OWASP [[Guide to Cryptography]]

OWASP – [http://www.owasp.org/index.php/ASVS Application Security Verification Standard (ASVS) – Communication Security Verification Requirements (V10)]

{{Cheatsheet_Navigation}}

= Authors and Primary Editors =

Jim Manico - jim[at]manico.net

Kevin Wall - kevin.w.wall[at]gmail.com

Kevin Kenan - kevin[at]k2dd.com

David Rook - david.a.rook[at]gmail.com

[[Category:How_To]] [[Category:Cheatsheets]] [[Category:OWASP_Document]] [[Category:OWASP_Top_Ten_Project]]

Cryptographic Storage Cheat Sheet

2010-01-14T05:51:38Z

Kkenan: /* Secure Cryptographic Storage Design */

= Introduction =

This article provides a simple model to follow when implementing solutions for data at rest. 

== Architectural Decision ==

An architectural decision must be made to determine the appropriate method to protect data at rest. There are such wide variety of products, methods and mechanisms for cryptographic storage that this cheat sheet will only focus on low-level guidelines for developers and architects who are implementing cryptographic solutions. We will not address specific vendor solutions, nor will we address the design of cryptographic algorithms.

= Providing Cryptographic Functionality =

== Benefits ==

== Basic Requirements ==

== Secure Cryptographic Storage Design ==

=== Rule - Only store sensitive data that you need ===

Many eCommerce businesses use payment providers that store the credit card for recurring billing. This offloads the burden of keeping credit card numbers safe.

=== Rule - Only use strong cryptographic algorithms ===

Only use approved public algorithms such as AES, RSA public key cryptography, and SHA-256 or better for hashing. Do not use weak algorithms, such as MD5 / SHA1/ Favor safer. The definition of a "strong" cryptographic algorithms change over time.

http://csrc.nist.gov/groups/STM/cavp/index.html

This is a good default if one doesn't have AES and one of the authenticated encryption modes that provide confidentiality and authenticity (i.e., data origin authentication) such as CCM, EAX, CMAC, etc. For Java, if you are using SunJCE that will be the case. The cipher modes supported in JDK 1.5 and later are CBC, CFB, CFBx, CTR, CTS, ECB, OFB, OFBx, PCBC, None of these cipher modes are authentication encryption modes. (That's why I added it explicitly.) If you are using an alternate JCE provider such as Bouncy Castle, RSA JSafe, IAIK, etc then some of these authentication encryption modes probably should be preferred.

Use salts when appropriate. Should note that integrity should be use a MAC (i.e., a keyed hash) and not a MIC (message integrity code). A MIC can be used as a keyed hash via

MIC(msg) = Secure_Hash( salt + msg )

but that is not as good as using something like HMAC-SHA1 or even better, HMAC-SHA256.

==== Rule - Store the hash value of passwords ====

Store the hashed value of the password. Salt each hash. Use a different random salt for each password hash. Never store the clear text password or an encrypted version of the password.

Cryptographic framework for password hashing is described in [http://www.rsa.com/rsalabs/node.asp?id=2127 PKCS #5 v2.1: Password-Based Cryptography Standard]. Specific secure password hashing algorithms exist such as [http://www.usenix.org/events/usenix99/provos/provos_html/node1.html bcrypt], [http://www.tarsnap.com/scrypt/scrypt.pdf scrypt]. Implementations of secure password hashing exist for PHP ([http://www.openwall.com/phpass/ phpass]), ASP.NET ([http://msdn.microsoft.com/en-us/library/ms998372.aspx#pagpractices0001_sensitivedata ASP.NET 2.0 Security Practices]), Java ([http://www.owasp.org/index.php/Hashing_Java OWASP Hashing Java]).

==== Rule - Ensure that random numbers are cryptographically strong ====

Ensure that all random numbers, random file names, random GUIDs, and random strings are generated in a cryptographically strong fashion.

TODO: This probably could use further explanation especially how entropy used to seed PRNGs plays an important role as well.

=== Rule - Only use widely accepted implementations of cryptographic algorithms ===

Do not implement an existing cryptographic algorithm on your own, no matter how easy it appears. Use widely accepted algorithms and widely accepted implementations only. Ensure that an implementation has, at least, had some cryptography experts involved in its creation. If possible, use an implementation that is FIPS 140-2 certified.

==== Rule - Only use strong cryptographic cipher modes ====

Use cryptographic cipher modes that offer both authenticity and confidentiality

ECB should almost unequivocally be avoided. If you use a cipher mode that treats a block cipher as a streaming mode, such as OFB or CFB, be careful you don't repeat the IV for the same encryption key. In general CBC is a decent cipher mode to use if message authenticity is not an issue and it a cipher mode that is almost always available. Better cipher modes are ones that offer
both authenticity and confidentiality such as those mentioned under the Wikipedia "Authenticated Encryption" article. See the "see also" section of <http://en.wikipedia.org/wiki/Authenticated_encryption> for a list of such cipher modes.

http://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet#Rule_-_Only_Support_Strong_Cryptographic_Ciphers

=== Rule - Rekey data at least every one to three years ===

Periodically rekeying data helps protect it from undetected key compromises. The rekeying period depends on the security of the keys. Data protected by keys secured in dedicated hardware security modules might only need rekeying every three years. Data protected by keys that are split and stored on two application servers might need rekeying every year.

=== Rule - Ensure that any secret key is protected from unauthorized access ===

==== Rule - Define a key lifecycle ====

The key lifecycle details the various states that a key will move through during its life. The lifecycle will specify when a key should no longer be used for encryption, when a key should no longer be used for decryption (these are not necessarily coincident), whether data must be rekeyed when a new key is introduced, and when a key should be removed from use all together.

==== Rule - Store unencrypted keys away from the encrypted data ====

If the keys are stored with the data then any compromise of the data will easily compromise the keys as well. Unencrypted keys should never reside on the same machine or cluster as the data.

==== Rule - Protect keys in a key vault ====

Ideally, keys should remain in a protected key vault at all times. In particular ensure that there is a gap between the threat vectors with direct access to the data and the threat vectors with direct access to the keys. This implies that keys should not be stored on the application or web server (assuming that application attackers are part of the relevant threat model).

==== Rule - Document concrete procedures for managing keys through the lifecycle ====

These procedures must be written down and the key custodians must be adequately trained.

==== Rule - Build support for changing keys periodically ====

Key rotation is a must as all good keys do come to an end either through expiration or revocation. So a developer will have to deal with rotating keys at some point -- better to have a system in place now rather than scrambling later. (From Bil Cory as a starting point).

==== Rule - Document concrete procedures to handle a key compromise ====

=== Rule - Follow applicable regulations on use of cryptography ===

==== Rule - Under PCI DSS requirement 3, you must protect cardholder data ====

The Payment Card Industry (PCI) Data Security Standard (DSS) was developed to encourage and enhance cardholder data security and facilitate the broad adoption of consistent data security measures globally. The standard was introduced in 2005 and replaced individual compliance standards from Visa, Mastercard, Amex, JCB and Diners. The current version of the standard was introduced in 2008 and an update to the standard is expected in 2010.

PCI DSS requirement 3 covers secure storage of credit card data. This requirement covers several aspects of secure storage including the data you must never store but we are covering Cryptographic Storage which is covered in requirements 3.4, 3.5 and 3.6 as you can see below:

'''3.4 Render PAN (Primary Account Number), at minimum, unreadable anywhere it is stored'''

Compliance with requirement 3.4 can be met by implementing any of the four types of secure storage described in the standard which includes encrypting and hashing data. These two approaches will often be the most popular choices from the list of options. The standard doesn't refer to any specific algorithms but it mandates the use of '''Strong Cryptography'''. The glossary document from the PCI council defines '''Strong Cryptography''' as:

''Cryptography based on industry-tested and accepted algorithms, along with strong key lengths and proper key-management practices. Cryptography is a method to protect data and includes both encryption (which is reversible) and hashing (which is not reversible, or “one way”). SHA-1 is an example of an industry-tested and accepted hashing algorithm. Examples of industry-tested and accepted standards and algorithms for encryption include AES (128 bits and higher), TDES (minimum double-length keys), RSA (1024 bits and higher), ECC (160 bits and higher), and ElGamal (1024 bits and higher).''

If you have implemented the second rule in this cheat sheet you will have implemented a strong cryptographic algorithm which is compliant with or stronger than the requirements of PCI DSS requirement 3.4 You need to ensure that you identify all locations that card data could be stored including logs and apply the appropriate level of protection. This could range from encrypting the data to replacing the card number in logs.

This requirement can also be met by implementing disk encryption rather than file or column level encryption. The requirements for '''Strong Cryptography''' are the same for disk encryption and backup media. The card data should never be stored in the clear and by following the guidance in this cheat sheet you will be able to securely store your data in a manner which is compliant with PCI DSS requirement 3.4

'''3.5 Protect cryptographic keys used for encryption of cardholder data against both disclosure and misuse'''

As the requirement name above indicates we are required to securely store the encryption keys themselves. This will mean implementing strong access control, auditing and logging for your keys. The keys must be stored in a location which is both secure and "away" from the encrypted data, this means key data shouldn't be stored on web servers, database servers etc

Access to the keys must be restricted to the smallest amount of users possible. This group of users will ideally be users who are highly trusted and trained to perform Key Custodian duties. There will obviously be a requirement for system/service accounts to access the key data to perform encryption/decryption of data.

The keys themselves shouldn't be stored in the clear but encrypted with a KEK (Key Encrypting Key). The KEK must not be stored in the same location as the encryption keys it is encrypting.

'''3.6 Fully document and implement all key-management processes and procedures for cryptographic keys used for encryption of cardholder data'''

Requirement 3.6 mandates that key management processes within a PCI compliant company cover 8 specific key lifecycle steps:

'''3.6.1 Generation of strong cryptographic keys'''

As we have previously described in this cheat sheet we need to use algorithms which offer high levels of data security. We must also generate strong keys so that the security of the data isn't undermined by weak cryptographic keys. A strong key is generated by using a key length which is sufficient for your data security requirements and compliant with the PCI DSS. The key size alone isn't a measure of the strength of a key. The data used to generate the key must be sufficiently random ("sufficient" often being determined by your data security requirements) and the entropy of the key data itself must be high. 

'''3.6.2 Secure cryptographic key distribution'''

The method used to distribute keys must be secure to prevent the theft of keys in transit. The use of a protocol such as Diffie Hellman can help secure the distribution of keys, the use of secure transport such as SSLv3, TLS and SSHv2 can also secure the keys in transit. 

'''3.6.3 Secure cryptographic key storage'''

The secure storage of encryption keys including KEK's has been touched on in our description of requirement 3.5 (see above).

'''3.6.4 Periodic cryptographic key changes'''

The PCI DSS standard mandates that keys used for encryption must be rotated at least annually. The key rotation process must remove an old key from the encryption/decryption process and replace it with a new key. The new key will be used to encrypt all of the existing data with the new key.

'''3.6.5 Retirement or replacement of old or suspected compromised cryptographic keys'''

The key management processes must cater for archived, retired or compromised keys. The process of securely storing and replacing these keys will more than likely be covered by your processes for requirements 3.6.2, 3.6.3 and 3.6.4

'''3.6.6 Split knowledge and establishment of dual control of cryptographic keys'''

The requirement for split knowledge and/or dual control for key management prevents an individual user performing key management tasks such as key rotation or deletion. The system should require two individual users to perform an action (i.e. entering a value from their own OTP) which creates to separate values which are concatenated to create the final key data.

'''3.6.7 Prevention of unauthorized substitution of cryptographic keys'''

The system put in place to comply with requirement 3.6.6 can go a long way to preventing unauthorised substitution of key data. In addition to the dual control process you should implement strong access control, auditing and logging for key data so that unauthorised access attempts are prevented and logged.

'''3.6.8 Requirement for cryptographic key custodians to sign a form stating that they understand and accept their key-custodian responsibilities'''

To perform the strong key management functions we have seen in requirement 3.6 we must have highly trusted and trained key custodians who understand how to perform key management duties. The key custodians must also sign a form stating they understand the responsibilities that come with this role.

= Related Articles =

OWASP - [[Testing for SSL-TLS (OWASP-CM-001)|Testing for SSL-TLS]], and OWASP [[Guide to Cryptography]]

OWASP – [http://www.owasp.org/index.php/ASVS Application Security Verification Standard (ASVS) – Communication Security Verification Requirements (V10)]

{{Cheatsheet_Navigation}}

= Authors and Primary Editors =

Jim Manico - jim[at]manico.net

Kevin Wall - kevin.w.wall[at]gmail.com

Kevin Kenan - kevin[at]k2dd.com

David Rook - david.a.rook[at]gmail.com

[[Category:How_To]] [[Category:Cheatsheets]] [[Category:OWASP_Document]] [[Category:OWASP_Top_Ten_Project]]

Cryptographic Storage Cheat Sheet

2010-01-06T07:41:36Z

Kkenan: /* Secure Cryptographic Storage Design */

= WORK IN PROGRESS =

= Introduction =

This article provides a simple model to follow when implementing solutions for data at rest. 

== Architectural Decision ==

An architectural decision must be made to determine the appropriate method to protect data at rest. There are such wide variety of products, methods and mechanisms for cryptographic storage that this cheat sheet will only focus on low-level guidelines for developers and architects who are implementing cryptographic solutions. We will not address specific vendor solutions, nor will we address the design of cryptographic algorithms.

= Providing Cryptographic Functionality =

== Benefits ==

== Basic Requirements ==

== Secure Cryptographic Storage Design ==

=== Rule - Only Store Sensitive Data That You Need ===

Many eCommerce businesses use payment providers that store the credit card for recurring billing. This offloads the burden of keeping credit card numbers safe.

=== Rule - Only Use Strong Cryptographic Algorithms ===

Only use approved public algorithms such as AES, RSA public key cryptography, and SHA-256 or better for hashing. Do not use weak algorithms, such as MD5 / SHA1/ Favor safer. The definition of a "strong" cryptographic algorithms change over time.

http://csrc.nist.gov/groups/STM/cavp/index.html

This is a good default if one doesn't have AES and one of the authenticated encryption modes that provide confidentiality and authenticity (i.e., data origin authentication) such as CCM, EAX, CMAC, etc. For Java, if you are using SunJCE that will be the case. The cipher modes supported in JDK 1.5 and later are CBC, CFB, CFBx, CTR, CTS, ECB, OFB, OFBx, PCBC, None of these cipher modes are authentication encryption modes. (That's why I added it explicitly.) If you are using an alternate JCE provider such as Bouncy Castle, RSA JSafe, IAIK, etc then some of these authentication encryption modes probably should be preferred.

Use salts when appropriate. Should note that integrity should be use a MAC (i.e., a keyed hash) and not a MIC (message integrity code). A MIC can be used as a keyed hash via

MIC(msg) = Secure_Hash( salt + msg )

but that is not as good as using something like HMAC-SHA1 or even better, HMAC-SHA256.

==== Rule - Store the Hash Value of Passwords ====

Store the hashed value of the password. Salt each hash. Use a different random salt for each password hash. Never store the clear text password or an encrypted version of the password.

==== Rule - Ensure That Random Numbers are Cryptographically Strong ====

Ensure that all random numbers, random file names, random GUIDs, and random strings are generated in a cryptographically strong fashion.

TODO: This probably could use further explanation especially how entropy used to seed PRNGs plays an important role as well.

=== Rule - Only Use Widely Accepted Implementations of Cryptographic Algorithms ===

Do not implement an existing cryptographic algorithm on your own, no matter how easy it appears. Use widely accepted algorithms and widely accepted implementations only. Ensure that an implementation has, at least, had some cryptography experts involved in its creation. If possible, use an implementation that is FIPS 140-2 certified.

==== Rule - Only Use Strong Cryptographic Cipher Modes ====

Use cryptographic cipher modes that offer both authenticity and confidentiality

ECB should almost unequivocally be avoided. If you use a cipher mode that treats a block cipher as a streaming mode, such as OFB or CFB, be careful you don't repeat the IV for the same encryption key. In general CBC is a decent cipher mode to use if message authenticity is not an issue and it a cipher mode that is almost always available. Better cipher modes are ones that offer
both authenticity and confidentiality such as those mentioned under the Wikipedia "Authenticated Encryption" article. See the "see also" section of <http://en.wikipedia.org/wiki/Authenticated_encryption> for a list of such cipher modes.

http://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet#Rule_-_Only_Support_Strong_Cryptographic_Ciphers

=== Rule - Ensure That Any Secret Key Is Protected From Unauthorized Access ===

==== Rule - Define a key lifecycle ====

The key lifecycle details the various states that a key will move through during its life. The lifecycle will specify when a key should no longer be used for encryption, when a key should no longer be used for decryption (these are not necessarily coincident), whether data must be rekeyed when a new key is introduced, and when a key should be removed from use all together.

==== Rule - Store unencrypted keys away from the encrypted data ====

If the keys are stored with the data then any compromise of the data will easily compromise the keys as well. Unencrypted keys should never reside on the same machine or cluster as the data.

==== Rule - Protect keys in a key vault ====

Ideally, keys should remain in a protected key vault at all times. In particular ensure that there is a gap between the threat vectors with direct access to the data and the threat vectors with direct access to the keys. This implies that keys should not be stored on the application or web server (assuming that application attackers are part of the relevant threat model).

==== Rule - Document concrete procedures for managing keys through the lifecycle ====

These procedures must be written down and the key custodians must be adequately trained.

==== Rule - Build Support For Changing Keys Periodically ====

Key rotation is a must as all good keys do come to an end either through expiration or revocation. So a developer will have to deal with rotating keys at some point -- better to have a system in place now rather than scrambling later. (From Bil Cory as a starting point).

==== Rule - Document concrete procedures to handle a key compromise ====

=== Rule - Follow Applicable Regulations On Use Of Cryptography ===

==== Rule - Under PCI Data Security Standard requirement 3, you must protect cardholder data ====

PCI DSS compliance is mandatory by 2008 for merchants and anyone else dealing with credit cards. Good practice is to never store unnecessary data.

= Related Articles =

OWASP - [[Testing for SSL-TLS (OWASP-CM-001)|Testing for SSL-TLS]], and OWASP [[Guide to Cryptography]]

OWASP – [http://www.owasp.org/index.php/ASVS Application Security Verification Standard (ASVS) – Communication Security Verification Requirements (V10)]

'''Other Articles in the OWASP Prevention Cheat Sheet Series'''

* [[XSS (Cross Site Scripting) Prevention Cheat Sheet]]
* [[Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet]]
* [[SQL Injection Prevention Cheat Sheet]]
* [[Transport Layer Protection Cheat Sheet]]

= Authors and Primary Editors =

Jim Manico - jim.manico[at]aspectsecurity.com

Kevin Wall - kevin.w.wall[at]gmail.com

[[Category:How_To]] [[Category:Cheatsheets]] [[Category:OWASP_Document]] [[Category:OWASP_Top_Ten_Project]]

Cryptographic Storage Cheat Sheet

2010-01-06T07:40:07Z

Kkenan: /* Secure Cryptographic Storage Design */

= WORK IN PROGRESS =

= Introduction =

This article provides a simple model to follow when implementing solutions for data at rest. 

== Architectural Decision ==

An architectural decision must be made to determine the appropriate method to protect data at rest. There are such wide variety of products, methods and mechanisms for cryptographic storage that this cheat sheet will only focus on low-level guidelines for developers and architects who are implementing cryptographic solutions. We will not address specific vendor solutions, nor will we address the design of cryptographic algorithms.

= Providing Cryptographic Functionality =

== Benefits ==

== Basic Requirements ==

== Secure Cryptographic Storage Design ==

=== Rule - Only Store Sensitive Data That You Need ===

Many eCommerce businesses use payment providers that store the credit card for recurring billing. This offloads the burden of keeping credit card numbers safe.

=== Rule - Only Use Strong Cryptographic Algorithms ===

Only use approved public algorithms such as AES, RSA public key cryptography, and SHA-256 or better for hashing. Do not use weak algorithms, such as MD5 / SHA1/ Favor safer. The definition of a "strong" cryptographic algorithms change over time.

http://csrc.nist.gov/groups/STM/cavp/index.html

This is a good default if one doesn't have AES and one of the authenticated encryption modes that provide confidentiality and authenticity (i.e., data origin authentication) such as CCM, EAX, CMAC, etc. For Java, if you are using SunJCE that will be the case. The cipher modes supported in JDK 1.5 and later are CBC, CFB, CFBx, CTR, CTS, ECB, OFB, OFBx, PCBC, None of these cipher modes are authentication encryption modes. (That's why I added it explicitly.) If you are using an alternate JCE provider such as Bouncy Castle, RSA JSafe, IAIK, etc then some of these authentication encryption modes probably should be preferred.

Use salts when appropriate. Should note that integrity should be use a MAC (i.e., a keyed hash) and not a MIC (message integrity code). A MIC can be used as a keyed hash via

MIC(msg) = Secure_Hash( salt + msg )

but that is not as good as using something like HMAC-SHA1 or even better, HMAC-SHA256.

==== Rule - Store the Hash Value of Passwords ====

Store the hashed value of the password. Salt each hash. Use a different random salt for each password hash. Never store the clear text password or an encrypted version of the password.

==== Rule - Ensure That Random Numbers are Cryptographically Strong ====

Ensure that all random numbers, random file names, random GUIDs, and random strings are generated in a cryptographically strong fashion.

TODO: This probably could use further explanation especially how entropy used to seed PRNGs plays an important role as well.

=== Rule - Only Use Widely Accepted Implementations of Cryptographic Algorithms ===

Do not implement an existing cryptographic algorithm on your own, no matter how easy it appears. Use widely accepted algorithms and widely accepted implementations only. Ensure that an implementation has, at least, had some cryptography experts involved in its creation. If possible, use an implementation that is FIPS 140-2 certified.

==== Rule - Only Use Strong Cryptographic Cipher Modes ====

Use cryptographic cipher modes that offer both authenticity and confidentiality

ECB should almost unequivocally be avoided. If you use a cipher mode that treats a block cipher as a streaming mode, such as OFB or CFB, be careful you don't repeat the IV for the same encryption key. In general CBC is a decent cipher mode to use if message authenticity is not an issue and it a cipher mode that is almost always available. Better cipher modes are ones that offer
both authenticity and confidentiality such as those mentioned under the Wikipedia "Authenticated Encryption" article. See the "see also" section of <http://en.wikipedia.org/wiki/Authenticated_encryption> for a list of such cipher modes.

http://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet#Rule_-_Only_Support_Strong_Cryptographic_Ciphers

=== Rule - Ensure That Any Secret Key Is Protected From Unauthorized Access ===

=== Rule - Store unencrypted keys away from the encrypted data ===

If the keys are stored with the data then any compromise of the data will easily compromise the keys as well. Unencrypted keys should never reside on the same machine or cluster as the data.

=== Rule - Protect keys in a key vault ===

Ideally, keys should remain in a protected key vault at all times. In particular ensure that there is a gap between the threat vectors with direct access to the data and the threat vectors with direct access to the keys. This implies that keys should not be stored on the application or web server (assuming that application attackers are part of the relevant threat model).

=== Rule - Define a key lifecycle ===

The key lifecycle details the various states that a key will move through during its life. The lifecycle will specify when a key should no longer be used for encryption, when a key should no longer be used for decryption (these are not necessarily coincident), whether data must be rekeyed when a new key is introduced, and when a key should be removed from use all together.

=== Rule - Document concrete procedures for managing keys through the lifecycle ===

These procedures must be written down and the key custodians must be adequately trained.

=== Rule - Build Support For Changing Keys Periodically ===

Key rotation is a must as all good keys do come to an end either through expiration or revocation. So a developer will have to deal with rotating keys at some point -- better to have a system in place now rather than scrambling later. (From Bil Cory as a starting point).

=== Rule - Document concrete procedures to handle a key compromise ===

=== Rule - Follow Applicable Regulations On Use Of Cryptography ===

==== Rule - Under PCI Data Security Standard requirement 3, you must protect cardholder data ====

PCI DSS compliance is mandatory by 2008 for merchants and anyone else dealing with credit cards. Good practice is to never store unnecessary data.

= Related Articles =

OWASP - [[Testing for SSL-TLS (OWASP-CM-001)|Testing for SSL-TLS]], and OWASP [[Guide to Cryptography]]

OWASP – [http://www.owasp.org/index.php/ASVS Application Security Verification Standard (ASVS) – Communication Security Verification Requirements (V10)]

'''Other Articles in the OWASP Prevention Cheat Sheet Series'''

* [[XSS (Cross Site Scripting) Prevention Cheat Sheet]]
* [[Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet]]
* [[SQL Injection Prevention Cheat Sheet]]
* [[Transport Layer Protection Cheat Sheet]]

= Authors and Primary Editors =

Jim Manico - jim.manico[at]aspectsecurity.com

Kevin Wall - kevin.w.wall[at]gmail.com

[[Category:How_To]] [[Category:Cheatsheets]] [[Category:OWASP_Document]] [[Category:OWASP_Top_Ten_Project]]

Eugene

2008-03-19T17:01:33Z

Kkenan:

{| style="width: 80%; margin: 0 auto; border-collapse: collapse; background: #FBFBFB; border: 1px solid #aaa; border-left: 10px solid #000066;"
|-
| style="padding: 0.25em 0.25em;" align="center" valign="center" | '''Next Meeting'''
| style="padding: 0.25em 2em;" | Wednesday, March 26, 6:00pm-8:00pm Symantec, Vista Room See [[#Next_Meeting|below]] for more information.
|}

{{Chapter Template|chaptername=Eugene, Oregon|extra=The chapter leader is [[User:Kkenan|Kevin Kenan]]|mailinglistsite=http://lists.owasp.org/mailman/listinfo/owasp-eugene|emailarchives=http://lists.owasp.org/pipermail/owasp-eugene}}

== Next Meeting ==

6:00pm-8:00pm Wednesday, March 26 
Symantec, Vista Room 
555 International Way 
Springfield, OR 
[http://maps.google.com/maps?f=q&hl=en&geocode=&q=555+International+Way&sll=44.04988,-123.08892&sspn=0.29907,0.482712&ie=UTF8&ll=44.086599,-123.036243&spn=0.037361,0.060339&z=14 Google Maps] 

Defending Against Cross-Site Scripting 
Kevin Kenan, K2 Digital Defense

Cross-site scripting, a.k.a. XSS, leads the OWASP top ten and is perhaps
the most common vulnerability found on web sites today. It is a key
component of many phishing attacks and can allow an attacker to hijack
user sessions. This talk will demonstrate the different types of
cross-site scripting, explore how to find XSS vulnerabilities, and
discuss how to protect your site.

This meeting is free and open to all so please forward this message to your
colleagues who are interested in application security. You can read more
about OWASP at:

http://www.owasp.org

To join the Eugene Chapter, simply sign-up for the mailing list at:

https://lists.owasp.org/mailman/listinfo/owasp-eugene

[[Category:OWASP Chapter]]

Eugene

2008-03-19T00:46:49Z

Kkenan:

{| style="width: 80%; margin: 0 auto; border-collapse: collapse; background: #FBFBFB; border: 1px solid #aaa; border-left: 10px solid #000066;"
|-
| style="padding: 0.25em 0.25em;" align="center" valign="center" | '''Next Meeting'''
| style="padding: 0.25em 2em;" | Wednesday, March 26, 6:00pm-8:00pm Symantec, Vista Room See [[#Next_Meeting|below]] for more information.
|}

{{Chapter Template|chaptername=Eugene, Oregon|extra=The chapter leader is [[User:Kkenan|Kevin Kenan]]|mailinglistsite=http://lists.owasp.org/mailman/listinfo/owasp-eugene|emailarchives=http://lists.owasp.org/pipermail/owasp-eugene}}

== Next Meeting ==

6:00pm-8:00pm Wednesday, March 26 
Symantec, Vista Room 
555 International Way 
Springfield, OR 
[http://maps.google.com/maps?f=q&hl=en&geocode=&q=555+International+Way&sll=44.04988,-123.08892&sspn=0.29907,0.482712&ie=UTF8&ll=44.086599,-123.036243&spn=0.037361,0.060339&z=14 Google Maps] 

Defending Against Cross-Site Scripting 
Kevin Kenan, K2 Digital Defense

Cross-site scripting, a.k.a. XSS, leads the OWASP top ten and is perhaps
the most common vulnerability found on web sites today. It is a key
component of many phishing attacks and can allow an attacker to hijack
user sessions. This talk will demonstrate the different types of
cross-site scripting, explore how to find XSS vulnerabilities, and
discuss how to protect your site.

This meeting is open to all so please forward this message to your
colleagues who are interested in application security. You can read more
about OWASP at:

http://www.owasp.org

To join the Eugene Chapter, simply sign-up for the mailing list at:

https://lists.owasp.org/mailman/listinfo/owasp-eugene

[[Category:OWASP Chapter]]

Eugene

2008-03-19T00:45:57Z

2008-02-15T17:08:07Z

Kkenan:

Category:OWASP Books

2008-02-15T17:07:36Z

Kkenan:

Many OWASP projects have produced books regarding the project's subject. The books range from technical manuals to vulnerability catalogs to best practice guides. Readers may download PDFs of the books for free or they may purchase the actual physical books. The physical books are offered at cost and OWASP does not make a profit from their sale. The books are provided as part of OWASP's mission to make application security visible.

[[Image:OWASP_Books_logo.png|left|thumb|200px|Book logo]]
If a project features a book, then the project's main page will include a message box at the top of the page displaying the OWASP Books logo and links to download or purchase the book as well as view the entire catalog. The catalog of books is hosted at Lulu and may be viewed at [http://www.lulu.com/owasp http://www.lulu.com/owasp].

To browse the entire catalog of books,

Category:OWASP Books

2008-02-15T17:06:53Z

Kkenan:

Many OWASP projects have produced books regarding the project's subject. The books range from technical manuals to vulnerability catalogs to best practice guides. Readers may download PDFs of the books for free or they may purchase the actual physical books. The physical books are offered at cost and OWASP does not make a profit from their sale. The books are provided as part of OWASP's mission to make application security visible.

If a project features a book, then the project's main page will include a message box at the top of the page displaying the OWASP Books logo and links to download or purchase the book as well as view the entire catalog. The catalog of books is hosted at Lulu and may be viewed at [http://www.lulu.com/owasp].

To browse the entire catalog of books,

[[Image:OWASP_Books_logo.png|left|thumb|200px|Book logo]]