Not that I know of. My guess is that somebody on that list threw a DMCA takedown notice at Github/Gitlab to get it pulled. Knee jerk reaction is to pull first, verify later.
That may have been the case with GitHub. Gitlab claimed that it fell into the same category as zero-day exploits (which is ridiculous), and that as such posting it wasn't responsible disclosure and it thus violated their ToS.
Sounds like he contacted some of the sites in the article and they blew him off ("We are 100% secure, don't you see the Verisign badge?!"). But yeah, that still makes sense that it could be pulled for that reason.
It's not just that it makes sense, that's what GitLab said. I can't find the link right now, but it's on the earlier HN post about Github/lab taking it down.
As the article points out, if someone can inject Javascript into your checkout page, you're most likely also having other security issues.
Still, and I'm pretty much being called an idiot every time I point this out: You should NEVER have the user enter credit card information on your site. That is something that is best left to your PSP. If you're Amazon or similar size, fine, I can accept that you most likely have the need resources. Anyone smaller should never interact with credit card information, leave it to Stripe, BrainTree, Paypal, someone trusted, with the resources to handle it.
Also I'm not really surprised to see that it seem to be affecting Magento shops. Similarly to not accepting credit card directly: If you don't have the technical resource, don't run Magento. It's big and complicated, and you need to react fast when there's a problem. Contracting is an option, but expensive and the turn around time is a lot higher, especially if there's a critical error in Magento and everyone need the issue fixed right then and there.
I work in ecommerce consulting - most of my clients take CC info on their site, the forms on the checkout POST (over SSL) to the PSP who then return a token to the site, all future transactions use the token.
Most people don't want to bounce customers to a third party site for payment, it really hurts conversions.
I certainly hate it when merchants bounce me to a different site. It's most likely I will never complete the transaction and just buy from Amazon instead.
If your site sacrifices user experience, I will hate your site. Simple as that. Amazon understands the convenience factor really well.
I hope Apple Pay (on the web) takes off. While I don't like yet another middle man, and I don't care about its security benefits in the slightest, I appreciate the consistent and convenient interface it provides, so I will use it, if offered the choice.
I don't care about keeping my credit card safer that it already is. I am not liable for credit card fraud. In this insecure world we live in, I have not lost a single dime, nor any time, nor was I inconvenienced in any way by card theft. It's not my problem to worry about.
My debit card was skimmed once, a few weeks ago. The bank detected fraud, notified me that they sent me a new card, and I didn't lost any money. I only lost two minutes of my life while I was talking to the bank on the phone.
No, because I have many debit cards from different banks in order to have redundancy and increase availability when the bank's system is down, or a particular card simply won't work at some merchant, but other will (usually happens in the US with my European cards).
So the sites should drop the safety features because there exists a user who would not be personally inconvenienced by the theft of their credit card details?
And that adds the overhead of managing multiple balances, fees, and credentials. You don't seem to be a typical bank user, so I'm still going to conclude that getting a credit/debit card stolen is a huge inconvenience.
This. We saw about 50% would prefer on-site transactions, 50% would prefer off-site transactions (PayPal or Amazon payments). Remove one of the options and half your customers just disappear.
Most people don't want to bounce customers to a third party site for payment, it really hurts conversions.
That is certainly true in my experience.
Also, some of the payment services have a habit of changing the appearance and/or behaviour of their hosted systems, sometimes not for the better, and typically without warning. That is a risk you might not be willing to take for something as important as your payment flow. I know of at least one local business that switched from Stripe Checkout to using Stripe.js from their own site as a direct result of Checkout being significantly changed and resulting in customer support enquiries about the new behaviour that the business had no idea how to answer.
I've worked with similar organizations that want the transaction on their site due to all the reasons mentioned in the comments.
There are providers that use JavaScript to allow you to take payment information on your platform but never let the sensitive details hit your server. I believe this removes your platform as an attack vector for leaking credentials. The only locations that have traces of that information are the browser and the payment provider.
Unfortunately, even if your payment service is hosting the system that processes the sensitive details, there's always an element of vulnerability on the merchant's side if they are hosting the rest of the site, simply because a compromise could redirect customers to a hostile alternative site to collect those sensitive details. At that point, they're really no better off than a completely fake site that never had any real relationship with a payment service at all. Merchants should always be serving their own pages securely for this among other reasons, even if they are never intending to receive sensitive payment credentials.
Which presumably is why the attackers here are injecting their own client-side JavaScript that sends a copy of the payment information to the attacker. Even if the business never sees a copy of the sensitive information, their server can still be made to serve up malicious code that does.
I don't understand this at all. I really, really don't want to give my credit card details to some random webshop who are exceedingly unlikely to have solid security. If I can use PayPal or another well known payment provider, great, I don't even have to type in my details. But even a less well known PSP is more likely to get it right than a small business webshop.
A slightly jarring user interface seems a small price to pay for a much lower chance of my payment details being compromised. Is this a minority view?
I am not liable for credit card fraud. The last thing in the world I want is inconvenience for me, when it's other people's money at risk (bank, merchant, CC company, whoever), not mine.
On the other hand, Paypal itself is a liability. Blocking your account (and your money!) for months without recourse, randomly reducing expense limits to nothing (50 EUR) are not just some Internet stories, but things that have happened to me personally multiple times.
When my card was stolen (debit card even!), I didn't lose a dime, nor time. Bank just sent me a new card the same day. I didn't even have to report the fraud, they detected it themselves, as they are really good at that. They just called me to tell me about it, and that they sent me a new card.
You aren't liable for credit card fraud, but that money comes from somewhere. Today it is a small percentage charged to the vendor; do they pass it on?
And tomorrow, when the problem gets worse and the fees start to climb, will you still not care?
Why be content with a system that may indirectly charge you for other people's lack of security?
Why not look for ways to focus the cost on the vendors who lack security?
Yes, you're right, they pass it on. But as costs start to get noticible to the involved parties (direct and indirect), hopefully that would prod the ones that don't care now, to start.
As a merchant, I am the one responsible. When a stolen credit card gets used on my site, I am the one that has to pay for that (assuming Stripe does not block it through fraud prevention). Which is fine, because my fraud rate is very low. But it's an odd situation because in effect I am being penalized for someone else's lax security. Sure I could try to come up with my own fraud prevention algorithm but I highly doubt that as a small vendor I could beat Stripe in that department. So it doesn't matter how well I'm protecting my customer's card data, the fact is if someone's info is stolen from some other site or an atm skimmer or somewhere else, and then the perpetrator buys product from my site, I have to pay for that carelessness.
Personally I think the banks should be paying for the bulk of this fraud out of the 2-3% transaction fees, not merchants who may not have anything to do with the problem. This way, there's strong incentive to actually issue secure cards and improve security. Right now, it's no skin off their backs, so nothing is improving.
Some years ago I had a Bank of America credit card. My new card never arrived in the mail, and I discovered 3,000 in charges. When I reported it, Bank of America insisted that they had mailed me the card and that I was responsible for its use. I appealed, and they still insisted that I pay the bill. I don't know their logic - was it just some employees trying to increase profit - like Wells Fargo today? And what choice did I have? Hire a lawyer for $400/hour? Lose hours of work time fighting them? Allow my credit to be wrecked? So I paid them and got a different credit card. (They even fined me and charged me interest for the months I was contesting the charges.)
In the end, they hold an unfair power over those who they can extort. I wish we had much better consumer laws - to actually protect us.
I don't know, maybe. I have zero liability on credit card purchases, and while it's certainly an inconvenience I never don't buy something because my details might be leaked. Who cares, why put yourself through the constant mental effort for an event that happens maybe once or twice a decade if you are exceedingly careless?
I absolutely despise being sent to a third party site - usually a broken one that takes forever to load, with some annoying "security" authentication, or OTP, etc. when really all I wanted was amazon one click and to move on with my life.
By far the #1 way a small merchant can get me to click the buy button is make it easy for me to checkout and pay. If I have to sign up for an account, be redirected around the world, etc. I generally tend to lose interest and just go back to newegg/amazon. Note that this sometimes is a third party payment link such as Paypal due to the nature of the service - but you have to think about user experience first, not last.
Also your requirement makes absolutely no sense to me. If a merchant is compromised to the point that javascript can be injected, it's not much more difficult at all to direct you to a fake paypal skimmer that you likely won't notice. I agree it raises the bar a bit, but not by an appreciable degree.
Not quite right. Many banks make you liable for the first $50, for each occurrence of fraud. Also they typically require you to notice and report a fraudulent charge within 30-90 days or else you are liable for 100% of the amount.
Most likely. The fact that you understand what is happening when your store webage you're on goes white the words in the www bar change and then you're on a different site and it's asking for credit card info kind of illustrates this point.
Could you imagine trying to buy eggs at the supermarket then when it comes time to swipe your credit card, being asked to leave all your eggs at the register, go over to a different store with your credit card, swipe your card there, sign the paper, then go back to the original store and pick up your eggs? I imagine that's how a lot of people visualize going to a PSP site to enter credit card info.
Like so many other areas, it's really a shame that the industry can't co-operate here. Apple Pay works fine at the one location near me that supports it, but it's a headache for the merchant (I might be the only person who uses that payment system) and the consumer (lack of support elsewhere).
The equation for websites is similar given Mac users are a minority, and many Mac users use Chrome.
Apple Pay online is great for convenience and security, from a practical point of view, but on a more abstract point of view I think something is deeply flawed about the payment industry if the solution is to add yet another middle man.
I want a world where payment is convenient, security is excellent, and there's no mandatory mafia of middle man between my electronic money and the merchant. It's fine that people chose to use banks voluntary, banks provide many services people want. But it should not be mandatory to use banks, if you chose to do so, and most certainly it should not be necessary to implicate yet another 3rd party to the transaction (VISA/Mastercard). And now we are adding a 4th party!
Whether to use a 3rd, 4th, 5th party should be users' choice. Some people value security, others privacy, others convenience; some people want 2FA for every transaction, some people hate PINs and want just to swipe a card, etc. All this should be client side; user's side. Open payment protocol with multiple implementations. Merchant just uses the protocol. If some new payment revolution is coming, merchant should just update his software.
We have technical solutions to do all this, but most people do not understand that this is possible, what the existing system entails; and the people in charge of this don't want to lose the power.
That has to be a local issue, because that is flat out wrong. The majority of all e-commerce sites does exactly that. I have yet to meet a PSP that believe send the entire credit card number, expiry and CVV was the right solution. I've talked to exactly one PSP that supported accepting credit cards in an iframe, and that was only available to existing customers, because they where discontinuing that service.
In most of northern Europe at least, customer have been use to credit card payments redirecting them to third party sites since at least 1999. It has zero effect on conversion.
> That has to be a local issue, because that is flat out wrong.
You can't declare it a possible local issue and then say it's wrong.
And it's definitely been measured (in my own testing at various companies and by many many others) that it hurts conversions to break the flow into separate redirect.
You know it. I know it. Most of HN knows it. We are, in general, not the customer.
On sites I've been involved with, in 2016, I still have to fight tooth and nail to get SSL on the payment page at all, let alone redirect users somewhere else.
On sites I've been involved with, in 2016, I still have to fight tooth and nail to get SSL on the payment page at all
I'm reasonably sure that every payment service I've ever used requires payment pages to be served over HTTPS, not just HTTP, even those that have minimal other requirements and take on most of the security burden themselves with some sort of hosted arrangement.
Are there really significant numbers of merchants who aren't doing that?
As a low tech experiment, I just grabbed the list that started this thread and tried a few random sites.
I only made it to the third one before I found an http:// checkout page. I tried to change the address to https:// and found it complaining about a cert mismatch. I also viewed source and confirmed the form submits to an http:// address.
Do some payment services not do at least a basic check of integrations before allowing them to go live? I haven't worked on a site starting out with online payments very recently, but the last time I did, there was a short series of entries in the server logs that did look like someone from the payment service had taken at least a very quick look at the relevant pages.
We shouldn't be asking this of clients any more. Build the site with SSL on all pages and either require the client buys a cert or implement Let's Encrypt. But at this stage, it makes no sense to make it optional, even for non-commerce sites.
> leave it to Stripe, BrainTree, Paypal, someone trusted, with the resources to handle it.
Wouldn't stripe and braintree still effectively let you handle CC on your own site? i.e. If someone can inject JS code there, they can in high likelihood grab CC details even if you're using stripe or braintree. Am I missing something?
The difference is if you make the user click a link to Stripe's site then unless the evil JS replaces the URL with a different domain they can no longer interact with the user. And swapping out links is something that will get noticed far more easily than passively harvesting CC details.
> You should NEVER have the user enter credit card information on your site
My app client sends the card info to Stripe, then forwards the Stripe token to my server to charge the card each month. So far this is a standard security model.
The problem is that if PayPal come along to offer me a cheaper commission on processing subscription payments, I cannot simply switch my sever to use PayPal for all my existing customers. So I'm tempted to encrypt the credit card info and store it in my database in case I want to switch in future.
I don't know about PayPal, but even if you just have the token for recurring payments/subscriptions you can still switch PSPs. Most PSPs are able to exchange tokens and information, enabling you to switch between them (at a price of cause).
> "So I'm tempted to encrypt the credit card info and store it in my database in case I want to switch in future."
Seriously....just don't. The world of pain you'll be in if you mishandle this data and the symmetric encryption key will probably see you or your clients made bankrupt.
Please read up on PCI-DSS before even considering this:
I constantly see various posts regarding credit card skimming and find it curious why 2 factor authentication is not enforced for all transactions. It's a simple solution, having someone's credit card info is not sufficient to make a transaction.
Note: I am not from the USA. The 2FA solution is the default in my country, and I have literally never heard anyone lose money because of skimming.
There's a lot of hate against 3DSecure around here because a lot of banks and stores (seems primarily in the US and U.K.) have extremely poor implementations of it.
Horror stories on here range from having the 3DSecure in an iframe to having horrible "secret question" style inline enrollment
My banks implement it decently - weird third party URLs (albeit with the banks name on the EV certs), but using mobile 2FA apps or hardware card readers for the verification. One of my banks enforces 3DSecure for their debit cards (but not credit cards) since all domestic stores support it.
3DSecure and the Visa equivalent (don't remember the name) are not really what I meant by 2FA.
To make a transaction:
-add items to cart
-enter card details
-you are redirected to 3DSecure if it's enabled
-you are redirected to a page of your bank where you enter a One time Password(OTP). It's a simple 6 digit number sent to your mobile phone and is unique for every transaction.Enter OTP.
-transaction is confirmed.
So even if someone has my card details they can't make any transaction (unless they also managed to steal my phone).
Two of my banks do it a little differently. With Visa's process (Verified by Visa), I had to register a password for each card. A separate password from my internet banking password. When I try to use my card on a VbV site (maybe one in ten sites), I have to enter three random characters.
So few sites require it that I don't remember the password and entering random characters from KeepassX is always a pain.
I hate it when I see that VbV prompt. That's frustrating security and results in passwords that you use so infrequently they never get changed. I'd much prefer OATH TOTP or even an SMS based code (with a "I don't have my phone" option).
3DScure is usually optional. Some merchants might opt out of using it (but then they take the liability for fraud) so criminals can still use your credentials.
Do you feel reassured about entering your credit card details into anything hosted there? At least the domain's whois information doesn't claim it's registered to "yaron shohat" (sic) any more...
The entire card payment system is fundamentally undermined from a security point of view, simply because it relies on merchants pulling funds instead of customers pushing them.
We would probably be much better off if we'd evolved a system where the payment authorisation step was always hosted by the customer's bank, and everyone expected that instead of putting card details or the like into some merchant's site, they would only ever deal with their own bank.
In the absence of such a system, modern 2FA schemes are trying to plug the gap, but they almost always introduce more friction in the process and consequently affect conversion rates. When not everyone is using them, that makes adopting 2FA potentially a worse option commercially than accepting the losses due to a certain level of fraud in return for better conversion rates across the board.
> I constantly see various posts regarding credit card skimming and find it curious why 2 factor authentication is not enforced for all transactions.
A few reasons:
1) Card issuers don't care because it's merchants who are on the hook for card-not-present fraud.
2) Cardholders don't care because they're never on the hook for fraud.
3) If a specific merchant enforced 3DSecure (to move fraud liability back to the issuer/network) they'd lose more money on lost sales from people that hate 3DSecure (everyone?) than they would save on fraud.
That said, I have seen 3DSecure enforced at ultra-high-fraud merchants like Bitcoin resellers.
I think this is a bad generalization, that doesn't even stand in more than 50% of the cases: If someone can inject Javascript into your site, your database is most likely also hacked.
There's a lot of PHP and similar technologies on the web, where the mechanism for hacking a site such that you can insert something into the HTML template also implies full code execution abilities. These technologies are still very popular and multiple large projects that are widely deployed by many sites are implemented with them.
It depends on the details, because there are also technologies where the templates are separated and you can add text to them without execution rights. But for all that people on HN may tend to prefer that, in the great big real world, thinking separation of execution and data is a requirement for a template language is a niche view. Even here you can start up a rollicking, free-wheeling debate on the topic, and I'm not even sure where I come down myself.
Unsurprisingly, the scammers use scanners that look for the soft targets first, so, statistically, I'd suspect the claim could be modified to a true statement with "If someone can inject Javascript into your site, they could have hacked your database with just a bit more effort on your site." It's easier to write something that sprays a script tag across a whole bunch of sites that can scrape off anything that gets submitted that looks like a credit card number than it is to write something to go dump databases across all those same sites, because the database is more likely to be customized or have quirky local rules that would make your automated code fail, or draw attention to itself when it froze the database for half an hour, or some other issue like that. But if someone paid personal attention to your site, they could probably grab the whole thing. At this scale, clearly personal attention is not being paid to these sites.
You could also prevent this problem in general with Content Security Policy, by whitelisting only the domains you know JS should come from. Then, even if they do in fact get a script tag on to your page pointing at a hostile domain, it won't execute unless they also nuke your CSP headers. You can even set up your CSP such that it notifies you upon violations. In theory a hacker could still penetrate all that in one shot by disabling your CSP and then adding their script, but it means if they miss the CSP even briefly that you have at least a chance to be notified before they square it away. It at least raises the bar.
But the real problem here is that we're not generally talking about people who know about CSP, nor is it generally reasonable to expect they would or could, at least right now. It's pretty niche stuff in general. I'm sure if I gave a quiz on CSP here, a ton of people could reply with the correct answers, some of them even without Googling, but in general if I talk to my coworkers about that I'm doing well to get a vague "Yeah, I've heard of that I think..."
"Raises the bar", I did say. They have access but if they're only accessing it through an automated system they may miss it.
Plus, I should have pointed out that CSP can be applied at higher layers, including nginx itself or a WAF, that the attacker may not be able to access or modify. I didn't think of it at the time.
The only reason this is possible is because card payment systems still are using transistor era technologies with zero cryptography. You get someone's card number and you can pay with it. All VISA security is based on trust. With Internet it doesn't work anymore because you never know who your customer is, you don't know what merchant does with card numbers and the laws are different in different countries.
They also lack privacy: your name is written on a card and in every transaction you use the same card number so merchants can collect person's shoppping history (and using a name they can find customer's page in social networks). And maybe they even share this information among themselves.
Not in every country there are laws protecting clients. In US there is a law, but in other countries if your card number got stolen you might never get the money back and even be left with a debt if it was a credit card (because it is client's responsibility to keep his card info secure).
When you are buying something online with a card there is no way to check whether it is a real shop or just a fake site to collect card numbers.
As a result merchants make their own sophisticated antifraud system and you never know whether your card would work or not. For example once I was unable to pay for a Digital Ocean server with virtual prepaid card (of course I would never pay with a real card on the Internet) so I chose another cloud hosting and they lost a customer.
> The only reason this is possible is because card payment systems still are using transistor era technologies with zero cryptography.
Cryptography does not help here. The problem is that better transaction types (3d secure) are badly implemented by banks and as such not deployed because it's seen as an unnecessary second step.
And this is exactly why I do not understand why there is such a huge opposition against 3D Secure. It prevents this exact issue. Card fraud on 3D Secure pages that are well implemented (2nd factor with SMS or hardware device token) is non existent.
Here in the US, users avoid Verified by Visa (which I believe is the same thing) because it moves the burden of fraud onto the end user. Whenever that VBV page comes up, I immediately abort. I don't trust companies to keep my card data safe, so if the burden is suddenly on me, I'll just go without whatever I was going to buy if I can't get it elsewhere. It's that big of a deal. This is before we even get to technical issues or the UI/UX flow.
That's misinformation. It only shifts for 3d secure transactions work require another info that is not sent to your merchant. So the only way this fails if your bank had a bad 3d secure page or your fucked up.
This is not responsible disclosure [1], which raises an ethical issue.
For victims added to the list and published within days, the victim is not allowed adequate time time to fix their vulnerability. That does real harm to the victims by inviting attacks before they can avoid the harm the disclosure invites.
I can't wait until Apple Pay and company are more widely deployed. It's significantly more secure and way faster than manual entry. Tokenization can't come fast enough.
I'm surprised this article does not mention the use of virtual credit card numbers in their list of solutions. I use one-time / temporary card numbers with expirations and dollar limits from my issuer[1] for both online and over the phone transactions
I tried to do this with Citibank a few years ago and couldn't get it to work. I don't know if the issue was something in my browser, or what, but it just wouldn't generate the numbers for me. After that, I gave up. Maybe it works better now?
103 comments
[ 3.8 ms ] story [ 187 ms ] threadStill, and I'm pretty much being called an idiot every time I point this out: You should NEVER have the user enter credit card information on your site. That is something that is best left to your PSP. If you're Amazon or similar size, fine, I can accept that you most likely have the need resources. Anyone smaller should never interact with credit card information, leave it to Stripe, BrainTree, Paypal, someone trusted, with the resources to handle it.
Also I'm not really surprised to see that it seem to be affecting Magento shops. Similarly to not accepting credit card directly: If you don't have the technical resource, don't run Magento. It's big and complicated, and you need to react fast when there's a problem. Contracting is an option, but expensive and the turn around time is a lot higher, especially if there's a critical error in Magento and everyone need the issue fixed right then and there.
Most people don't want to bounce customers to a third party site for payment, it really hurts conversions.
If your site sacrifices user experience, I will hate your site. Simple as that. Amazon understands the convenience factor really well.
I hope Apple Pay (on the web) takes off. While I don't like yet another middle man, and I don't care about its security benefits in the slightest, I appreciate the consistent and convenient interface it provides, so I will use it, if offered the choice.
Even if said sacrifice keeps your credit card safe?
I mean, if you are staying on the same site, you have no guarantees that the site isn't storing your credit card info in an unsecure manner.
My debit card was skimmed once, a few weeks ago. The bank detected fraud, notified me that they sent me a new card, and I didn't lost any money. I only lost two minutes of my life while I was talking to the bank on the phone.
This. We saw about 50% would prefer on-site transactions, 50% would prefer off-site transactions (PayPal or Amazon payments). Remove one of the options and half your customers just disappear.
That is certainly true in my experience.
Also, some of the payment services have a habit of changing the appearance and/or behaviour of their hosted systems, sometimes not for the better, and typically without warning. That is a risk you might not be willing to take for something as important as your payment flow. I know of at least one local business that switched from Stripe Checkout to using Stripe.js from their own site as a direct result of Checkout being significantly changed and resulting in customer support enquiries about the new behaviour that the business had no idea how to answer.
There are providers that use JavaScript to allow you to take payment information on your platform but never let the sensitive details hit your server. I believe this removes your platform as an attack vector for leaking credentials. The only locations that have traces of that information are the browser and the payment provider.
A slightly jarring user interface seems a small price to pay for a much lower chance of my payment details being compromised. Is this a minority view?
On the other hand, Paypal itself is a liability. Blocking your account (and your money!) for months without recourse, randomly reducing expense limits to nothing (50 EUR) are not just some Internet stories, but things that have happened to me personally multiple times.
When my card was stolen (debit card even!), I didn't lose a dime, nor time. Bank just sent me a new card the same day. I didn't even have to report the fraud, they detected it themselves, as they are really good at that. They just called me to tell me about it, and that they sent me a new card.
And tomorrow, when the problem gets worse and the fees start to climb, will you still not care?
Why be content with a system that may indirectly charge you for other people's lack of security?
Why not look for ways to focus the cost on the vendors who lack security?
Personally I think the banks should be paying for the bulk of this fraud out of the 2-3% transaction fees, not merchants who may not have anything to do with the problem. This way, there's strong incentive to actually issue secure cards and improve security. Right now, it's no skin off their backs, so nothing is improving.
You're seriously overestimating the fraud protection Stripe does.
In the end, they hold an unfair power over those who they can extort. I wish we had much better consumer laws - to actually protect us.
We have excellent consumers laws in this particular regard. If only consumers fought for their rights instead of paying the mafia!
> Hire a lawyer for $400/hour?
You don't need a lawyer for small claims court.
They are who fined Wells Fargo.
I don't know, maybe. I have zero liability on credit card purchases, and while it's certainly an inconvenience I never don't buy something because my details might be leaked. Who cares, why put yourself through the constant mental effort for an event that happens maybe once or twice a decade if you are exceedingly careless?
I absolutely despise being sent to a third party site - usually a broken one that takes forever to load, with some annoying "security" authentication, or OTP, etc. when really all I wanted was amazon one click and to move on with my life.
By far the #1 way a small merchant can get me to click the buy button is make it easy for me to checkout and pay. If I have to sign up for an account, be redirected around the world, etc. I generally tend to lose interest and just go back to newegg/amazon. Note that this sometimes is a third party payment link such as Paypal due to the nature of the service - but you have to think about user experience first, not last.
Also your requirement makes absolutely no sense to me. If a merchant is compromised to the point that javascript can be injected, it's not much more difficult at all to direct you to a fake paypal skimmer that you likely won't notice. I agree it raises the bar a bit, but not by an appreciable degree.
Not quite right. Many banks make you liable for the first $50, for each occurrence of fraud. Also they typically require you to notice and report a fraudulent charge within 30-90 days or else you are liable for 100% of the amount.
Most card issuers these days will proactively contact the customer to inquire about suspicious charges.
Most likely. The fact that you understand what is happening when your store webage you're on goes white the words in the www bar change and then you're on a different site and it's asking for credit card info kind of illustrates this point.
Could you imagine trying to buy eggs at the supermarket then when it comes time to swipe your credit card, being asked to leave all your eggs at the register, go over to a different store with your credit card, swipe your card there, sign the paper, then go back to the original store and pick up your eggs? I imagine that's how a lot of people visualize going to a PSP site to enter credit card info.
Especially now that it can be deployed on websites?
The equation for websites is similar given Mac users are a minority, and many Mac users use Chrome.
I want a world where payment is convenient, security is excellent, and there's no mandatory mafia of middle man between my electronic money and the merchant. It's fine that people chose to use banks voluntary, banks provide many services people want. But it should not be mandatory to use banks, if you chose to do so, and most certainly it should not be necessary to implicate yet another 3rd party to the transaction (VISA/Mastercard). And now we are adding a 4th party!
Whether to use a 3rd, 4th, 5th party should be users' choice. Some people value security, others privacy, others convenience; some people want 2FA for every transaction, some people hate PINs and want just to swipe a card, etc. All this should be client side; user's side. Open payment protocol with multiple implementations. Merchant just uses the protocol. If some new payment revolution is coming, merchant should just update his software.
We have technical solutions to do all this, but most people do not understand that this is possible, what the existing system entails; and the people in charge of this don't want to lose the power.
That has to be a local issue, because that is flat out wrong. The majority of all e-commerce sites does exactly that. I have yet to meet a PSP that believe send the entire credit card number, expiry and CVV was the right solution. I've talked to exactly one PSP that supported accepting credit cards in an iframe, and that was only available to existing customers, because they where discontinuing that service.
In most of northern Europe at least, customer have been use to credit card payments redirecting them to third party sites since at least 1999. It has zero effect on conversion.
You can't declare it a possible local issue and then say it's wrong.
And it's definitely been measured (in my own testing at various companies and by many many others) that it hurts conversions to break the flow into separate redirect.
On sites I've been involved with, in 2016, I still have to fight tooth and nail to get SSL on the payment page at all, let alone redirect users somewhere else.
I'm reasonably sure that every payment service I've ever used requires payment pages to be served over HTTPS, not just HTTP, even those that have minimal other requirements and take on most of the security burden themselves with some sort of hosted arrangement.
Are there really significant numbers of merchants who aren't doing that?
I only made it to the third one before I found an http:// checkout page. I tried to change the address to https:// and found it complaining about a cert mismatch. I also viewed source and confirmed the form submits to an http:// address.
So.... yes.
Do some payment services not do at least a basic check of integrations before allowing them to go live? I haven't worked on a site starting out with online payments very recently, but the last time I did, there was a short series of entries in the server logs that did look like someone from the payment service had taken at least a very quick look at the relevant pages.
Wouldn't stripe and braintree still effectively let you handle CC on your own site? i.e. If someone can inject JS code there, they can in high likelihood grab CC details even if you're using stripe or braintree. Am I missing something?
My app client sends the card info to Stripe, then forwards the Stripe token to my server to charge the card each month. So far this is a standard security model.
The problem is that if PayPal come along to offer me a cheaper commission on processing subscription payments, I cannot simply switch my sever to use PayPal for all my existing customers. So I'm tempted to encrypt the credit card info and store it in my database in case I want to switch in future.
Seriously....just don't. The world of pain you'll be in if you mishandle this data and the symmetric encryption key will probably see you or your clients made bankrupt.
Please read up on PCI-DSS before even considering this:
https://www.pcisecuritystandards.org/document_library
Note that both GitHub and GitLab took down the list already.
In any case the only operate in USA.
Note: I am not from the USA. The 2FA solution is the default in my country, and I have literally never heard anyone lose money because of skimming.
Horror stories on here range from having the 3DSecure in an iframe to having horrible "secret question" style inline enrollment
My banks implement it decently - weird third party URLs (albeit with the banks name on the EV certs), but using mobile 2FA apps or hardware card readers for the verification. One of my banks enforces 3DSecure for their debit cards (but not credit cards) since all domestic stores support it.
To make a transaction:
-add items to cart
-enter card details
-you are redirected to 3DSecure if it's enabled
-you are redirected to a page of your bank where you enter a One time Password(OTP). It's a simple 6 digit number sent to your mobile phone and is unique for every transaction.Enter OTP.
-transaction is confirmed.
So even if someone has my card details they can't make any transaction (unless they also managed to steal my phone).
Sorry if my original comment was not clear.
Follow up question, how widespread is the adoption of 3DSecure in the USA and if it's not available, is it easy to get 3DSecure activated?
So few sites require it that I don't remember the password and entering random characters from KeepassX is always a pain.
I hate it when I see that VbV prompt. That's frustrating security and results in passwords that you use so infrequently they never get changed. I'd much prefer OATH TOTP or even an SMS based code (with a "I don't have my phone" option).
All 3DSecure iframe content is bounced through a third-party site, securesuite.co.uk. I invite you to visit one of the following URLs:
http://securesuite.co.uk
https://securesuite.co.uk
Do you feel reassured about entering your credit card details into anything hosted there? At least the domain's whois information doesn't claim it's registered to "yaron shohat" (sic) any more...
Here's a full writeup:
https://web.archive.org/web/20160603034835/http://www.cl.cam...
We would probably be much better off if we'd evolved a system where the payment authorisation step was always hosted by the customer's bank, and everyone expected that instead of putting card details or the like into some merchant's site, they would only ever deal with their own bank.
In the absence of such a system, modern 2FA schemes are trying to plug the gap, but they almost always introduce more friction in the process and consequently affect conversion rates. When not everyone is using them, that makes adopting 2FA potentially a worse option commercially than accepting the losses due to a certain level of fraud in return for better conversion rates across the board.
A few reasons:
1) Card issuers don't care because it's merchants who are on the hook for card-not-present fraud.
2) Cardholders don't care because they're never on the hook for fraud.
3) If a specific merchant enforced 3DSecure (to move fraud liability back to the issuer/network) they'd lose more money on lost sales from people that hate 3DSecure (everyone?) than they would save on fraud.
That said, I have seen 3DSecure enforced at ultra-high-fraud merchants like Bitcoin resellers.
It depends on the details, because there are also technologies where the templates are separated and you can add text to them without execution rights. But for all that people on HN may tend to prefer that, in the great big real world, thinking separation of execution and data is a requirement for a template language is a niche view. Even here you can start up a rollicking, free-wheeling debate on the topic, and I'm not even sure where I come down myself.
Unsurprisingly, the scammers use scanners that look for the soft targets first, so, statistically, I'd suspect the claim could be modified to a true statement with "If someone can inject Javascript into your site, they could have hacked your database with just a bit more effort on your site." It's easier to write something that sprays a script tag across a whole bunch of sites that can scrape off anything that gets submitted that looks like a credit card number than it is to write something to go dump databases across all those same sites, because the database is more likely to be customized or have quirky local rules that would make your automated code fail, or draw attention to itself when it froze the database for half an hour, or some other issue like that. But if someone paid personal attention to your site, they could probably grab the whole thing. At this scale, clearly personal attention is not being paid to these sites.
You could also prevent this problem in general with Content Security Policy, by whitelisting only the domains you know JS should come from. Then, even if they do in fact get a script tag on to your page pointing at a hostile domain, it won't execute unless they also nuke your CSP headers. You can even set up your CSP such that it notifies you upon violations. In theory a hacker could still penetrate all that in one shot by disabling your CSP and then adding their script, but it means if they miss the CSP even briefly that you have at least a chance to be notified before they square it away. It at least raises the bar.
But the real problem here is that we're not generally talking about people who know about CSP, nor is it generally reasonable to expect they would or could, at least right now. It's pretty niche stuff in general. I'm sure if I gave a quiz on CSP here, a ton of people could reply with the correct answers, some of them even without Googling, but in general if I talk to my coworkers about that I'm doing well to get a vague "Yeah, I've heard of that I think..."
Plus, I should have pointed out that CSP can be applied at higher layers, including nginx itself or a WAF, that the attacker may not be able to access or modify. I didn't think of it at the time.
They also lack privacy: your name is written on a card and in every transaction you use the same card number so merchants can collect person's shoppping history (and using a name they can find customer's page in social networks). And maybe they even share this information among themselves.
Not in every country there are laws protecting clients. In US there is a law, but in other countries if your card number got stolen you might never get the money back and even be left with a debt if it was a credit card (because it is client's responsibility to keep his card info secure).
When you are buying something online with a card there is no way to check whether it is a real shop or just a fake site to collect card numbers.
As a result merchants make their own sophisticated antifraud system and you never know whether your card would work or not. For example once I was unable to pay for a Digital Ocean server with virtual prepaid card (of course I would never pay with a real card on the Internet) so I chose another cloud hosting and they lost a customer.
Cryptography does not help here. The problem is that better transaction types (3d secure) are badly implemented by banks and as such not deployed because it's seen as an unnecessary second step.
"Thanks for your suggestion, but our shop is totally safe. There is just an annoying javascript error."
please share the stores sending these negligent and insulting responses. they don't deserve any sort of protection.
- trivial enumeration attacks that could be used to retrieve customer information (name, address, order, payment details, ...)
- XSS issues that could be exploited by sending crafted URLs to customers
In all cases, I received rather lame responses as if the person in question was completely nonchalant about the issues.
All I could do was to avoid those stores myself.
So far received one response: "We do not even accept credit cards!". Tried to explain to her why foreign code on your site might still be a problem.
Expecting many similar responses. Where possible I contacted their developers directly, maybe they will do something.
For victims added to the list and published within days, the victim is not allowed adequate time time to fix their vulnerability. That does real harm to the victims by inviting attacks before they can avoid the harm the disclosure invites.
[1] https://en.wikipedia.org/wiki/Responsible_disclosure
with credit cards it's like there is only a pubkey and no private key needed to steal!
[1] https://www.cardbenefits.citi.com/Products/Virtual-Account-N...