Results 476 to 495 of 495
-
04-11-2009, 01:48 PM #476Rockin' the beer gut
- Join Date
- May 2006
- Location
- NJ, USA
- Posts
- 6,645
0
-
04-11-2009, 01:49 PM #477Web Hosting Evangelist
- Join Date
- Jul 2005
- Location
- Belgium
- Posts
- 507
kept alive by vertaalbureau0
-
04-11-2009, 03:14 PM #478Retired Moderator
- Join Date
- Oct 2003
- Location
- Scotland, UK
- Posts
- 2,916
Encrypting CC data and not storing a CVV is a massive expectation? Yikes.
i fully expect most websites that i deal with on a payment basis to have their database silently stolen. now, to think that somebody inside companies like TARGET and other public companies like that is NOT stealing the same information and passing it on to fraudsters is plain stupidity.
DONT GET THE PLASTIC IF YOU CANT HANDLE THE CONSEQUENCES.Alasdair
Long time ex-host, ex-billing software owner/developer/support staff. Recent lurker.0
-
04-11-2009, 04:05 PM #479New Member
- Join Date
- Apr 2009
- Posts
- 4
Two things I am thankful for:
1) I was not a customer of WHT
2) WHT did not require it's customers to submit scans of its drivers licenses, credit cards, utility bills, etc. before obtaining services.
I have found this thread to be one of the most useful ones on WHT. By reading the responses, I can easily identify the service providers that consider the security and privacy of their customers important and which ones are nonchalant about such issues. It will be invaluable when I make purchasing decisions for myself and my clients.
For people that are not of the technical mindset, the present year is 2009. Public key cryptography is trivial to implement, use and maintain. Storing any form of confidential information in an unencrypted state or storing the private keys on a system accessible via a network is sheer incompetence.
What's done is done, but it should have never happened. Learn from this and make sure your systems are setup securely.0
-
04-11-2009, 04:30 PM #480Disabled
- Join Date
- Nov 2003
- Location
- Amidst several dimensions
- Posts
- 4,324
0
-
04-11-2009, 10:11 PM #481Web Hosting Master
- Join Date
- Sep 2001
- Location
- Sunnyvale, CA
- Posts
- 979
So if the private key is not on a machine with a network connection, how do they process the charges?
I guess every single CC provider (let alone merchant) on the planet is incompetent in your mind because at some point, the machine running the charge has to be connected to some network to run the actual charge.
I'm not saying it shouldn't have been encrypted (and not saved in the other case), it's just it's easy to sit in the peanut gallery and make snide remarks. We all do it at some point in our life, glad to see you're not an exception.Last edited by Jeremy Johnstone; 04-11-2009 at 10:25 PM.
Jeremy Johnstone
Personal Blog: http://www.jeremyjohnstone.com/blog0
-
04-12-2009, 12:13 AM #482New Member
- Join Date
- Apr 2009
- Posts
- 4
First of all, this discussion only applies if the business is *storing* customer CC information.
If your business requires a customer's CVV2 code to complete a transaction, you have absolutely no choice but to process the order in *real-time* because you are not legally permitted to store the CVV2 value (encrypted or otherwise). This also means you cannot have "auto-billing" setup, because the customer is required to provide his/her CCV2 value for EVERY purchase. If they get sick of entering this value every month, they need to change their billing cycle to quarterly, semi-annually, yearly, etc. Many companies will store the CC information (without the CVV2 value) in an encrypted state for their records.
If your business does not require CVV2 to complete a transaction, it is still recommended to process the order in *real-time* (i.e. don't store the information, just securely transmit it to your payment gateway for processing). However, for subsequent billings, or autobilling, you may choose to store the encrypted CC details (no CVV2!) in your database. In this case, when you do billing you export the encrypted payment details (for accounts to be billed) and transfer this data to a removable storage media (like a USB flash drive).
The private key should be stored in a physically secure environment (bank safety deposit box, your company's vault, etc.) and protected by a pass-phrase. Private keys are also often stored on removable media like a flash drives. You take the flash drive with the encrypted CC data and copy it to a secure machine (patched, AV in place, etc.) that is not on any network. You then use your payment gateway software to decode the contents of the exported, encrypted CC data on the flash drive (using the private key (from the other flash memory drive) and your secret pass phrase) into secure memory. Securely wipe the flash drive that contained the encrypted export contents. Instruct your payment gateway software to re-encrypt the data using a one-time-use symmetric key. This produces an encrypted binary file that you copy to the flash drive that was securely deleted. Secure the flash drive with your private key back to your vault, and move the flash drive with the encrypted binary file to a computer connected to the Internet that also has a copy of your payment gateway software. Import the contents of the flash drive, providing the one-time-use decryption key. This will cause the contents to be decrypted into secure memory. The payment processing software will then use an encrypted Internet connection to process the order. After it is done, securely wipe the USB Flash memory device and store it somewhere safe for future use.
At no point in this process is confidential information ever left in the clear. It is protected.
I guess every single CC provider (let alone merchant) on the planet is incompetent in your mind because at some point, the machine running the charge has to be connected to some network to run the actual charge.
Many businesses do comply with the regulations. As I said, this is 2009 and PKI is not a new technology. We've known for years what happens when data isn't protected. There is no excuse for not protecting it.
I'm not saying it shouldn't have been encrypted (and not saved in the other case), it's just it's easy to sit in the peanut gallery and make snide remarks. We all do it at some point in our life, glad to see you're not an exception.0
-
04-12-2009, 12:26 AM #483Web Hosting Master
- Join Date
- Sep 2001
- Location
- Sunnyvale, CA
- Posts
- 979
Ok troll, glad to see you can join in too. I can assure you my employer has infinitely better security than your hosting company.
Never once did I defend their mistake. I am simply stating that encryption wouldn't have fixed this problem, only made it harder for the attacker to exploit the information.
Please do not misconstrue policies with laws. They aren't one and the same. PCI DSS is not a law (as you would have learned just reading the FAQ about it, let alone actually understanding it's terms and conditions in their entirety), just the regulation which all merchant providers are required to follow to continue running CC transactions.Jeremy Johnstone
Personal Blog: http://www.jeremyjohnstone.com/blog0
-
04-12-2009, 12:32 AM #484Web Hosting Master
- Join Date
- Sep 2001
- Location
- Sunnyvale, CA
- Posts
- 979
Jeremy Johnstone
Personal Blog: http://www.jeremyjohnstone.com/blog0
-
04-12-2009, 12:38 AM #485New Member
- Join Date
- Apr 2009
- Posts
- 4
I don't work for a hosting company, so your statement is true by default.
Never once did I defend their mistake. I am simply stating that encryption wouldn't have fixed this problem, only made it harder for the attacker to exploit the information.
Please do not misconstrue policies with laws. They aren't one and the same. PCI DSS is not a law (as you would have learned just reading the FAQ about it, let alone actually understanding it's terms and conditions in their entirety), just the regulation which all merchant providers are required to follow to continue running CC transactions.0
-
04-12-2009, 12:40 AM #486New Member
- Join Date
- Apr 2009
- Posts
- 4
0
-
04-12-2009, 12:45 AM #487Web Hosting Master
- Join Date
- Sep 2001
- Location
- Sunnyvale, CA
- Posts
- 979
Last edited by anon-e-mouse; 04-12-2009 at 02:16 AM.
Jeremy Johnstone
Personal Blog: http://www.jeremyjohnstone.com/blog0
-
04-12-2009, 12:53 AM #488Web Hosting Master
- Join Date
- Sep 2001
- Location
- Sunnyvale, CA
- Posts
- 979
Oh yeah, that's right. As long as it's "encrypted" it's safe from ever being decrypted.
Again, I never disputed that it was against PCI DSS policy and it definitely should be. In fact, there should be laws against storing CC information in clear text and/or keeping the CVV2 code too. Sadly, that isn't the case EXCEPT in Minnesota and that's ONLY if you are a moderately high volume merchant (aka over 20k transactions/year). iNET might be doing greater than that, but we don't know that for sure so claiming it's illegal is a bit of a misnomer, but again, IANAL.Jeremy Johnstone
Personal Blog: http://www.jeremyjohnstone.com/blog0
-
04-12-2009, 02:28 AM #489Web Hosting Master
- Join Date
- Sep 2001
- Location
- Sunnyvale, CA
- Posts
- 979
Realized I am simply being a troll too attacking you back. So here's a better response:
Problem
--------
You need the ability store credit card numbers in a way which is decryptable (thus excluding one way hash algorithms like SHA-1) so users can make purchases using that stored number without re-entering card information and have real-time processing of those transactions.
iNET solution under previous ownership (broken)
---------------------------------------
Store the credit cards in plain text in the DB. In iNET's defense, the original decision was made back in 2003 before it was a regulation, but still not a good solution even then. Why was it done then? Business reasons which likely won't be discussed publicly. Why was it not fixed in the past six years, and especially since it became a major regulation? Again doubt we will know. How did they pass PCI certification (if in fact they did)? They would be foolish to tell us I'm sure their lawyers will advise them.
Proposed Solution #1 (broken)
-------------------------
Simply follow PCI DSS and encrypt the card number. This of course meets regulations, but in fact is itself also not really secure. The problem is that DSS allows the decryption key to be stored on a webserver. Since obviously this webserver could be attacked if the DB could be attacked too, this would be the attacker could have the ability to decrypt the DB if the webserver could despite the owner getting the proper security audits and meeting the terms of DSS. Yes, you have quarterly security audits, but that doesn't mean some brilliant hacker won't find a way. This obviously wouldn't have prevented the attack on WHT either, because if they could get to iNET's firewalled DB server, they obviously could have had webserver access too.
Proposed Solution #2 (also broken)
----------------------------
Let me try and say I get this right. First you collect the CC# on the webserver and then encrypt it using a public key. This is then stored. Some other process (manual of course, since the machine can't be net connected allowing automation) pulls these CC numbers from a DB and stores them on a USB stick. This USB stick is returned to a safety deposit box or company vault when not in use. Through some other secure channel, this data is then later transmitted to the merchant processor. Ignoring the fact this doesn't allow real-time transactions. Further ignoring the lack of true security despite the complication of this. Can anyone imagine this to be a scalable solution (even at small company sizes)?
Real Solution -- in-house (still not 100% fool proof)
-----------------------------------------
1.) Encrypt all CC #s immediately using a strong public key even before storing. Basically encrypt it the second you receive the variable in webserver memory.
2.) All CC charges would be written to a database of some sort providing the encrypted card #, encrypted exp date using different public key(might as well be extra safe), and charge amount.
3.) Have a machine which sits in a secured environment (potentially locally in your office if that's secure) which has an out-of-band connection to the DB server (maybe via dialup, maybe dedicated line, maybe just VPN) and obviously not internet accessible in any way. This machine polls the DB looking for pending charges, decrypts the info, runs the charge, and updates with authorization or failure info.
4.) Since there is no access point from the webservers to access the machine with the private key, the customer is using one of the best (not the best, but one of) real-time (mostly) secured card processors.
Interestingly, this solution was proposed back at the time iNET's system was built in 2003, but again we will likely never know publicly the full details on why it wasn't implemented that way.
Real Solution -- 3rd party (still not 100% fool proof)
-----------------------------------------
1.) Collect all non-CC related info from customer
2.) For the payment page, redirect securely to a 3rd party payment provider. Have them collect all payment information. In the case of recurring payments, have some secure method for you to rerun the card without you ever needing the info directly.
This obviously is "secure" to you as you never have the info and thus absolves you of responsibility. It really isn't necessarily more safe for the user, as the 3rd party builds their own systems, but it absolves you of most (IANAL, so can't say all) responsibility if something happens.
It sounds like this is the approach iNET is taking and we should all applaud them (after spitting at them for taking so long to fix it and only after having compromised us, myself included as my old CC # was exposed too) for finally taking a step to providing us better security (which we should have had to begin with, but C'est La Vie).
Anyway, this thread has rubbed me the wrong way (as do most rant threads here it seems) and I am now returning to my enjoyable life ignoring WHT. No offense to the good guys here, just there is enough crap to not overcome the positive for me (as I am not interested in hosting anymore, YMMV).Jeremy Johnstone
Personal Blog: http://www.jeremyjohnstone.com/blog0
-
04-12-2009, 07:57 AM #490Disabled
- Join Date
- Nov 2003
- Location
- Amidst several dimensions
- Posts
- 4,324
thats ridiculous. i do not think that you are not technically affluent enough to realize that copy/pasting a private key from a removable device just at the time of the credit card processing will minimize the chances of key being found out, except in cases of network snooping.
Last edited by unity100; 04-12-2009 at 08:03 AM.
0
-
04-12-2009, 07:58 AM #491Disabled
- Join Date
- Nov 2003
- Location
- Amidst several dimensions
- Posts
- 4,324
0
-
04-12-2009, 08:02 AM #492Disabled
- Join Date
- Nov 2003
- Location
- Amidst several dimensions
- Posts
- 4,324
that is a snide remark. its also rather bullsh@t.
with your logic, it doesnt matter much whether we encrypt anything or not, because a rogue meteorite can strike earth anytime and can end civilization. then there's also global warming.
'can be decrypted' does not mean that it doesnt make GREAT difference when credit cards are encrypted with a strong key and encryption. even if the hackers employ server farms to run decryption schemes, encryption will give everyone enough time to take measures before the numbers getting out, in the time it takes them to decrypt.0
-
04-12-2009, 08:30 AM #493Retired Moderator
- Join Date
- Oct 2003
- Location
- Scotland, UK
- Posts
- 2,916
Not in the case of WHT If, as WHT claims, the CC details were taken at the same time as the initial breach, then iNET/WHT were quite happy to state that no CC details had been compromised. It was only when the details were released and widely avaialble that anyone noticed and we were told.
Ultimately there is no perfect solution that'll be accepted by everyone (except really passing the buck and responsibility to a payment processor!).Alasdair
Long time ex-host, ex-billing software owner/developer/support staff. Recent lurker.0
-
04-12-2009, 11:04 AM #494Web Hosting Master
- Join Date
- Oct 2003
- Location
- The Netherlands
- Posts
- 1,269
0
-
04-12-2009, 11:46 AM #495Dennis Johnson
- Join Date
- Jun 2001
- Location
- Kalamazoo
- Posts
- 33,412
0