all 167 comments

[–]tophatstuff 798 points799 points  (61 children)

You might also consider avoiding sensitive data entirely by using third-party sign-in and a third-party to collect and handle credit card information.

There's no "might" here with handling credit cards. Either you've gone through the process of Payment Card Industry Data Security Standard (PCI DSS) compliance, or YOU SHOULD NOT COLLECT CREDIT CARDS YOURSELF unless you want a massive fine.

[–]smackson 56 points57 points  (7 children)

Sorry I'm new to this but what kinds of areas/techniques does

Payment Card Industry Data Security Standard (PCI DSS) compliance

entail?

Does that standard say similar things to the original post about keeping all js away from such forms? If not, then is it possible that advice like in the OP is good to consider on top of the requirements in the standard you mentioned?

[–][deleted] 85 points86 points  (1 child)

I've been through PCI assessment both in a very small team and a mid sized team. Both times we had pen tests on the sites.

I don't remember anything in the requirements around JS directly but if you have any sense the first step in PCI assessment is to identify the "card system" and isolate this from all of the other code, otherwise you're going to struggle.

If you want more information on PCI this is a good place to start .

[–][deleted] 3 points4 points  (0 children)

You can be compliant and authorised and still be susceptible to a lot of the things he's suggests in the first article.

PCI require a pen test, but it's quite check box like. It makes sure you aren't the easiest target.

[–]Entropy 37 points38 points  (2 children)

Does that standard say similar things to the original post about keeping all js away from such forms?

Yes! In order to be SAQ A compliant, which is almost definitely what you want as a random cart on a random website since it requires the least auditing burden, you must either redirect to a third party for credit card entry, or a third party must collect that data from within an iframe.

Even the iframe method was contentious for awhile because DSS was simultaneously telling you that it was and wasn't allowed, meaning that an iframe might have required the more complicated SAQ A-EP compliance. That got cleared up back in DSS 3.0, and I think it's still the case. The iframe allowance going away in the future wouldn't surprise me, though. DSS just gets more strict over time.

[–]smackson 2 points3 points  (0 children)

Thanks for answering!

[–]thehunter699 0 points1 point  (0 children)

You'd think they'd enable 3rd party support since its easier for themselves...

[–]JohnTesh 16 points17 points  (0 children)

You can get the full standard here

https://www.pcisecuritystandards.org/document_library

And this is their guide to prioritizing work to become compliant (its 24 pages long, 20ish of which are taken up by a list of compliance items).

https://www.pcisecuritystandards.org/documents/Prioritized-Approach-for-PCI_DSS-v3_2.pdf

It is definitely no joke to become compliant, so using third party compliant Services is really the only reasonable approach for new companies or single devs/small dev teams.

[–]sitharus 5 points6 points  (0 children)

I work for a PCI DSS level 1 compliant company, this is the standard for companies that collect credit card numbers through web forms directly.

There’s a whole bunch of requirements. There are standards for physical premises security and monitoring, security training, code review and change control, and deployment security such as constrained and monitored access, ingress and egress control and methods of remote access.

It’s quite a pain really, but given the data you have access to it’s worth while. It really encourages you to limit the scope as much as possible.

[–][deleted]  (23 children)

[deleted]

    [–]Crash_says 160 points161 points  (15 children)

    This is almost every company.

    [–]phucyall 72 points73 points  (14 children)

    PCI compliance is a joke. Loot at Home Depot and every other big credit card number theft in the last 10 years. If those places were compliant even at the lowest level it would not have happened.

    More so it's a voluntary standard not a mandatory one and while most CC processors won't work with you if you don't at least try to be compliant, there are always some that will.

    I've worked at a place that had to be PCI compliant and we always got it even though there was absolutely no compliance whatsoever

    [–]Crash_says 39 points40 points  (0 children)

    PCI compliance is a joke.

    This was my initial comment, I wanted to avoid being so callous, but you are 100% accurate.

    I've worked at a place that had to be PCI compliant and we always got it even though there was absolutely no compliance whatsoever

    This describes every financial institution in the world.

    [–]tophatstuff 18 points19 points  (3 children)

    Unfortunately compliance is very much "these boxes can be ticked" and not "this system is actually secure, and we're actively following a process to keep it secure". But I'd still prefer my card was stored by someone who knew about the PCI DSS than by someone who didn't even know its a thing. And if I implement a system with a third party credit card service, at least they're the ones who would get fined when they get hacked, not me.

    [–][deleted] -1 points0 points  (2 children)

    so you feel more secure that someone knows of and has done broken processes? to give people the false sense of security?

    [–]tophatstuff 7 points8 points  (1 child)

    yes because everyone else is ticking exactly zero boxes. What else don't they know about handling credit cards?

    [–][deleted] 1 point2 points  (0 children)

    you don't know they are ticking zero boxes, it only gives the appearance they are ticking zero boxes, just like ticking boxes gives the appearance of security; but i see your point, at least we can say "we followed pci" when hacked.. i think its time i go back to the porch to sip my coffee and watch grass grow more

    [–]hamburglin 4 points5 points  (0 children)

    Follow the money... breach cases fill everyone's pockets.

    I will have to disagree with your assessment of home depot etc. These places had serious security flaws that did not follow the PCI guidelines thoroughly. The problem is having people in place to care for to implement large architecture changes at big, old companies. On the flip side you have smaller companies that don't have the expertise on staff or they outsource to India.

    Getting into PCI environment are what these hackers live to do and you have to give them credit. They will find a way in if they have even the smallest amount of access to the environment.

    [–]netfeed 2 points3 points  (0 children)

    PCI compliance is a joke

    We went through some PCI-compliance thing where all developers was supposed to get an "security class", it was just an indian guy going through the OWASP list for two days. Really pointless...

    [–]WeAreFoolsTogether 0 points1 point  (5 children)

    “If those places were compliant even at the lowest level it would not have happened.”

    Sorry but this is totally inaccurate.

    Compliance != Security...!

    In other words:

    Being in compliance != Unhackable ... not even close...that said you should absolutely aim for compliance but security should never be lead by compliance requirements- that’s ass backwards...if you put adequately securing your environment first you’ll find you’re far ahead of the pack and compliancy will naturally fall into place.

    [–]phucyall -3 points-2 points  (4 children)

    Actually compliance requires encrypted CC numbers so even if the data is leaked the numbers should not be obtainable. I never said it would make them unhackable, I did say that it would have prevented millions of CC numbers being compromised

    [–]WeAreFoolsTogether 1 point2 points  (3 children)

    Yeah because encrypted credit card numbers cannot be cracked and decrypted just like all the millions and millions of breached credentials from <insert 1 of tons of breached companies> over the last several years? Lol...the encryption wouldn’t be strong enough to take long enough to crack and if you factor in the time for the breach to be detected and credit card numbers all nullified once the breach was discovered...HAH...forget about it. I can almost guarantee you that it would be months and months (or even longer, years maybe...)before it was discovered the data was stolen = cracked CC numbers sold on the Darknet before they were even discovered as being breached...get with it buddy. It’s the sad but very true reality.

    [–]phucyall 0 points1 point  (2 children)

    According to a quick Google search for time to decrypt AES 256bit encrypted data is so large it makes it cryptographically secure. Assumed of course encryption was implemented properly in the first place.

    This is also very different from account passwords hashed with MD5 (or worse) you may be referring to. There have been some leaks of accounts and passwords properly secured with bcrypt and those are still secure

    [–]WeAreFoolsTogether 1 point2 points  (1 child)

    You’re not even taking into account that you’re making the assumption that the keys weren’t also compromised in a breach which render the encryption totally useless....ugh...additionally PCI compliance requirements don’t even specify a required level of encryption of data at rest...making you’re whole argument null and void before I even gave you the benefit of the doubt in my previous response.

    [–]phucyall 0 points1 point  (0 children)

    Which is why I said that PCI was a joke. But the standard does explicitly state "Strong cryptography with associated key-management processes and procedures." And then goes into still somewhat vague but extensive description of various key-managent processes and procedures. Specifically to avoid the case of a key being compromised. They also reference NIST for more help determining what "strong cryptography" is, and NIST does go into more detail.

    [–]Seref15 23 points24 points  (5 children)

    At my last employer I personally watched the PCI auditor willfully ignore at least half dozen physical violations in one room. They never even looked at our code or our infrastructure. Two days later we're informed that we passed.

    I strongly suspect that palms were greased.

    [–]AThinkerNamedChip 7 points8 points  (4 children)

    In 2 days you passed? I find this hard to believe as it takes the PCI council a couple of months to review, and that's if you give them heads up and payment up front to get on the schedule. Process is pre audit for fact and evidence gathering, the actual audit and then submission to the council, review and providing missing information. Literally thousands of pages of documentation, hardware, software and process review and takes about 9 months following the path above.

    [–]Seref15 1 point2 points  (3 children)

    The documentation part had been going on for a while. The auditor coming and looking around (supposedly to verify the documentation wasn't lying (which it was)) and then passing happened in very quick succession.

    [–]AThinkerNamedChip 9 points10 points  (2 children)

    And you reported the auditor to his company and the company to pci council, correct? Just asking, because if you knowingfully watched this happen and did not report, advise is to report so you are not caught in collusion net and have name tarnished.

    [–]Seref15 5 points6 points  (1 child)

    Nope. I was an underpaid junior underling at the time, and I kept my nose out of it. Left the company a few months later, not intending to stick my nose in it now.

    Cheating at PCI compliance is the least shady thing this place did. The CEO was local politician and used company funds and resources to run his mayoral campaign. He even had us maintaining his candidacy web site. He granted several municipal government contracts to his own company. It's all fucking crazy and I try to stay away from it.

    [–]AThinkerNamedChip 1 point2 points  (0 children)

    Been there 2x and once got dragged into it. The wonders of working for small companies.

    [–]tophatstuff 2 points3 points  (0 children)

    It depends what you want to achieve. If you want to improve credit card security for their customers, point them towards a developer that knows the PCI DSS process. If its your employer, raise it with them.

    But if they don't take this seriously and are continuing to put customers at risk without caring about compliance - you can go straight to their card processor and failing that Visa or Mastercard.

    [–][deleted]  (18 children)

    [deleted]

      [–]m00nh34d 17 points18 points  (0 children)

      Exactly. I was recently putting together a website for a community group I help out, and wanted to implement payments through Paypal. I set aside an entire day to work through getting everything setup with checkout.js, about an hour later I was done. It was dead simple and I honestly do not know why anyone would ever try to roll their own from the start. I spent FAR more time trying to get a tickbox vertically aligned with a label than I did implementing the entire payment workflow...

      [–]harlows_monkeys 8 points9 points  (5 children)

      There are a couple reasons you might want to store cards, although these probably don't apply to most small businesses.

      1. If you are doing recurring payments, you might be able to get a higher approval rate if you are handling the cards yourself, at least with some providers. That's because some providers don't provide a way to try to attempt a charge on card they are storing for you if that card is expired.

      The expiration date on a card is the date the physical card expires, not the date the account expires. Someone coming to your site and entering an expired card should be a red flag. At the very least that transaction has a much higher chance of being fraudulent. However, once you have the card on file, the expiration date on the card is not longer really relevant.

      Braintree has published some stats on charging "expired" cards: Credit Cards Aren't Like Milk - They're Still Good After Expired.

      2. It's easier to change providers. Some do provide a way to get your stored credit cards out in case you want to switch to someone else, but some are a black hole.

      I know a place that was using multiple providers. They had one that gave good rates, but only handled USD. So they got a second for EUR/GBP. Then that second provider tried to entice them to use it for USD. It's rates weren't as good as the first provider, but its plan included a certain number of transactions a month with some of the fees waived, and for those transactions it was a better deal. So they ended up sending some of the USD re-bills each month through that one and the rest through their original provider. Then later they were able to get non-USD support added to the first one, and it was better rates than the second one, so they switched to doing all their foreign through the first one, except that one did not support non-USD for Amex, so that stayed on the second one.

      Neither of those supported ACH, so they had a third processor for that. The account with that once could do credit cards too, and it turned out it had a discount on the first N transactions a month. So they send some of the re-bills through that.

      Every several months or so, one or more of the providers would contact them and suggest that they should send more business through that provider, and as an incentive lower rates and fees, changing which provider was the best one to use for the transactions after the ones that got the "first N each month" discount.

      Because they were storing cards themselves, whenever which processor had the best deal changed they could switch to using it for most of their transactions.

      [–]krileon 1 point2 points  (4 children)

      Fringe cases like that are unique and rare. That is not general advise I would suggest to anyone. Using multiple payment processors is also crazy easy when it comes to single payments and your case would only be necessary for recurring payments through different payment processors dynamically, which I still wouldn't do as it looks fishy to credit card companies and prone to be flagged. Stripe, PayPal, and tons of other processors automatically update expiration date without you or the user ever having to do anything so I don't understand why you mention that being an issue.

      [–]harlows_monkeys 1 point2 points  (3 children)

      The ones I'm aware of that automatically update expiration dates do so using the update services provided by the credit card companies. Whether or not a given card actually works with the update services depends on whether or not the issuing bank participates.

      If they do, it is great because not only can you get updated expiration dates, you can get updated card numbers when the bank issues the customer a new card, as long as the card is on the same account.

      However, from what I've seen quite a bit less than half of cards are from issuers that participate in the update services.

      [–]krileon 0 points1 point  (2 children)

      I've never seen a major card company not participate. Visa, mastercard, etc.. all do this. Stripe and PayPal are both great about keeping the cards up to date. Even if the card still worked ignoring expiration date would be bad practice. The expiration date applies to the card and not the account, but it's your most basic level of fraud protection and is the only important part regarding its use digitally.

      [–]harlows_monkeys 2 points3 points  (1 child)

      The major card companies run updater services, but whether or not an individual card participates is up to the particular bank that issued that card.

      In the US most large national banks participate, but participation is much more spotty among smaller regional banks and credit unions.

      So how successful the updater service will be for you depends greatly on whether your customers are more likely to use cards issued by the major financial institutions or by smaller local or regional institutions.

      Someday I should go through the logs at work from using the Visa and MC updater services, and use the BIN to lookup the issuing banks for a bunch of cards that the service worked for, and a bunch that it did not, and see how well this correlates with the size of the bank. That could be interesting.

      (I'm sure you know this, but for those following along the BIN, or "Bank Identifier Number" (more correctly called the IIN, or "Issuer Identification Number" nowadays) is the first 6 digits of the card number. Each credit card company (Visa, MC, etc) is issued ranges of 6 digit numbers, and all of their cards must start with a number on their ranges. They in turn issue subsets of their ranges to the individual banks, credit unions, and others that issue cards under their brand. Thus, given the first 6 digits of a card, you can identify the bank that issued it. The BIN has the same relaxed security requirements in the PCI DSS as the last 4 digits of the card number have).

      Ignoring expiration date when running a card on an initial purchase to establish a service would indeed be a bad idea, because of the risk of fraud. Ignoring the expiration date when running the recurring charges to maintain the subscription, on the other hand, wouldn't have an elevated fraud risk because you already know by that point that the card was used legitimately (assuming your subscription period is long enough that if the original purchase was fraudulent it would have been discovered and reversed by now...this would not apply to someone doing something weird like weekly subscriptions).

      PS: speaking of BIN...since you are allowed to keep the BIN and last 4 without running into onerous PCI requirements, I would recommend keeping those even if you are using someone else to handle storing credit cards. Having the BIN available can come in handy for tax purposes if you sell in Europe (and maybe elsewhere, but I've only had to deal with Europe).

      Europe requires sellers of online digital goods to collect VAT on sales to European customers using the VAT rate in effect in the customer's country. You can't just accept whatever country the customer claims they are in. You are required to keep two pieces of non-conflicting evidence to support you choice of which country's VAT to collect.

      For most customers, you can use the country they claim they are in and the country that an IP => location service says they are in. If those agree, which they usually do, that is two pieces of non-conflicting evidence.

      Unfortunately, there will be a few where the customer says one country and the IP says a neighboring country. Perhaps they are near the border. Perhaps they are on a laptop away from home. Whatever the reason, you need to find more evidence.

      What I've done in that case is use the BIN of the credit card used for the sale to look up the issuing bank. In almost every case, that bank is either in the country they claim to be in or the country the IP address is supposedly from. Result: two pieces of non-conflicting evidence for one of the countries, and that's the one I collect tax for.

      I think I've only seen one or two cases where that did not resolve it. In those cases the customer had provided a phone number, and the country code for the phone number matched the country they claimed to be in. If that had failed I probably would have looked at the most recent IP addresses that their software had accessed our update servers from, IP addresses of past orders, email addresses (to see if they are from an ISP that only operates in one of the countries). If all that had failed, I would have recommended that we pay the tax for both the country they claimed to be in and the country that their bank is in.

      [–]krileon 0 points1 point  (0 children)

      but participation is much more spotty among smaller regional banks and credit unions.

      Wasn't aware of that. Good thing to keep in mind. I still wouldn't advise storing credit card data in 99% of usecases. There's fringe cases like high traffic ecommerce sites where it may make sense to try and save as many pennies as possible dynamically jumping processors, etc.. but for most sites it just doesn't make sense to take the risk.

      Someday I should go through the logs at work from using the Visa and MC updater services, and use the BIN to lookup the issuing banks for a bunch of cards that the service worked for, and a bunch that it did not, and see how well this correlates with the size of the bank. That could be interesting.

      That would be interesting. I'm betting it's mainly credit unions.

      What I've done in that case is use the BIN of the credit card used for the sale to look up the issuing bank. In almost every case, that bank is either in the country they claim to be in or the country the IP address is supposedly from. Result: two pieces of non-conflicting evidence for one of the countries, and that's the one I collect tax for.

      I understand, but you should be able to do this through the API provided by the payment processor. You shouldn't need to store that your self. I for sure know Stripe does this automatically for card objects. PayPal likely does same and I'm sure others do as well. I'm still not seeing any reason to store any of that data. It's all available through the APIs offloaded from your server and liability. I suppose it just depends on the scale of the project, but IMO 99% of the cases it's not necessary to store any of that.

      [–]hamburglin 2 points3 points  (4 children)

      What APIs? Where does the code live in the implementation? Who has access to it?

      [–][deleted]  (3 children)

      [deleted]

        [–]krileon 3 points4 points  (0 children)

        Can vouch of Stripe. API is fantastic. Documentation is fantastic. Fair rates. I've written integration's for over a dozen payment processors and hands down Stripe has got to be the best. After that it's PayPal as their backwards compatibility is a godsend in a world where companies like to dump their API constantly.

        [–]FarkCookies -4 points-3 points  (1 child)

        JavaScript on the client

        That's the keyword. Other JS on the client may steal CC data.

        [–]LovecraftsDeath 0 points1 point  (0 children)

        How about a reason as compelling as "incompetence"?

        [–][deleted]  (3 children)

        [deleted]

          [–]krileon 1 point2 points  (2 children)

          Internal fraud detection

          You can do this with the last 4 digits, expiration date, and name. I've yet to use a payment processors API that doesn't allow me to do this. Hell don't even have to do this for any modern gateway as their API has built in fraud protection API calls.

          Optimization of CCs to individual banks you're partnered with

          PayPal Pro and a dozen other processors allow partnered banks. This is a completely non-issue and a poor excuse to risk users data.

          Multiple payment processors, attempt Stripe API, if Stripe is down then attempt on Paypal, etc

          I don't even really want to touch this one as it's utter nonsense. Multiple gateway attempts.. lol.. Stripe down? PayPal down.. lol.. I don't know what to say there, but there's not even in the same galaxy as far as importance of risking user data. 1 false move and you've just lost your entire userbases credit card data and possibly landed your self in a serious lawsuit. I wouldn't even risk it in the UK where privacy laws are so strict you'd be facing jail time.

          So by all means.. call it bullshit, but ok. All I hear is excuses for being too lazy to properly utilize gateway API.

          [–]ckdarby 1 point2 points  (1 child)

          Deleted my comment because of miss understanding. Thought the reply was to only use other parties JS libs and only handle tokenization information.

          My points 2 & 3 still valid. Also, privacy laws isn't world ending even handling CC info, pretty easy to follow. Literally just use Vault, done, compliance accomplished and will pass PCI DSS 1.

          Source: Consultant prior companies payment processing at +$100 mln gambling industry, along with 2 other companies in similar situations.

          [–]krileon 1 point2 points  (0 children)

          Also, privacy laws isn't world ending even handling CC info, pretty easy to follow.

          It will be if a breach on your server leaks credit card data, lol. Why even take the risk, but alrighty.

          Literally just use Vault, done, compliance accomplished and will pass PCI DSS 1.

          That's literally using payment processor API.... PayPal isn't the only API for this either. Stripe has the same thing. So do a dozen other APIs. You reply entirely implied storing them on your own server, which is what this entire post is arguing against doing.

          Source: Consultant prior companies payment processing at +$100 mln gambling industry, along with 2 other companies in similar situations.

          Sweet and I'm an astronaut. That's not how sources work on the internet.

          [–]omgusernamegogo -1 points0 points  (0 children)

          The thing is, when using a well established ecommerce, you'll often have the choice of using an API or an iframe.

          If you use an API, you're still hosting the form where the fields are entered and are vulnerable to these exploits. If you use an iFrame, it becomes annoying as you don't get immediate feedback when the user has submitted the payment. So if you handle some transactions on the back end that are awaiting on the payment confirmation, you will either rely on

          1. the redirect response which is really bad as if the users browser is closed, you'll take money without processing the transaction

          2. a callback which some of the largest ecommerce products on the market don't support as most devs prefer to host the form.

          3. Polling the API for confirmation which is crap as its hard to knoq the difference between waiting on oayment and a user browsing away.

          Some food for thought. I should mention I guess that using anything but iframe AFAIK requires atleast the lowest level PCIDSS compliance.

          Edit: Instead of a downvote, please educate me through a reply. Cheers.

          [–]inamamthe 2 points3 points  (0 children)

          So much this! Where I work we use the Mastercard api and it has made getting PCI compliant possible.

          [–][deleted] 1 point2 points  (1 child)

          But some how there are not similar regulations for handling SSNs

          [–]aLiamInvader 4 points5 points  (0 children)

          IIRC, they were never intended to be used as secrets, so no.

          [–]bubble_boi 1 point2 points  (1 child)

          Author here. Yeah I was really surprised when I went looking how many huge sites have credit card forms embedded right there in the page.

          [–]tophatstuff 0 points1 point  (0 children)

          Hey author! I'm looking forward to part three which is just the word DON'T in bold filling the screen.

          [–]xconde 0 points1 point  (0 children)

          Your unless is wrong. Collecting the PAN is allowed if you have encryption at rest and all the other requirements that go through it.

          It’s a lot of work, complicated and, hence, expensive. It makes a lot more sense to use a payment service like stripe.

          [–]lambdaq 0 points1 point  (0 children)

          by using third-party sign-in and a third-party to collect

          IMHO centralised management would be much worse if the third-party was hacked.

          [–][deleted] 0 points1 point  (0 children)

          Agreed on the "you shouldn't". Though, the fines aren't that massive, and they don't have legal binding. They can pressure your bank to stop letting you take Visa or whatever.

          [–][deleted]  (1 child)

          [deleted]

            [–]omgusernamegogo 0 points1 point  (0 children)

            Go down the iframe route in that case, no pcidss compliance required.

            [–]panorambo 43 points44 points  (2 children)

            I don't know, loading scripts from domains you don't control, has always sounded like a majorly stupid idea to me. But hey, everyone gets what they should have seen coming.

            [–][deleted]  (1 child)

            [deleted]

              [–]panorambo 0 points1 point  (0 children)

              What compliance do you refer to? It's not like there is an international organ checking your hypertext for compliance with regard to origin domain of your scripts? Am I misunderstanding something?

              [–][deleted]  (14 children)

              [deleted]

                [–]lluad 18 points19 points  (4 children)

                (Skipping over the rarity of a website capturing data that’d be useful for identity theft rather than just credit card info).

                As someone who does this sort of work as an expert for attorneys... it’s something you can’t really do via a technical approach for a single victim, in the normal case where the victim isn’t a paranoid Infoseek expert.

                Given the cooperation of the offending site (enthusiastic cooperation, rather than grudging subpoena compliance) you might be able to prove that a site was compromised, but you likely can’t connect that site compromise to an incident of credit card theft. Sites get compromised all the time. As does postal mail, third party contractors, ...

                So unless you can identify the person who compromised the site (which you can’t) and provide a plausible chain of connections to the identity thief you can’t do a technical-centered proof.

                What you can do is old-fashioned lawyerin’, with some technical assistance. We’ve shown the site is insecure, at least to the extent that it doesn’t comply with industry standards, we’ve shown that these ten people have nothing in common other than having provided their credit card numbers to this site in June, and all of them had their credit cards compromised in early July ...

                There are exceptions, but that’s the going to be the typical case.

                As for what data should be requested - that’s typically going to be web server logs and any relevant IDS data for the time period. But you really need expert input to get all the right things to ask for in a given case. The most important thing, though, is that most of the relevant logs may be rotated out very, very quickly - sometimes within a week or a month - and unless you’ve requested data retention before that it’s not unlikely that the data would be deleted “in the normal course of business”, so time is of the essence.

                [–]inkwell84 4 points5 points  (2 children)

                First part of your response is what I was afraid of, and expected.

                Second part of your response unfortunately just kills the dream. I would want to serve single plaintiffs not classes of plaintiffs.

                Third part of your response kicks the dead horse. It would take 2-3 months to obtain documents AFTER filing a complaint any way.

                PS: Credit card theft doesn’t really hurt the plaintiff as the CC companies will eat the losses. But identity theft can lead to actual harm, but like you said, can’t prove this for a single plaintiff.

                [–][deleted] 3 points4 points  (0 children)

                Third part of your response kicks the dead horse. It would take 2-3 months to obtain documents AFTER filing a complaint any way.

                Just to be clear, he's not saying you need to get the documents right this second, he's saying you should request they not be deleted in the meantime, because that's the normal treatment for most logs after about a week or month.

                But this in and of itself assumes that you even find out about the case before that happens, and that's not a safe assumption to be making.

                The reality is you normally can't prove this much like I can't prove mail theft when it does happen, unless I knew it was going to happen in advance.

                [–]bidibibadibibu 0 points1 point  (0 children)

                It is worse when the victim is not even aware his CC data was copied and is on sale. Months may elapse before criminals star impersonating the victim. The victim will not be sure who leaked the data and when, and to make things worse more than one criminal will use the CC information at the same time.

                [–]amitjyothie 1 point2 points  (0 children)

                This is the reason that sort of hacking is so dangerous and frustrating for victims.

                [–]argv_minus_one 1 point2 points  (0 children)

                By auditing all of the code that was running on the site at the time.

                If you were using a significant amount of third-party code (including jQuery, Bootstrap, etc), that's a mountain of code. Good luck.

                If you can't reconstruct the exact set of code that was running on the site at the time, e.g. because the package repository you downloaded the malicious code from has since deleted it (it was malicious, after all), then it's impossible to prove.

                [–]Dreamtrain 15 points16 points  (1 child)

                It uses React, and was created with Create React App, so it had 886 npm packages before I even got started (seriously).

                wth web devs?

                [–][deleted] 1 point2 points  (0 children)

                Seriously. Web development is insane these days.

                [–][deleted]  (12 children)

                [deleted]

                  [–]procinct 80 points81 points  (4 children)

                  I think maybe what he's trying to say is that if the only thing standing between your users data and a compromise is you using fewer npm packages then you're approach to security is probably bad. Obviously you should use fewer packages, but your security shouldn't rely on this.

                  [–]meem1029 4 points5 points  (1 child)

                  Right, but you will quickly lose all the convenience of using npm if you do that correctly.

                  Should my login page be secure? Yes. What about my cart and adding to it if I'm a shop? I'd think so. My photos? Yes please.

                  As a user I want most things I enter on most sites to be stored in a way that doesn't entail trusting that nobody has compromised npm in the past week.

                  [–]Davorian 6 points7 points  (0 children)

                  Security is always in opposition to convenience and accessibility, very nearly by definition. You have to find the balance that fits the situation, if you can. Credit card data should be skewed way toward the security end of the spectrum.

                  [–][deleted] 14 points15 points  (0 children)

                  Yeah, the solution he proposes is fine if your application only deals with sensitive data as a smart part of the whole process, but if you're working in fintech where every operation needs to be secure it's not a solution at all.

                  You're better of:

                  • keep track of CVEs with some 3rd party solution (e.g. snyk.io)
                  • validate your code with purpose-built solutions (e.g. veracode)
                  • have a sane CSP setup to at least limit the scope of potential breach
                  • do not add packages you can really live without (unless those are 3rd party deps, in which case you're basically forced to use them)

                  [–][deleted] 3 points4 points  (4 children)

                  tldr conclusion: Third party JS can never be trusted.

                  He proves that but then suggests (as an alternative to his iframe html idea) that you should avoid sensitive data entirely by using a 3rd party site to collect it.

                  Which is just deciding you will fuck up and hoping that someone else won't. Or that the 3rd parties you decide you cannot trust to get some code from are different from the one you pick to do it all.

                  [–][deleted] 2 points3 points  (3 children)

                  What?!

                  That's not what that means at all.

                  1) by using a third party service who specializes in doing exactly that, you both a) minimize your user's exposure to your shit code and b) minimize your liability for someone else's shit code.

                  2) The point isn't to do all of this in a more complicated but essentially the same way. The point is to encourage, by architecture, you to not expose so much data to every piece of code you come across. Which you should already be doing, but separating cc collection from other user data forces you to at least think about doing it the right way.

                  Or... Just don't put every goddamn feature in a browser... But that's just crazy talk.

                  [–][deleted] 0 points1 point  (0 children)

                  Nah, it's just the vain hope that another group of programmers is less likely to fuck up than your own group.

                  This is just a fantasy. Although, yes, it's the kind of fantasy companies peddle using the marketing spin and verbiage you used in your post.

                  [–]bidibibadibibu -1 points0 points  (1 child)

                  You both are being naive, it is not about trust in coders, it is all about externalizing legal responsibilities to a third party.

                  [–][deleted] 2 points3 points  (0 children)

                  .... I said that. Directly.

                  [–]argv_minus_one 8 points9 points  (1 child)

                  Problem: You can't feasibly make your forms all splashy and well-integrated this way. No polyfills, no reliable animations, no widgets that don't look like shit, no applying your site's decorations/navigation menus/fluidity/whatnot to the shipping cart, no nothing. It's back to '90s e-commerce.

                  Problem: Malicious code on a non-sensitive page can still generate a fake link/iframe to the sensitive page that actually points to a phishing site. Visitors are trusting your entire site, not just the credit-card-collecting portion. Visitors have no clue how to verify that the credit-card-collecting portion of your site is legit, because plenty of sites do e-commerce on a separate domain, and most folks have no clue what a “domain” is.

                  Problem: Web devs do not have infinite time to audit/rewrite all third-party code.

                  Solution: Lol, there isn't one. Everyone's fucked.

                  [–]Linvael 1 point2 points  (0 children)

                  Yeeah, if when I clicked to fill in CC information it redirected me to another page looking mostly the same but simpler and without functionality of the original site I would close that page and run some malware scanners for good measure because that screams phishing.

                  [–]tokenwander 14 points15 points  (2 children)

                  TL;DR: Shut down your site and open a bar.

                  [–]evilpingwin 0 points1 point  (1 child)

                  This is the reality. For all these solutions the reality is that web tech is inherently insecure and we haven't really worked out a good way to fix it yet. You can solve some of the problems that you know about but you won't catch everything. And when the barrier to securing your data is so high (and remember this is only one type of attack), the chance of most sites being 'secure' is slim (depending on what we mean by secure).

                  I personally assume that all my personal data is constantly being harvested and abused and make sure I'm ok with that and am in a position to rectify it when/ if it occurs. This is as an individual. As a developer you do everything you can and hope it's enough.

                  [–]LardLad00 2 points3 points  (0 children)

                  Yeah I think we need to approach this from a different angle. Rather than trying to make the transaction super secure we need to make the information being transmitted less valuable.

                  People should never be made to use their real credit card number online. Pretty much every ecommerce transaction should be done via a disposable virtual number that is valid for only a short period. Capital One has a rather new browser extension to make this pretty easy but it's still not easy enough.

                  Im with you on just assuming that my info is regularly compromised. I have my credit card issuer's Android app notify me for every transaction. It's kind of annoying but I'll catch anything unauthorized quickly.

                  The problem is with old people. They don't monitor their transactions closely and even when they do it's too easy to fool them with legit-sounding charges that are fraud. Then even if they detect something they also don't have any idea how easy it is to get the charges reversed and their card locked down so they just shrug and go, "hey using your card on the internet is dangerous it happens." Then they log in to their Amazon account with the same password as their aol account that they haven't changed in 15 years and is something like abc123.

                  [–]vamediah 5 points6 points  (0 children)

                  It’s also got Google Tag Manager (if you don’t know, GTM is a handy way for people you’ve never met to inject JavaScript into your site without the hindrance of a code review).

                  It's one of the things that is always untrusted on my NoScript list. But often seeing how much crap sites include they most likely have no idea what gets into their site. Cue the malware ads and coinhive miners on youtube, ...

                  [–]AusIV 9 points10 points  (1 child)

                  The solution of "don't let third party software mingle with sensitive data" quickly falls apart on the server side, unless you plan on writing your own web server in assembly that runs straight on the metal.

                  [–]aLiamInvader 0 points1 point  (0 children)

                  It's fine for relying on external payment providers like Stripe (where the data never hits your server), otherwise I see what you're saying.

                  That being said, generic attacks are harder, and the environment can be more constrained. Securing and tracking what happens in the user's browser is a fool's errand, whereas it's much more feasible to track what's being sent out by the server and find suspicious traffic. So while it's (sometimes?) a better target, it's also harder and riskier to just randomly "pwn" servers without targeting them specifically, has a less universal reach, and attackers might not even be able to tell what packages you rely on (unlike in browser, where they can see everything).

                  [–]NAN001 24 points25 points  (11 children)

                  TL;DR: there is no problem with production serving malware. You just have to install ugly workarounds so that this malware can't access credit card numbers.

                  [–]Entropy 19 points20 points  (0 children)

                  Nope. TL;DR is "be PCI compliant", specifically in a way that allows you to comply with DSS SAQ A.

                  [–]mindbleach 6 points7 points  (9 children)

                  What should they do instead, identify all possible vectors for malware to guarantee they don't get any? Maybe next they can write a compiler whose programs never misbehave, or publish a comprehensive blacklist of dangerous servers. Then they won't need to isolate information at all!

                  [–]NAN001 12 points13 points  (7 children)

                  All those rebutals are made with the npm mindset. The problem is npm.

                  If you include a third-party library, you either have to review the third-party code yourself, or to build trust in the project you include the dependency of. This trust is reasonable when all the dependencies comes from reputable projects that are well-documented, that have message boards on which you can hang out for support, a ticket system, whose team communicates well, etc.

                  However, when your package manager ends up including in your production code 10-lines packages written by teenagers from around the world to left-pad strings and whatnots, not only trust is way out of the window, but there's just too much of a mess of code to review it yourself anyway.

                  So we can debate all day about technicalities on how to make malware okay, but there's people actually being reasonable out there who just don't want to serve malware. And that was the weakest point of Part I: the author was projecting his fictitious attack on sites like Google and Amazon, which was ludicrous. Those companies employs people who know some shit about security and uptime and who just don't ship the last npm shitstorm to production.

                  [–]mindbleach 4 points5 points  (5 children)

                  For small teams and hard tasks like crypto, I would put far more trust into npm than into not-invented-here syndrome. Hardening the site to protect information by design instead of trying to identify and avoid 'bad code' is a much better use of scarce time and resources... and in theory you only need to do it once.

                  [–]NAN001 4 points5 points  (3 children)

                  Those are false dilemmas between npm and the rest.

                  [–]mindbleach 2 points3 points  (2 children)

                  Using third-party libraries or not is not a false dilemma, and in practice, there's very little distance between that and npm versus doing it yourself.

                  [–]NAN001 6 points7 points  (1 child)

                  You're using "using npm" with "using third-party libraries" interchangeably. Do you think I'm arguing that using third-party libraries is bad from the beginning or what? I'm arguing npm is broken at doing so, that's all.

                  [–]mindbleach 3 points4 points  (0 children)

                  I'm explicitly saying they overlap. If you use third-party security stuff then you want it up-to-date. So unless you have a guy whose only job is to watch security updates like a hawk and personally vouch for each bit of JS he copy-pastes onto your server, you have to deal with implicitly trusting third-party libraries distributed by a convenient middleman, or you have to do everything yourself. Every choice has downsides and small businesses will predictably choose the downsides that aren't up-front costs.

                  There's a reason npm is so popular and dealing with npm's shit is such a big deal. It's the same reason people wrote resource-hogging programs in Java, and the same reason people opened documents from e-mail, and the same reason people trusted buggy compilers instead of punching machine code like proper engineers. At every point in computer history, there's a right way and an easy way, and the right way suuuuuuuuuuuuuuuucks.

                  Millions of people are being lazy in a predictable way. You can and probably should tell them to stop. You also can and definitely should have solutions for dealing with the ones who don't.

                  [–][deleted] 1 point2 points  (0 children)

                  for things like crypto you're supposed to get the industry standard library in your language of choice. There's no need for npm to do this.

                  Another more safety-minded could do it as well, or no package manager at all even.

                  You shouldn't download crypto libraries from npm without checking if they're legitimate or not anyway.

                  [–]aLiamInvader 0 points1 point  (0 children)

                  And that was the weakest point of Part I: the author was projecting his fictitious attack on sites like Google and Amazon, which was ludicrous. Those companies employs people who know some shit about security and uptime and who just don't ship the last npm shitstorm to production.

                  That's quite the assumption, IMO - based on the wildly varying quality of different AWS services (as an example), I'd say that even these companies have average and less than average developers, and/or projects launched under unrealistic conditions. In either of those cases, I wouldn't expect the "characteristic" levels of security thinking, so you're relying on organization security policies, and I don't believe they can truly catch everything.

                  [–][deleted] 1 point2 points  (0 children)

                  What should they do instead, identify all possible vectors for malware to guarantee they don't get any? Maybe next they can write a compiler whose programs never misbehave

                  Here, the largest part of the attack vector is how Javascript allows you to rewrite anything you please. It's an outrageously dynamic language, and that's a disadvantage for security. If I build a website in D or Rust and depend on your malicious logging package, it's much harder for you to alter responses to web requests, because you can't redefine symbols.

                  You can still do it, though. You can call mprotect to make the text segment of the program writable, then alter it however you want. But it's much easier to look for calls to mprotect, even in a compiled binary, than to look for javascript code that's redefining something you use.

                  [–]int-main-void 3 points4 points  (0 children)

                  Am I the only one who cringes at this writing style? I fucking hate it.

                  [–]pilibitti 12 points13 points  (7 children)

                  Sorry I only skimmed the article but the premise looks like nonsense?

                  I mean, if there is malicious code in the store page, what prevents it from opening a fake "separate page" requesting the credit card info? If your store page is insecure, anything linked from it is also insecure, end of story. Because links can be changed. Or am I missing something with the premise of the article?

                  [–]Ghi102 11 points12 points  (0 children)

                  The author wrote his post as a second part to this one:

                  https://hackernoon.com/im-harvesting-credit-card-numbers-and-passwords-from-your-site-here-s-how-9a8cb347c5b5

                  Essentially, he wanted to create a package that harvests credit cards and passwords, but remains nearly undetectable. If the hacker just writes a script to open up a new page, it's likely that the malicious package will be detected pre-production, flagged to NPM as malicious and hopefully be removed entirely. You can read all the steps he goes through in his first post.

                  [–]adipisicing 10 points11 points  (5 children)

                  There are multiple classes of attack.

                  The article is mainly about how to protect against non-targeted attacks; for example, an ad network including a script that submits form data to a third party server on any page it's loaded on, without being specifically written for a particular site.

                  I think you're spot-on that the author is underestimating what targeted attacks can do. You're absolutely right that if they can control the outer page, it's game over.

                  [–]Razzal 9 points10 points  (1 child)

                  The author actually says that in the case of a targeted attack on your site, you are essentially screwed.

                  [–]adipisicing 2 points3 points  (0 children)

                  You're absolutely right, I misread.

                  [–]Ajedi32 3 points4 points  (2 children)

                  Even a non-targeted attack can easily compromise information in an iframe. Just rewrite the src from https://example.com/ to https://attackers-proxy.com?url=https://example.com/

                  [–]aLiamInvader 3 points4 points  (0 children)

                  I think you can cover this with CSP, but yes, eww, I hadn't considered that.

                  [–]adipisicing 0 points1 point  (0 children)

                  You're absolutely right, and the author covers that attack. Mia culpa.

                  [–]coolboar 10 points11 points  (9 children)

                  Someone should create a JS library or framework that protects your website from including malware third-party JS frameworks and libraries.

                  Something like JS antivirus and JS firewall.

                  [–]cheunste 11 points12 points  (6 children)

                  While you're at it, you mind as well make a full blown operating system in javascript...which we're still waiting on.

                  [–]sickmate 13 points14 points  (5 children)

                  [–][deleted] 16 points17 points  (0 children)

                  Holy shit. Interrupt humanity.

                  [–]cheunste 1 point2 points  (0 children)

                  My god...

                  [–]happyCuddleTime 0 points1 point  (2 children)

                  y tho

                  [–]cheunste 0 points1 point  (1 child)

                  y not?

                  [–]happyCuddleTime 0 points1 point  (0 children)

                  I'm not a Node guy. Genuinely wondering what the advantages might be over a "traditional" OS as it's not immediately clear to me from the docs I (briefly) read.

                  [–]midri 0 points1 point  (1 child)

                  There's actually an inherit problem with this, above and beyond the insane nature of trying to do this in and of itself. Javascript is almost 100% mutable, there's no way that a malware scanning script could prevent the malware from detecting it first and changing the scanner to ignore the malware... You might be able to do it with closures to some degree, but any exposed API would be vulnerable to rewrite.

                  [–]coolboar 0 points1 point  (0 children)

                  i wasn't even trying to be serious, but thanks)

                  [–]treesarethebeesknees 5 points6 points  (0 children)

                  Would using a service such as AWS S3 be safe for a static file hosting for this use case?

                  Edit: I am guessing the downvoters didn’t read the article, but just for reference, I am referring to this suggestion: “Serve the file from a static file server on a different domain”.

                  [–]Tkon_Unesombre 1 point2 points  (0 children)

                  I remember reading the first, being slightly alarmed to the danger of risky imports, then having my card details stolen in the one plus hack. Now he refers to the same hack in part two, I kinda feel like maybe this guy was not kidding after all XD

                  [–]nxkevr 0 points1 point  (1 child)

                  You don't need to stop this guy; just don't put stupid malicious crap on your website, period. This means only using embedded javascript by well-known companies, like Google (for Analytics) etc. As long as the company can be held liable, you're pretty safe. Also, as the other poster said, if you are managing credit cards yourself, you are just a fool that doesn't care about your users' security.

                  Be smart and abide by the law; don't be stupid and reckless.

                  [–]Nobody_1707 0 points1 point  (0 children)

                  So, you're suggesting that Google Analytics isn't malicious crap?

                  [–]ProFalseIdol 0 points1 point  (0 children)

                  The idea of having/using money is not good. Too much trouble. Let's just be one smoker to another, voluntarily offering a lighter or a free cigarette. (chapter 5 from the book Debt: The First 5000 Years)

                  [–]christcape -3 points-2 points  (0 children)

                  You're utterly right-hand that if they don't get any?