[WEB SECURITY] PCI DSS Level 1 - Guidelines for Storing Credit Card Details?

Pak.Tjun.Chin at nab.com.au Pak.Tjun.Chin at nab.com.au
Mon Feb 7 15:17:49 EST 2011


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 at gmail.com> 
Sent by: websecurity-bounces at lists.webappsec.org
07/02/2011 05:13 PM

To
websecurity at 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 at 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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/attachments/20110208/1219b81a/attachment.html>


More information about the websecurity mailing list