Forum Moderators: buckworks
If any CVC data was stored they are going to attract some huge card assocation fines because of course CVV2 can't be stored after authorization. It is one of the main tenants of PCI DSS compliance.
With phishing of course everyone knows that CVC data is a poor authentication tool for security but the card associations are very harshe about this storage!
Anyone reading stores the CVC delete them all immediately before something like this happens to you..
The file that the hacker made of about 2000 credit card details is doing the rounds and is from the time of the hack -- so at least 2 weeks ago (this is not a new hack). This may not be ALL the cards that have been compromised from the server however.
Because the hacker scum posted this credit card dump with a nasty README.TXT letter explaining that this is just done out of pure spitefulness and hatred for Webhosting Talk.
I have to say though that my sympathy is now becoming less for Troy and his team and the loss of business they will get for this because at least part of their system is in flagrent disregard for obvious common sense security standards (and of course the specifics of PCI DSS regardless of their PCI merchant level --be it 2 ,3 or 4).
Here is the format of the credit card details containing MySQL table that was dumped and has been doing the rounds (as a .rar) file:
CREATE TABLE `creditcard` (
`card_id` int(11) NOT NULL auto_increment,
`account_id` int(11) NOT NULL default '0',
`address_id` int(11) NOT NULL default '0',
`cardnumber` bigint(20) NOT NULL default '0',
`expdate` varchar(10) NOT NULL default '',
`cardcode` varchar(5) NOT NULL default '0', [This is the CVC!]
`issueingbank` varchar(50) NOT NULL default '',
`nameoncard` varchar(50) NOT NULL default '',
`status` enum('valid','removed','modified','fraud','chargeback','other') NOT NULL default 'valid',
`friendlyname` varchar(100) NOT NULL default '',
`admin_note_id` int(11) NOT NULL default '0',
`customer_note_id` int(11) NOT NULL default '0',
`creation_timestamp` bigint(20) NOT NULL default '0',
`creation_session_id` int(11) NOT NULL default '0',
`modify_timestamp` bigint(20) NOT NULL default '0',
`modify_session_id` int(11) NOT NULL default '0',
`removal_timestamp` bigint(20) NOT NULL default '0',
`removal_session_id` int(11) NOT NULL default '0',
PRIMARY KEY (`card_id`),
KEY `account_id` (`account_id`,`address_id`,`cardnumber`)
It is not just the CVC that is in PCI DSS (and common sense security) violation but that the card number is not stored hashed or encrypted.
If you need recurring billing you must NOT store the CVC but get a special terminal for recurring from your card processor.
I just looked at the mySQL database for one of our stores, and the CC and some other fields are all big long strings of random characters.
I would have thought that almost any online credit card system would have the database setup to encrypt any sensitive or private info.
Yes but it does seem not this subsystem of iNet interactive as it is all in the clear. It's a real train wreck for customer trust because they knew this 2 weeks ago but kept silent. Not the compromised credit cards but the storage as plaintext.
The other thing that came out from the hacker's spiteful README.TXT is the allegation (if true) which shows mainly I think that users are complacement about password changes. It could be this is just the most active users but I think it more likely reflects user complacency more than people not knowing about the troubles yet.
Well some did change [passwords], to be precise, 1348 users out of 200,000
The power that cybercriminals have in todays world to sow terror and fear and loss is on par with terrorists because we rely so much on information technologies in todays world.
And worse is that these hacker scum are "for profit" as well! Which means they steal as well as damage so losses are multiplied.
They didn't do it to profit but to take the company down and cause as much legal trouble as possible. The information they obtained could have been sold for a huge amount of money.
The more I see come out I am willing to bet a disgrunted former/present employee is responsible.
I would have thought that almost any online credit card system would have the database setup to encrypt any sensitive or private info.
or maybe the password to encrypt would be stored in a *.php file. ie. config.php or something. of course, it sounds like this attacker could have gotten access to that if he didn't already have access to it.
maybe the password the user logged in with could be used to encrypt the data. except how is the website going to know what the password is after you've logged in? you're not generally prompted for passwords after you've entered it in that first time round. oh - maybe we can save it unhashed in a sessions table! well, except that kinda defeats the point of hashing for users who are logged in.
long story short, any encryption that is done on saved cc's is going to be trivially easily thwarted and saved cc's are quite common.
Nobody here should take PCI lightly. If you are non-compliant, and you are hacked, it WILL force you into bankruptcy. The fines are extremely harsh; it's all pretty clear. If you don't want to manage this hassle, the the simplest answer is to not store the credit card details.
Zelnaga, there are methods to encrypt according to MD5 hash techniques
ways to obfuscate the code to make it more difficult to isolate the encryption key required to decrypt the stored data.
Nobody here should take PCI lightly.
how do you propose that be encrypted?
mcrypt [us3.php.net] offers one option.
Credit card info is hardly the only sensitive information be stored on web accessible servers. Understand how to encrypt is pretty important these days.
i know! how about WHT encrypt the encryption key! and then they can encrypt the key that they used to encrypt the encryption key and they can encrypt that key and so on and so forth to perpetuity! wheeee!
and where do you propose the key be stored? the database? the filesystem? that wouldn't have made a difference given that the attacker had access to both of those.
Outside the webroot, of course, but no security is infallible. Particularly true if an entire server has been compromised.
I had thought you were asking a legitimate question about encrypting a MySQL database field. Perhaps you are just looking to argue?
I had thought you were asking a legitimate question about encrypting a MySQL database field. Perhaps you are just looking to argue?
a lot of websites have the ability to save credit card info
If they are set up conscientiously, they don't unless they are using one of two approaches.
1. Most companies, including the ones I work with, never even see credit card info. They pass the data directly to a PCI compliant [pcicomplianceguide.org] gateway and allow the gateway to assume that liability. For recurring billing, they store only a unique token on the web site to pass to the gateway.
2. They fully pass PCI compliance. Understand that this is not limited to how you store the info in your database, it is a complete audit of your programming, the server security, and the network in which it's housed - even the physical location and access of the server. It's more than just encryption; encryption is only as secure as the network housing it. See the link above for more info.
Sites that don't do one of the two above are playing the game of chance . . . chance we'll never get caught, chance a catastrophe like this will never hit us. I am guessing by the information disclosed to this point, this company falls in this category.
All I'm saying is that PCI DSS regulations require that stored credit card details be done in encrypted fashion. Like it or not, its part of the requirements of becoming PCI compliant. The reason PCI compliance is important is that the credit card companies don't care about your or my opinions. All they care about is 'was this company compliant at the time of the hack?' If yes, you'll get off relatively easy. If no, they will put you out of business with their huge fines and penalties. Nobody said its fair, just like getting stuck with chargebacks that you can't really fight isn't fair. Once again, its an example of the e-commerce merchants getting stuck paying for problems that they didn't create because the big guys can do whatever they want. If anyone wants to store credit cards, PCI compliance is expensive but the best insurance you can get should the unfortunate situation like this ever arise. So, encrypt not because it keeps cardholders safe, but because it keeps YOU safe.
Any company with large pockets would NEVER think of storing those numbers UNLESS that was their core business.
Thankfully we don't store credit cards... makes me sleep more soundly at night!
Our second store is set to delete all CC and CVV/CVS info once the order is processed, that is probably the only really safe way unless you are using a remote processor.
Not even temporarily is safe. True, this presents a narrower avenue of attack, but it's still not safe, and still unacceptable (IMO, and probably as far as the card companies are concerned.)
Take port scanning (admins, jump in here, I have this info vicariously.) When you store CC info, even if it's encrypted, it has to be decrypted to be viewable. A port scan can capture info en route and get stored somewhere, to be culled over later. You won't even know what hit you, and may never know it's you. The client will if they review their bank statements closely.
Many server attacks don't hit the headlines. A crafty hacker does so silently. Once in, they can figure out how your system works, set something to quietly inform them of activity, and access the info for months or years without your knowledge.
You can get away with the last 4 digits only - encrypted, of course - so the customer can identify which card was used for a transaction. Anything else is like laying your arm on the butcher block and hoping the butcher is blind.
1. Most companies, including the ones I work with, never even see credit card info. They pass the data directly to a PCI compliant gateway and allow the gateway to assume that liability. For recurring billing, they store only a unique token on the web site to pass to the gateway.
someone, somewhere along the line, has to store the stuff unencrypted for it to be recalled and recharged.
one thing i'm curious about, though - when does the PCI DSS kick in? only if you store the full cc number? what if you store all but the first digit or all but the first two digits? what if you do encrypt it with a key in a file that's inaccessible from the web? certainly it seems that keeping track of some info is useful for each transaction even if you're not going to have the "store my info" feature. ie. a hash of the cc # so that you can search by cc #, maybe the last four digits, etc.
someone, somewhere along the line, has to store the stuff unencrypted for it to be recalled and recharged.
when does the PCI DSS kick in?
The easiest way to be compliant is, as rocknbil said, to not store the stuff on your server at all. Pass it direct to your gateway and let them deal with the storage. I don't know about other gateways, but Authorize.net has had a feature available for some months now where they will store your sensitive data for you for $20 a month, accessible by API only. Well worth it if you ask me. I have the info I need while completely outsourcing the storage risk.
certainly it seems that keeping track of some info is useful for each transaction
If you must store cc data searchably, you can do it, encrypted, on a hardened internal network that never sees the web. Just a thought.
I don't argue that the DSS are a real pain, esp for small-time businesses that do not have the resources to invest in fancy dedicated servers or security programmers. But there are cost-effective solutions, and basically, if you don't address PCI, you risk basically losing your business. The odds are slim but they are still there.
Take port scanning (admins, jump in here, I have this info vicariously.) When you store CC info, even if it's encrypted, it has to be decrypted to be viewable. A port scan can capture info en route and get stored somewhere, to be culled over later
I'd like to hear from one of the admin also on this. I was under the impression that if your viewing credit card data using SSL it would be encrypted for transmission over the internet connection? Would this not also be the case if a port is being scanned?
I recommend that clients use a third party processor but then we do run across those that are penny wise and pound foolish.
I'm from the Web Hosting Talk/iNET Interactive team and wanted to let all of you know the best place to get updates on the current events happening at Web Hosting Talk. We're working hard to resolve current issues and want to make sure everyone is informed of the latest updates and happenings.
To get the latest information and updates, visit the Forums Announcements board over at Web Hosting Talk.
Thanks!
