I was wondering whether anyone ever dealt with encryption that are visa
compliant with credit card numbers:

On 3.4 of this document
(http://usa.visa.com/download/business/accepting_visa/ops_risk_management/cisp_PCI_Data_Security_Standard.pdf)


It states the encryption:

One-way hashes (hashed indexes), such as SHA-1

- Truncation

- Index tokens and PADs, with the PADs being securely stored

- Strong cryptography, such as Triple-DES 128-bit or AES 256-bit with
associated key
management processes and procedures


1. One way hashes cannot be decrypted so this won't work

2. Triple DES works however we will need to encrypt SSN.  Triple DES
doesn't encrypt 2 values the same way, so we cannot use it as an
index key that we wanted to.  The decrypted value comes out the same
however the encrypted values are always different.  We can't do table
scans for a SSN look up.

3. Truncation - I have no idea

4. Index token or PAD seems like one way encryption and never can be
decrypted (not sure what this is for if it can't be decrypted)


So how do I get this to work?? It doesn't say RSA is compliant either.
If you think RSA is okay, where does it EXPLICITLY say that on this
document???

Show quoteHide quote

<dmalhotr2***@yahoo.com> wrote in message
Show quoteHide quoteQuestion - for what reason do you need to encrypt and decrypt credit card #s
and SSNs?  What kind of searches are you planning on doing that one-way
hashes won't work?  Are you planning on running reports on all SSNs that
begin with "990" for instance, or all credit card #s that start with "8096"?

All encryption methods (via SQL Server 2005 T-SQL) salt the encrypted data
with a random IV.  So no two encryptions of the same value should have the
same encrypted representation.  You can create a pseudo-index on SSN by
storing a hash of the SSN in one column and storing the encrypted version in
another column.  This will work for exact match searches (i.e., looking for
one exact SSN; WHERE ssn = 'xxx-xx-xxxx'), but not for range searches like
WHERE ssn < 'xxx-xx-xxxx'.  You can also use a MAC code as described here:
http://blogs.msdn.com/raulga/archive/2006/03/11/549754.aspx

You know, like the last 4 - 5 digits of the credit card.  Question:  do you
really absolutely have to store the entire credit card number?  Many
businesses store just the last 4 - 5 digits and an authorization code.

Hashes and so on are useful for specific exact searches.  For instance, if a
person calls in and you ask "what's your SSN?"  Then you type it in, hash
it, and search for the hashed value in the table.  No need to decrypt or
recover the plaintext of the stored SSN's.  Again, just have to ask, but do
you absolutely *need* to store the entire SSN?

Sorry, not going to review the document, but if they don't give RSA as an
option, then don't use RSA.

RSA is an asymmetric key algorithm - it is not meant for direct data
protection, so there is no point using it to protect SSNs.

Thanks

Show quoteHide quote

Maybe that's the exact reason why they didn't specify he could use RSA in
the implementation docs...

Regardless, if they didn't specify RSA as an option he shouldn't use it.

YW

Show quoteHide quote

lost sa password due to loss of employee
Backup using the proxy account in SQL2005
BCP genric error
Scripting db creation
Copy Sql Studio Output to Outlook in HTML? Grids to Excel? What gi