How to encrypt Credit Card numbers?

Question

How to encrypt Credit Card numbers?

Viewing 6 posts - 16 through 20 (of 20 total)

You must be logged in to reply to this topic. Login to reply

jcelko212 32090 SSCrazy Eights Points: 9294 More actions · Answer 1

BOR15K - Friday, September 8, 2017 10:17 AM
We have now finally moved all our customers to SQL 2014 from old or very old SQL versions and I have been given a task to enquire how to encrypt credit card numbers in the database.
Before I will start Google, thought to ask first people here what are the current approaches. Any suggestion will be much appreciated, as always
Thank you.

Is not a credit card industry standard for this?? And NEVER be so as to STUPID say "Before I will start Google.."; This just ended your care\er because anyone hires you, they will see this posting and know. Hackers now know to find the trace back to your posting address of your unprotected databases. It is always a bad, criminally bad, idea discuss security problems in a public forum.

Please post DDL and follow ANSI/ISO standards when asking for help.

Alan Burstein SSC Guru Points: 61136 More actions · Answer 2

NEVER be so as to STUPID say "Before I will start Google.."; This just ended your care\er because anyone hires you, they will see this posting and know.

Everyone uses Google. I USE GOOGLE, I USE GOOGLE, I USE GOOGLE. I'm sure the OP's career will be fine and so will mine Joe.

Hackers now know to find the trace back to your posting address of your unprotected databases.

It is always a bad, criminally bad, idea discuss security problems in a public forum.

God help us all.

"I cant stress enough the importance of switching from a sequential files mindset to set-based thinking. After you make the switch, you can spend your time tuning and optimizing your queries instead of maintaining lengthy, poor-performing code."

-- Itzik Ben-Gan 2001

Steve Jones - SSC Editor SSC Guru Points: 734498 More actions · Answer 3

I'll disagree on discussing potential solutions and issues. Security does not really depend on obscurity, but well know, practiced principles and then protecting specific implementations, like passwords, IPs, networking config, etc.

Google is a good way to learn, but for something like this, multiple people, including someone that has done the work, should sign off.

kevaburg SSCoach Points: 18131 More actions · Answer 4

Jack Corbett - Friday, September 8, 2017 12:38 PM
My recommendation is always to have the application handle encryption and decryption. If you use encryption builtin to SQL Server it makes it easier for people with access to the database to decrypt it.
I'd also be interesting in knowing why you are storing Credit Card information instead of using a service (there are few out there) to handle credit card transactions so you don't have to store that information.

If TDE is in use then yes, people with direct access to the database can access the "encrypted" data. If always-encrpyted is in use then that is no longer the case and it remains secure. If the application handles the data encryption on the application tier the data remains vulnerable in the database and I can't believe that can be acceptable.

Or have I misunderstood something here?

Jack Corbett SSC Guru Points: 184393 More actions · Answer 5

kevaburg - Monday, September 25, 2017 9:57 AM
Jack Corbett - Friday, September 8, 2017 12:38 PM
My recommendation is always to have the application handle encryption and decryption. If you use encryption builtin to SQL Server it makes it easier for people with access to the database to decrypt it.
I'd also be interesting in knowing why you are storing Credit Card information instead of using a service (there are few out there) to handle credit card transactions so you don't have to store that information.
If TDE is in use then yes, people with direct access to the database can access the "encrypted" data. If always-encrpyted is in use then that is no longer the case and it remains secure. If the application handles the data encryption on the application tier the data remains vulnerable in the database and I can't believe that can be acceptable.
Or have I misunderstood something here?

I think you misunderstood. For always-encrypted you need SQL Server 2016, an always-encrypted enabled driver, and to configure the application to use the driver, so the data is encrypted and decrypted by the driver and not SQL Server. With column-level encryption the encryption and decryption takes place within the database or can, so anyone with correct permissions and knowledge can run a query to see encrypted data because all the keys and functions live in SQL Server. If I don't have access to SQL Server 2016 and this post is in a 2014 forum, I prefer to have the application encrypt the data before sending it to SQL Server and then have the application decrypt the data when it receives it back from SQL Server. Then you have to use the application and/or have access to the application code and keys in order to decrypt it, not just proper access to SQL Server. So the data is only vulnerable while displayed on the user's screen in the application or when they write it down or put it in Excel. It is stored encrypted.

Jack Corbett
Consultant - Straight Path Solutions
Check out these links on how to get faster and more accurate answers:
Forum Etiquette: How to post data/code on a forum to get the best help
Need an Answer? Actually, No ... You Need a Question

Chris Harshman SSC-Forever Points: 42192 More actions · Answer 6

Steve Jones - SSC Editor - Wednesday, September 20, 2017 10:58 AM
If you want the app to be responsible, store the encrypted cc as a binary value and have the app manage the encryption/decryption with the .NET namespace. If you don't do this, then the CC is potentially being sent across the network to the app in an unencrypted fashion. That's often a violation of PCI requirements, hence my note.

this is a very key point, you need to consider encryption of data at rest (inside your database) and data in transit (over the network) whether that be in transit over your LAN between the DB and application server, or between the application server and your end users, in this case external businesses.