We have a web application running on Amazon AWS, which has recently been upgraded to PCI DSS Level 1 compliance. We want to take advantage of this and store credit card numbers on our host, but I'm having trouble finding any guidelines on best practices. In particular, what kind of encryption to use when storing the cards in the db, and what measures to take to keep the encryption key safe. Can anyone help?

In my view you should hash it, unless you want to retrieve the plain text number hashes would do it for you. if you do want to do encryption/decryption then you need you need infrastructure to store your keys securely (something that is dedicated for this task). I have seen some good implementation using SafeNet products for this, i am not their sales guys and hence you can do your own research on this for plus and minus. Changing your keys regularly and securely and still able to encrypt and decrypt your old data would be a good option. I have also seen and attended discussion where payment organizations are moving towards using ECC for encryption/decryption so you can see if it fits your requirement. Let me know what you get, I would also like to learn from your experience. - G On Sun, Feb 6, 2011 at 10:13 PM, Ed Bordin <edbordin@gmail.com> wrote: > We have a web application running on Amazon AWS, which has recently > been upgraded to PCI DSS Level 1 compliance. We want to take advantage > of this and store credit card numbers on our host, but I'm having > trouble finding any guidelines on best practices. In particular, what > kind of encryption to use when storing the cards in the db, and what > measures to take to keep the encryption key safe. Can anyone help? > > _______________________________________________ > The Web Security Mailing List > > WebSecurity RSS Feed > http://www.webappsec.org/rss/websecurity.rss > > Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA > > WASC on Twitter > http://twitter.com/wascupdates > > websecurity@lists.webappsec.org > http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org > -- Regards, Gautam

    Can you please clarify what you mean by a 'PCI DSS Level 1 

    Anyway, with regards to your question on storing PANs on your 

    However, if there is a legitimate business need to store then PAN, 

    Referring to the PCI DSS 1.2 Glossary of Terms, Abbreviations, and 

    In terms of key management, please refer to PCI DSS Requirements 

    Cheers!

    Pak-Tjun Chin

Hi Ed, Can you please clarify what you mean by a 'PCI DSS Level 1 compliance' on an application? Rather, are you referring to Amazon, as a Service Provider, is now a Level 1 Service provider, that is, according to Visa, they store, process and/or transmit more than 300,000 Visa accounts/transactions annually? Anyway, with regards to your question on storing PANs on your host, the fist question to ask is whether you have a legitimate business need to do so. More often than not, the surprising answer that comes back is 'no'. However, if there is a legitimate business need to store then PAN, PCI DSS requirement 3.4 states that you must render the PAN unreadable. For me personally, I would adopt the following approaches: Hashing or tokenization. If this approach is not feasible, then by Truncation. If this approach is not feasible, then by Encryption using strong cryptography. Referring to the PCI DSS 1.2 Glossary of Terms, Abbreviations, and Acronyms, 'strong cryptography' is defined 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). See NIST Special Publication 800-57 (http://csrc.nist.gov/publications/) for more information. In terms of key management, please refer to PCI DSS Requirements 3.5 and 3.6 for guidance. Cheers! Pak-Tjun Chin Ed Bordin <edbordin@gmail.com> Sent by: websecurity-bounces@lists.webappsec.org 07/02/2011 05:13 PM To websecurity@lists.webappsec.org cc Subject [WEB SECURITY] PCI DSS Level 1 - Guidelines for Storing Credit Card Details? We have a web application running on Amazon AWS, which has recently been upgraded to PCI DSS Level 1 compliance. We want to take advantage of this and store credit card numbers on our host, but I'm having trouble finding any guidelines on best practices. In particular, what kind of encryption to use when storing the cards in the db, and what measures to take to keep the encryption key safe. Can anyone help? _______________________________________________ The Web Security Mailing List WebSecurity RSS Feed http://www.webappsec.org/rss/websecurity.rss Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA WASC on Twitter http://twitter.com/wascupdates websecurity@lists.webappsec.org http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org The information contained in this email and its attachments may be confidential. If you have received this email in error, please notify the sender by return email, delete this email and destroy any copy. Any advice contained in this email has been prepared without taking into account your objectives, financial situation or needs. Before acting on any advice in this email, National Australia Bank Limited (NAB) recommends that you consider whether it is appropriate for your circumstances. If this email contains reference to any financial products, NAB recommends you consider the Product Disclosure Statement (PDS) or other disclosure document available from NAB, before making any decisions regarding any products. If this email contains any promotional content that you do not wish to receive, please reply to the original sender and write "Don't email promotional material" in the subject.