Legitimate reason to decrypt a credit card?

December 30, 2008 8:58 AM

Legitimate reason to decrypt a credit card?

I am trying to come up with a legitimate reason to decrypt a credit card from a database of customer information. I can't see why the customer would ask for that to be done, because obviously they have access to all their own credit card information.

Can anyone think of a legitimate reason for decrypting a customer's credit card?

posted by doomtop to computers & internet (44 comments total)

The physical card got stolen and now they need to cancel it...? I really don't know.
posted by Precision at 9:03 AM on December 30, 2008

To see how it works. But you better be careful using someones sensitive and private data. In this situation it's really hard to practice "see but not look" as in the case of email administration. I recommend exhausting all means of testing on bogus data before you do this.
posted by ezekieldas at 9:05 AM on December 30, 2008

What do you mean by "decrypt a credit card"? Do you mean there's a field in the order-database that has the credit card number in an encrypted form? Many home-built encryption ciphers are very easy to break, and are often just variations of a substitutions cipher; the ciphers used by commercial products are sometimes better, but not always. They could be trying to test how secure their system currently is with a real world "attack".
posted by nomisxid at 9:08 AM on December 30, 2008

It might help if I explain better. All the customer information is stored in a third party database. I am trying to convince the third party to give me the keys to the credit card encryption, so that I can move all of the customers into a different system and discontinue use of the current third party system. However, I don't want the third party to know this is why I want the key, so I need a legit cover story basically.
posted by doomtop at 9:11 AM on December 30, 2008

As a backup measure, in case something happens to the vendor?
posted by amtho at 9:16 AM on December 30, 2008

Most likely the credit card info has been encrypted one way. It cannot be decrypted. This is typically called a hash or one-way function. This is a much more secure way to store credit numbers and SS numbers. If you database is stolen tomorrow then you dont have to worry about someone being able to easily crack the codes.

Even if its done with reversible encryption, I cant think of any scenario where this would be justified. They can get all this info from their credit card company. In fact, how are you even authorizing this person? This could be a ID theft ploy.
posted by damn dirty ape at 9:20 AM on December 30, 2008

so that I can move all of the customers into a different system and discontinue use of the current third party system.

My understanding of e-commerce systems isnt great, but I think the idea here would be to replicate their one way hash in the new system, not try to turn the cipher into plain-text again. They should be able to give this to you. Heck it might just be MD5 or SHA-1. Have you tried those?
posted by damn dirty ape at 9:22 AM on December 30, 2008 [2 favorites has favorites]

DDA's assertion about hashes was the conventional wisdom, but today we see a practical example of engineering an md5 has collision.

Check your agreement with the third party, I'd be surprised if they don't have any language covering the termination of the contract. They may have already agreed to provide a data dump as part of the contract. Most businesses don't go around trashing data of soon-to-be-former-customers, partly out of bridge-burning-avoidance, partly to avoid the shit-storm of litigation you'd open yourself up to.
posted by nomisxid at 9:30 AM on December 30, 2008

i apologize for the derail, but why would you save a hashed cc number?
posted by phil at 9:46 AM on December 30, 2008 [2 favorites has favorites]

This is probably not allowed under your contract with the credit card companies, and is probably grounds for terminating your ability to take payments using those cards. In general, I don't think participating retailers are allowed to keep entire card numbers (as distinct from the last four digits); at the last large retailer where I contracted, I recall the db admin types talking about annual audits by tthe card companies to ensure compliance.
posted by orthogonality at 9:50 AM on December 30, 2008

I am not sure where the idea that we are a retailer came from, but we are a service provider. We store credit card information in order to process monthly recurring fees. I am pretty sure we are not doing anything illegal.
posted by doomtop at 9:57 AM on December 30, 2008

so that I can move all of the customers into a different system and discontinue use of the current third party system

Tell this to your vendor. Explain that you are planning on canceling their contract in X months, and need the data now to start the migration process. The vendor is much more likely to try to negotiate a deal that will allow them to continue doing business with you than to destroy the data.

This is probably not allowed under your contract with the credit card companies, and is probably grounds for terminating your ability to take payments using those cards. In general, I don't think participating retailers are allowed to keep entire card numbers (as distinct from the last four digits); at the last large retailer where I contracted, I recall the db admin types talking about annual audits by tthe card companies to ensure compliance.

There are definitely e-commerce sites that are PCI DSS compliant and store your full credit card information. PCI DSS compliance takes a lot of work, and may be a major burden to the poster's internal infrastructure. Failing PCI DSS is Not Good.
posted by b1tr0t at 9:58 AM on December 30, 2008 [2 favorites has favorites]

Um, those who think it's a one-way hash aren't thinking this through. The OP is obviously asking about a system which has stored credit card numbers for a subscription-based service. In these cases, a one-way hash would be incredibly useless, as Visa isn't about to take an MD5 hash. Instead, they'd use a basic crypt backed by a key that's necessary to reverse the card numbers, stored in separate places. This way, if the database was itself compromised, the CC numbers would be bogus without the key.

But a one-way hash? Come on, guys.

Honestly, OP, you might just be best off saying that you need to move to another solution. But, depending on TOS and other contracts, I probably wouldn't give you the CC information out. The liability risk is FAR too large for me to just give you the numbers, in plain text, from my database, even if you're the manager of the application. Call them and ask if they have any transition plans in place or how this is normally handled. But trying to come up with a cover story is going to raise suspicions on an already suspicious request. It might come down to you requesting your customers re-enter their billing information, which no one really wants to do.
posted by disillusioned at 9:59 AM on December 30, 2008 [1 favorite has favorites]

If you use the credit card info to process recurring fees, it seems that they must be able to get the credit card numbers back out of the system somehow (as opposed to just storing a hash). I agree with the people who recommend checking your contract for termination policies and then being up front with this vendor.
posted by vytae at 10:01 AM on December 30, 2008

No.

Whatever reason the customer has for wanting you to decrypt the number... it's outweighed by the need to defend against social engineering attacks, and by the principle of least privilege which entails that as few people/systems as possible have the ability to decrypt those numbers.

If the customer needs to know what credit card you have on file, he can have you delete the database entry and re-enter his credit card info.
posted by qxntpqbbbqxl at 10:06 AM on December 30, 2008

The liability risk is FAR too large for me to just give you the numbers, in plain text, from my database, even if you're the manager of the application.

This is a great point - you don't want those numbers going over the wire in plain text, and you certainly don't want them burned to a DVD or written to a disk for FedEx shipment in plain text.

This is a discussion that needs to happen between your two companies. You need to carefully plan this transition out. You can be certain that shortcuts will come back to bite you in the future.
posted by b1tr0t at 10:08 AM on December 30, 2008

We are not interested in negotiating any deal with the current vendor. The objective is to be able to get all of our customer billing information out of the existing system with as little hassle as possible. We are looking to do this soon and cannot afford to deal with a vendor who is unhappy that we are dropping their crappy service and decides to fight us on it.
posted by doomtop at 10:13 AM on December 30, 2008

Lawyer up
posted by b1tr0t at 10:25 AM on December 30, 2008

doomtop, perhaps you need to read the PCI DSS standard, or take their Online Compliance Questionnaire. Even if you convince the vendor to give you the credit card numbers, where are you going to store them? How are you going to transmit them from the vendor?

Are you complying with PCI DSS throughout that process? It's highly likely that you are not, which can be a very, very big problem waiting to happen. Business-destroying-big, I mean.
posted by odinsdream at 10:26 AM on December 30, 2008

Corrected link to online compliance:

Online Compliance Questionnaire
PCI DSS Homepage
posted by odinsdream at 10:29 AM on December 30, 2008

We are not interested in negotiating any deal with the current vendor.

Get interested. You expose yourself to so much liability that there is no possible way that manually transitioning the personal info is a smart idea. Even if this all goes perfectly (and when was the last time you saw an IT project do that?) you're glibly handling data that is tremendously valuable.

We are looking to do this soon and cannot afford to deal with a vendor who is unhappy that we are dropping their crappy service and decides to fight us on it.

Okay, so if they're the kind of company that would sabotage your data because you're leaving, what on earth makes you think that they're just going to hand you the data for some fabricated reason?

Further, it sounds like you're not asking for the data, but for a way to decrypt the data yourself: you are not going to get this information from anyone with even an inkling of sense.


Remove your head from your hind-quarters and go talk to your vendor about transitioning away from their system. The company (probably) isn't being run by teenagers -- they're losing your business. They can either lose it gracefully, or they can lose it in a way that would jeopardize getting any MORE business.

It sounds to me like you just don't want to tell the sales guy that you're breaking up with him.


Also: seconding the idea that saving a hash of CC number is stupid.
posted by toomuchpete at 10:36 AM on December 30, 2008 [3 favorites has favorites]

You're going to have to assume that there is no way to get this information through subterfuge. Given that, you have absolutely nothing to lose by approaching your current vendor about migrating to a new vendor. The worst that can happen is that you won't get their help and your users will need to re-enter their billing information. Which is where you are now. Talking to them will therefore not make things any worse and may make things better.
posted by kindall at 10:45 AM on December 30, 2008

Here's just one of the questions you need to be able to answer Yes to, if you want to store a customer's full card number (called the PAN, or Primary Account Number) and be considered PCI DSS compliant:

Is PAN, at a minimum, rendered unreadable anywhere it is stored (including data on portable digital media, backup media, and in logs,) by using any of the following approaches?

• One-way hashes based on strong cryptography
• Truncation
• Index tokens and pads (pads must be securely stored)
• Strong cryptography with associated key management processes and procedures.

The MINIMUM account information that must be rendered unreadable is the PAN.
If for some reason, a company is unable to render the PAN unreadable, refer to Appendix B: "Compensating Controls."
Note: "Strong Cryptography" is defined in the PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms.

posted by odinsdream at 10:50 AM on December 30, 2008

The data is not going to be stored in any unsecure, unencrypted way. I am not looking to decrypt and store this information plain text. I am looking simply to move it to a different database, where it will also be encrypted. It is not setup in a way where we could just take the hashes and use them with the new system. The decrypted version of the data will never be transmitted.
posted by doomtop at 11:01 AM on December 30, 2008

The objective is to be able to get all of our customer billing information out of the existing system with as little hassle as possible. We are looking to do this soon and cannot afford to deal with a vendor who is unhappy that we are dropping their crappy service and decides to fight us on it.

Can you afford to have the billing information stolen from one of your computers that you save the plaintext data onto, or for any of the various other very bad things that can happen if you don't follow the established security standards for things like this? Sometimes the cheap and risky option ends up being more expensive in the long run.
posted by burnmp3s at 11:02 AM on December 30, 2008

doomtop; between the part where you get the current vendor to give you the plain card number, and the part where you have your new system up and running... where are you going to store the card numbers?
posted by odinsdream at 11:19 AM on December 30, 2008

Please let me know what company you work for so I can never do business with you.

Seriously, you need to get the vendor on this and this kind of crazy cat and mouse game can only lead to disaster. Grow up, act like an adult, and pick up the phone.
posted by damn dirty ape at 11:25 AM on December 30, 2008 [1 favorite has favorites]

Frequently this kind of thing is covered in contracts at the time of signing. Look at your contract.
posted by chesty_a_arthur at 11:46 AM on December 30, 2008

We are looking to do this soon and cannot afford to deal with a vendor who is unhappy that we are dropping their crappy service and decides to fight us on it.

How about a vendor who gets duped by you, does what you want, gives you your credit card information, watches you obtain and transfer it in a noncompliant way, gets dropped by you, becomes unhappy at being involved by your company in interstate wire fraud, and takes you to the mat with the credit card companies for violating their data storage and transfer protocols?

Can you afford to deal with that?
posted by ikkyu2 at 11:47 AM on December 30, 2008

Hey, guys, it sounds like the question was perhaps not worded / focused well, but I don't think we need to be all condemning. Maybe doomtop doesn't want to "decrypt" as much as take control of the information somehow, whether it passes through his hands or not. It's natural for him to assume that decrypting would be a part of that.

The best people to talk to might be whoever your new service provider will be. They'll not only have an interest in helping you, they'll also be knowledgeable about this field. Or at least they should be.

If the current provider isn't behaving grossly unethically (it sounds like they might be either slightly unethical or else incompetent, since you're leaving them), then you'll want to be straightforward with them. If you start asking for keys to the information, or a big copy of the data, and there's just been some sort of incident in which you'd obviously be unhappy with their service, they're going to know something's up and that you might be trying to move away from them as a provider.

It's good ethics on your part not to mislead them or act "sneaky" in getting your information. Assuming they're not, as I said, grossly unethical themselves, just tell them the truth and they'll have an opportunity to behave well. If things have been difficult between you and them, they may be more than happy to help you move elsewhere. If you've got a lawyer's advice ready, you can bring that up if they start seeming reluctant.

Any new service provider you find will probably be a lot more comfortable working with you if you're not trying to trick the old service provider, and you should be more comfortable with the new guys if they're pro-always-telling-the-truth.

Again, I'm working on the basis that your old/current service provider is basically ethical. If not, you can still be straightforward with them, just have your velvet glove covering an iron, legally-reinforced fist.
posted by amtho at 12:05 PM on December 30, 2008 [2 favorites has favorites]

What does your original contract say?

It seems to me quite reasonable that you have an up to date record of the billing information for all your customers from a business continuity standpoint. What happens if your service provider goes out of business, or isn't up to date with their own BC planning? Blame your lawyers or investors or auditors or something.
posted by Good Brain at 12:36 PM on December 30, 2008

Wait... Tell me if I understand the situation correctly:

You want us to help you come up with a bullshit cover story that will let you dupe your current CC processing partner into giving you all of their credit card data?

Holy hell is that a Bad Idea. 2nding the "Who are you and how can I never do business with you." comments.

Here's the deal: You are responsible to your customers to not do something stupid and reckless with their data. However something stupid and reckless is exactly what you are proposing. Any subterfuge involving your customer data will not end well. Would you want someone else to do this with your credit card information? If you are honest, no, you would not. So don't do it.

The only reason you want to do this is because you are annoyed with your CC processor. This is not a good reason to start telling lies. It puts you in the wrong when there is no reason to. And when you're in the wrong on contracts you get nailed to the wall.

Simply behave like an adult. Tell them you're going elsewhere, tell them where, and tell them they have 30 days to get the data there. (Or whatever the terms of your contract termination are. You've read that, haven't you? That's exactly why they exist!) Anything else will get you into legal trouble. If they don't do it, it will get them into legal trouble.
posted by Ookseer at 1:26 PM on December 30, 2008 [1 favorite has favorites]

Seconding lawyer up.

All these seemingly harsh responses are simply trying to prevent you from doing something you will seriously regret later.

Unless your company is a thoroughly-audited, certified, PCI DSS-compliant entity, you Do Not Want a copy of your customers' data. There is no way for you to even momentarily take custody of this data safely.

The decrypted version of the data will never be transmitted.

Um, how is it going to get into a new system then? The new system will use an entirely new set of strong encryption keys, and so you'll have to enter the data from somewhere, and that somewhere will create temp files at a very minimum.

It's scary to think about the data being compromised, but that's not the point. The point is that if the credit card companies found out what you were doing, you're done. The End of Company.
posted by CaptApollo at 1:44 PM on December 30, 2008

From the responses you would think it is illegal to store credit card information and move that information from one system to another securely. Since I have no intention of transmitting or storing unencrypted credit card information at any time whatsoever, I am having trouble seeing why it is such an issue in this case.
posted by doomtop at 1:56 PM on December 30, 2008

I feel the need to clarify further because there is some obvious confusion in these responses.

We are not going to be doing anything with the data except for moving it from one billing system to another. In order for this to ever be possible, we will need to decrypt the data from the existing database (because it is encrypted for all the reasons everyone is bringing up). Then the data will be put in the new database where it will also be encrypted, more securely encrypted at that.

At no time during this process will the data ever be stored or transmitted in any unsecure way whatsoever. What we are looking to do is no different than calling each and every customer and getting their credit card info all over again, except that we already have all the information. Let me stress that this will be done in a secure and compliant way.

What we are trying to do is EXACTLY THE SAME as what is being recommended, except without the cooperation of our current vendor. How do you think they will get the data to our new vendor once they agree to do so? They are going to hand the new vendor the database and the encryption key so that they can get the information out of the old database and into the new database. They can't decrypt it themselves and then send the data PLAINTEXT to the new vendor, that is EXACTLY WHAT EVERYONE IS SAYING TO AVOID.

Normally we would just have the current vendor just deal with the new vendor, as is being recommend, which makes perfect sense, as contractually the current vendor will have to do this. However, due to the relationship we have had thus far with the current vendor, it is likely that they will start to cause problems/delays once they find out we are dumping their service. We'd like to avoid the expense, and more importantly the TIME, of the legal battle that would be required to force the current vendor to comply with the contract.

Since the current billing system DOES NOT WORK CORRECTLY, we would like to move our customers to the new billing system before the next billing cycle, which will allow us to continue billing our customers and continue to provide our customers the service they are enjoying. If this cannot be done in time, it may cause an interruption in our service and our customers will not be happy.

Since our current vendor SUCKS, I do not have an ethical concern with deceiving them into giving us access to OUR DATA THAT BELONGS TO US AND NOT THEM. If you think it is unethical, please feel free to not offer any advice in doing something that you feel is not ethical.
posted by doomtop at 2:19 PM on December 30, 2008

They are going to hand the new vendor the database and the encryption key so that they can get the information out of the old database and into the new database.

That makes sense. I think most people were assuming that you were going to use the key yourself when you said "so that I can move all of the customers into a different system." People are trying to make sure you're not doing the equivalent of taking tens of thousands of dollars out of a bank, putting it in the trunk of your car, and driving over to another bank.

As others have said, though, there really isn't any valid reason why you would need the encryption key to the database other than the real reason. You could say that you need to manually uncrypt a single record or small set of records for some made-up reason, but the vendor would probably rather decrypt them for you than give up the key. Another possible way to end up with the key would be to request that they re-encrypt the data with a new key of your choosing, but I can't think of any valid reason for doing that either.
posted by burnmp3s at 2:39 PM on December 30, 2008

Let me stress that this will be done in a secure and compliant way.

Let me see if I understand this correctly: you're coming to Metafilter for advice, and you want us to believe that you know your way around all of the relevant state and federal regulation in this area but can't come up with a clever enough excuse to make it happen?

Give me a break.

There is exactly zero difference between possessing the plaintext and possessing the encrypted database along with the encryption key. It's like writing the passcode to your car's keyless entry system on the window.

This needs to be handled by the vendors.

Again, what on earth makes you think that the vendor you're talking it would be willing to give you the encryption key for ANY reason? That, to me, sounds like a really great way to get one's company into a whole mess of trouble.


You asked for advice on how to accomplish something... the advice you got was "Holy crap that's a stupid idea!" Consider the possibility that this is not because you're being misunderstood but because you're actually embarking upon something monumentally stupid and your proximity to the situation is clouding your vision.
posted by toomuchpete at 4:29 PM on December 30, 2008 [1 favorite has favorites]

Considering how much trouble you're going to run into here - either by doing something fraudulent (fraud plus credit card numbers = very bad idea) or by dealing with a vendor who is so difficult you'd rather deceive them then negotiate with them...

It would cost very little (hire a few temps if you have to) to call all of your customers and ask for their payment information again.

Also, after reading your commentary about ethical concerns:

Please let me know what company you work for so I can never do business with you.
posted by mmoncur at 4:34 PM on December 30, 2008 [1 favorite has favorites]

Yeah, I think your approach is all wrong. In fact, I don't think you're even the person who should be doing this. Your VP of IT would be a better person to do the thinking, the planning, the talking to the vendors. Hopefully VP can get Old Vendor and New Vendor to work together to transition the data smoothly. (That's why VPs are paid big bucks.) Using the company lawyer only if necessary. And you can thank your lucky stars you are out of this loop!
posted by exphysicist345 at 4:44 PM on December 30, 2008

We are not trying to call you names, we are trying to help you keep from making a grave error.

You want us to help you lie to your vendor so they'll turn over your customer's credit card information.

Correct?

Yes. Correct. You've said this several times.

Our response: THIS IS A BAD IDEA!!!!

This is also correct. Very little misunderstanding here.

Read your contract that you have with this vendor. In it it clearly states how to get out of this. Just because talking to them is icky and makes you feel like a meanie is no reason to do something this monumentally dangerous.

Right now go and find the section in your contract that is titled "Termination" Read it, then call up your vendor and do exactly what it says there. If they don't like it, quote the contract back at 'em. Who cares if they don't like it? It's what happens all day every day in responsible businesses. Hell, maybe they will like it! Maybe they don't want you as a customer.
posted by Ookseer at 4:56 PM on December 30, 2008 [1 favorite has favorites]

Since our current vendor SUCKS, I do not have an ethical concern with deceiving them into giving us access to OUR DATA THAT BELONGS TO US AND NOT THEM.

One breach of contract does not justify another.
posted by b1tr0t at 7:13 PM on December 30, 2008 [2 favorites has favorites]

There is no way to do what you are asking to do and remain PCI DSS complaint. If you think there is, you are misunderstanding the situation. If your current vendor gave you an encrypted copy of the data, and the encryption keys, they would be failing their responsibility under PCI DSS to maintain control over the encryption keys involved. You fail to understand what is involved in the secure management of encryption keys.
posted by odinsdream at 7:55 PM on December 30, 2008

Ethical reasons aside, it is clear from the overwhelming response here that the way I am going about this is all wrong. It is definitely not my intention to put the data at risk in any way. The vendor I am working with is certainly PCI compliant. I think I have to go with what everyone is telling me and let the vendors work this one out. Hopefully it goes smoother than I expect.
posted by doomtop at 6:03 AM on December 31, 2008

Congratulations on making the right decision! Getting the vendors to work together may be difficult, but is the right decision for your customers, your company, and your other external partners.
posted by b1tr0t at 8:19 AM on December 31, 2008