Page 20 of 20 FirstFirst ... 1017181920
Results 476 to 495 of 495
  1. #476
    Join Date
    May 2006
    Location
    NJ, USA
    Posts
    6,645
    Quote Originally Posted by jeev View Post
    you guys have some massive expectations.

    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.

    mistakes are made, for you to hope that all this hard work building the forum goes down the drain, i truly hope you get in a devastating car accident today.. i mean it. enjoy your life while you live, not PMS over something on like a FORUM, whether or not it was negligence.

    if you whack jobs blasted the bush whitehouse before the wars, we would've never been in this giant mess we call the "war on terror", with thousands of soldiers dead and a million iraqi's dead... frankly, some of those iraqi children missing fathers will eventually want to pay back the U.S. and i hope they come after the morons in here wishing death and destruction to WHT.

    another funny thing is some of you here have businesses and i guarantee you for the life of it, you are NOT pci compliant either. downloading credit card databases to your personal computer at home and all that mumbo jumbo, yea.. we all do it for records. so stop bitching

    enjoy.
    IMHO, he hit the nail right on the head.
    AS395558
      0 Not allowed!

  2. #477
    Join Date
    Jul 2005
    Location
    Belgium
    Posts
    507
    Quote Originally Posted by unity100 View Post
    this is like building an aircraft but not putting in the engine.
    You mean a glider?
    kept alive by vertaalbureau
      0 Not allowed!

  3. #478
    Join Date
    Oct 2003
    Location
    Scotland, UK
    Posts
    2,916
    Quote Originally Posted by jeev View Post
    you guys have some massive expectations.
    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.
    You could say the same thing about houses. You expect that they will get broken into. That doesn't mean you leave your door wide open or the key outside to make it easier.
    Alasdair
    Long time ex-host, ex-billing software owner/developer/support staff. Recent lurker.
      0 Not allowed!

  4. #479
    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 Not allowed!

  5. #480
    Join Date
    Nov 2003
    Location
    Amidst several dimensions
    Posts
    4,324
    Quote Originally Posted by jeev View Post
    mistakes are made,
    skipping to encrypt 9000 credit cards in an online database is not a 'mistake'. its gross negligence.
      0 Not allowed!

  6. #481
    Join Date
    Sep 2001
    Location
    Sunnyvale, CA
    Posts
    979
    Quote Originally Posted by VPSTech View Post
    Two things I am thankful for:
    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.
    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/blog
      0 Not allowed!

  7. #482
    Quote Originally Posted by Jeremy Johnstone View Post
    So if the private key is not on a machine with a network connection, how do they process the charges?
    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.
    I take it your business does not make an effort to protect customer payment information? Please inform me of what company you work for so I might avoid doing business there.

    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.
    Obviously it should have been encrypted. There are privacy laws mandating that it must be encrypted. Again, it's 2009 so anyone in the peanut gallery can say "it should have been encrypted" and they'll be 100% correct. I hope management in all organizations dealing with private information come to this realization sooner than later.
      0 Not allowed!

  8. #483
    Join Date
    Sep 2001
    Location
    Sunnyvale, CA
    Posts
    979
    Quote Originally Posted by VPSTech View Post
    I take it your business does not make an effort to protect customer payment information? Please inform me of what company you work for so I might avoid doing business there.
    Ok troll, glad to see you can join in too. I can assure you my employer has infinitely better security than your hosting company.

    Quote Originally Posted by VPSTech View Post
    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.
    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.


    Quote Originally Posted by VPSTech View Post
    There are privacy laws mandating that it must be encrypted.
    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/blog
      0 Not allowed!

  9. #484
    Join Date
    Sep 2001
    Location
    Sunnyvale, CA
    Posts
    979
    Quote Originally Posted by VPSTech View Post
    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.
    I will pay $100 if you can find more than 10 web hosts on this board (heck, maybe in the world) with more than 5,000 customers who follow the steps you list above for CC payment processing.

    -Jeremy
    Jeremy Johnstone
    Personal Blog: http://www.jeremyjohnstone.com/blog
      0 Not allowed!

  10. #485
    Quote Originally Posted by Jeremy Johnstone View Post
    Ok troll, glad to see you can join in too. I can assure you my employer has infinitely better security than your hosting company.
    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.
    You obviously don't understand how encryption works, then. If the data had been encrypted with the private key stored in a secure fashion, the hacker would have had nothing but gibberish to publish on the Internet.



    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.
    I wasn't referring to PCI DSS, though even PCI prohibits storing in clear text or storing CVV2 for that matter.
      0 Not allowed!

  11. #486
    Quote Originally Posted by Jeremy Johnstone View Post
    I will pay $100 if you can find more than 10 web hosts on this board (heck, maybe in the world) with more than 5,000 customers who follow the steps you list above for CC payment processing.

    -Jeremy
    I don't doubt there are many that are not in compliance. My intent in posting the "how-to" was to HELP those that want to avoid a future fiasco for their business. Don't take offense. Learn. Embrace. Prevent.
      0 Not allowed!

  12. #487
    Join Date
    Sep 2001
    Location
    Sunnyvale, CA
    Posts
    979
    Quote Originally Posted by VPSTech View Post
    I don't doubt there are many that are not in compliance. My intent in posting the "how-to" was to HELP those that want to avoid a future fiasco for their business. Don't take offense. Learn. Embrace. Prevent.
    Your "how-to" doesn't scale and isn't considered an industry best practice anywhere. I'm not taking offense, just shedding light on your <<snipped>>
    Last edited by anon-e-mouse; 04-12-2009 at 02:16 AM.
    Jeremy Johnstone
    Personal Blog: http://www.jeremyjohnstone.com/blog
      0 Not allowed!

  13. #488
    Join Date
    Sep 2001
    Location
    Sunnyvale, CA
    Posts
    979
    Quote Originally Posted by VPSTech View Post
    You obviously don't understand how encryption works, then.
    Oh yeah, that's right. As long as it's "encrypted" it's safe from ever being decrypted.


    Quote Originally Posted by VPSTech View Post
    I wasn't referring to PCI DSS, though even PCI prohibits storing in clear text or storing CVV2 for that matter.
    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/blog
      0 Not allowed!

  14. #489
    Join Date
    Sep 2001
    Location
    Sunnyvale, CA
    Posts
    979
    Quote Originally Posted by Jeremy Johnstone View Post
    Your "how-to" doesn't scale and isn't considered an industry best practice anywhere. I'm not taking offense, just shedding light on your ignorance.
    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/blog
      0 Not allowed!

  15. #490
    Join Date
    Nov 2003
    Location
    Amidst several dimensions
    Posts
    4,324
    Quote Originally Posted by Jeremy Johnstone View Post
    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.
    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 Not allowed!

  16. #491
    Join Date
    Nov 2003
    Location
    Amidst several dimensions
    Posts
    4,324
    Quote Originally Posted by Jeremy Johnstone View Post
    I will pay $100 if you can find more than 10 web hosts on this board (heck, maybe in the world) with more than 5,000 customers who follow the steps you list above for CC payment processing.

    -Jeremy
    you can find a lot. and not among the ones in 5000+ customer range either. any decent billing software provides strong encryption in easy to use manner. even kids can do it.
      0 Not allowed!

  17. #492
    Join Date
    Nov 2003
    Location
    Amidst several dimensions
    Posts
    4,324
    Quote Originally Posted by Jeremy Johnstone View Post
    Oh yeah, that's right. As long as it's "encrypted" it's safe from ever being decrypted.
    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 Not allowed!

  18. #493
    Join Date
    Oct 2003
    Location
    Scotland, UK
    Posts
    2,916
    Quote Originally Posted by unity100 View Post
    encryption will give everyone enough time to take measures before the numbers getting out, in the time it takes them to decrypt.
    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 Not allowed!

  19. #494
    Join Date
    Oct 2003
    Location
    The Netherlands
    Posts
    1,269
    Quote Originally Posted by sash View Post
    No, they all most certainly must eat themselves alive. And then pay us all for the rest of our precious lives restitution for this immense psychological trauma we've experienced. And also dig up our gardens. Forever. And trim the grass.
    Your terms are acceptable, start trimming
    (Sorry just trying to inject some humor.. everything has already been said so I'm not going to add anything to it)
      0 Not allowed!

  20. #495
    Join Date
    Jun 2001
    Location
    Kalamazoo
    Posts
    33,412
    Quote Originally Posted by Bvs[NL] View Post
    .. everything has already been said ...
    I agree. It's time we closed this thread and get back to the rest of the community.

    [/end thread]
    There is no best host. There is only the host that's best for you.
      0 Not allowed!

Page 20 of 20 FirstFirst ... 1017181920

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •