So after MUCH research online, I'm coming to the one place I know someone will be able to help me!
We have a site that WILL accept credit card payments via PayPal's Classic API. More specifically, we'll be accepting credit cards for recurring payments. I know I have to be PCI compliant, and after speaking to PayPal today, I have been told (in writing) that:
"Once your account has processed over 20 transaction in the last 3 weeks (or 100 in a year), you will be able to register with Trustwave to become PCI compliant."
AND that I
"do not need to prove your compliance before reaching these levels"
Not sure what it is, but something doesn't sit right with me. Mainly, that I think I should be PCI compliant from the get-go. I think what they're saying is that I won't need to prove anything until then, but that I should be PCI compliant.
If anyone could give me a bit of guidance on this, it would be great. Here's a little bit more about our situation:
We will not store ANY customer card details on any system we run.
We send the details to the PayPal API by a regular old HTML POST form.
Recurring payments don't allow for a hosted solution by Paypal, so we are required to do it via our own form.
I'm sure I'm missing something here, but know that someone here will have had experience/be able to point me in the right direction!
Cheers guys!
You do indeed fall under PCI requirements immediately as a web page in your environment captures card-holder data and then transmits (the key term) it to PayPal. PCI/DSS does not have a volume threshold below which it does not apply.
Perhaps the thing that doesn't feel right is that they are happy to brush off any and all responsibility for your PCI compliancy by presenting the option of signing up with "Trustwave" whom I guess will present you with a SAQ to fill in and then take care of your quarterly scans.
Related
Over the past few months random email addresses, some of which are on known spam lists, have been added at the rate of 2 or 3 a day to my website.
I know they aren't real humans - for a start the website is in a very narrow geographical area, and many of these emails are clearly from a different country, others are info# addresses that appear to have been harvested from a website, rather than something a human would use to sign up to a site.
What I can't work out is, what are reasons for somebody doing this? I can't see any benefit to an external party beyond being vaguely destructive. (I don't want to link to the site here, it's just a textbox where you enter email and press join).
These emails are never verified - my question isn't about how to prevent this, but what are some valid reasons why somebody might do this. I think it's important to understand why malicious users do what they do.
This is probably a list bombing attack, which is definitely not valid. The only valid use I can think of is for security research, and that's a corner case.
List bomb
I suspect this is part of a list bombing attack, which is when somebody uses a tool or service to maliciously sign up a victim for as much junk email as possible. I work in anti-spam and have seen victims' perspectives on this: it's nearly all opt-in verifications, meaning the damage is only one per service. It sounds like you're in the Confirmed Opt-In (COI) camp, so congratulations, it could be worse.
We don't have good solutions for list bombing. There are too many problems to entertain a global database of hashed emails that have recently opted into lists (so list maintainers could look up an address, conclude it's being bombed, and refuse to invite). A global database of hashed emails opting out of bulk mail (like the US Do Not Call list or the now-defunct Blue Frog's Do Not Intrude registry but without the controversial DDoS-the-spammers portion) could theoretically work in this capacity, though there'd still be a lot of hurdles to clear.
At the moment, the best thing you can do is to rate-limit (which this attacker is savvy enough to avoid) and use captchas. You can measure your success based on the click rate of the links in your COI emails; if it's still low, you still have a problem.
In your particular case, asking the user to identify a region via drop-down, with no default, may give you an easy way to reject subscriptions or trigger more complex captchas.
If you're interested in a more research-driven approach, you could try to fingerprint the subscription requests and see if you can identify the tool (if it's client-run, and I believe most are) or the service (if it's cloud-run, in which case you can hopefully just blacklist a few CIDR ranges instead). Pay attention to requesters' HTTP headers, especially the referer. Browser fingerprinting it its own arms race; take a gander at the EFF's Panopticlick or Brian Kreb's piece on AntiDetect.
Security research
The only valid case I can consider, whose validity is debatable, is that of security research (which is my field). When I'm given a possible phishing link, I'm going to anonymize it. This means I'll enter fake data rather than reveal my source. I'd never intentionally go after a subscription mechanism (at least with an email I don't control), but I suppose automation could accidentally stumble into such a thing.
You can avoid that by requiring POST requests to subscribe. No (well-designed) subscription mechanism should accept GET requests or action links without parameters (though there are plenty that do). No (well-designed) web crawler, for search or archiving or security, should generate POST requests, at least without several controls to ensure it's acceptable (such as already concluding that it's a bad actor's site). I'm going to be generous and not call out any security vendors that I know do this.
Here's the thing.
were doing some cross-platform game, selling some virtual currency to be used on our game, and life are awesome. Until came the requirements for BI.
The requirements are completely legible - no magic here. Only that with Apple, it's (how to say gently) ...hell.
Here I have to report for every package that was purchased, what is the price that was presented to the user, and what of it was passed to us.
So, OK, after I get a report of a successful purchase and get a receipt
I pass it to my server
I check the receipt with apple, get it decoded
in the receipt I find the package ID - awesome.
But there is no information about sums :o
All this is available when doing billing integration for credit-cards. What would be the equivalent for Apple In-App Purchases?
More info? Ok.
I could cheat a little and solve half of the problem, naming packages like
com.example.vc100
com.example.vc100_promo1
where in both packages the user buys 100 coins of VC, but
vc100 is sold in the usuall case, by the price of some tier that makes sense to our game-balancers, and
vc100_promo1 is sold by promotions by the price of a cheaper tier that makes sense to our marketting.
So, the fallback would be to maintain two lists. one on our servers, and one on the apple back-end, repeating in both ends the relations between a pack and a tier.
Another fallback would be to encode both the VC-sum and the tier in the name. But that would be a partial solution, because we still don't know what price was presented to the user, AND need to maintain a list on our side that would update every-time a price tier is redefined.
Yuck. I refuse to believe there's no better way to do it!
My goal is that marketers can create whatever product-SKU they wish to sell in one place. Obviously, Apple wont let me do that, so at least let it be one list per platform: apple-skus on the iTunes backend, and cross-billing-provider skus in our integration layer for our billing partners, who are much more cooperative than the ...appholes in apple.
Basically, if clients can pull this information and present it to the users - there has to be a way to do it on our servers, and collect this information for BI events.
Having the commission that apple cuts a constant percent from the US price - all we need is to have on our servers the prices for the sold SKU in local currency and USD.
Anybody?
Unfortunately -- incredibly -- Apple doesn't include the price tier as part of the receipt, so the approaches you've outlined are the only options:
The client can store the price tier + local currency price and send it up to the server at time of purchase
The server can maintain a separate list of [product ids -> price tiers], and [price tiers -> local currency price] per tier, both of which need to be kept in sync with iTunes.
It looks like iTunes connect has an (unofficial) JSON API, which could be used to automate #2 (keeping the server in sync with iTunes). I haven't tried it though!
See iTunes Connect API and https://github.com/fastlane/itc-api-docs
so, no long - no answer.
We could not find a way to get this info from Apple in a peer-to-peer request.
What we ended up doing is collect the sums on the client and pass them to the server together with the receipt, protect the values with hashing signature, and send it over ssl.
If there is a better solution - I'd still want to learn about it
So, like any reasonably competent web development shop, we wear cotton gloves when we touch credit cards, and we use Braintree SecureVault to store them so we are clear of PCI Compliance issues.
However now we want to offer a free trial for our service, which pretty much relies on being able to guarantee that a given credit card is only used once for a free trial. Ideally we would be able to hash the credit card number itself to guarantee uniqueness. The problem there is that set of valid credit card numbers is small, so it's going to be easy to brute force the credit card numbers. Salting tactics are useless as far as I can see, because if someone has access to the database of hashes, they will most likely have the code as well, and thus the salting algorithm.
The best two ideas so far are:
A) Keeping the hashes isolated in a set, with no relation to their billing information. Therefore if the hashes are brute-forced, all they have is a list of credit card numbers that were used at some point in time, with no personal information or knowledge of whether it's even still valid. The main weakness here is that we do have record of the last-4 which could potentially be used to match them up to some extent.
B) Hash without the full number and deal with the false positives and negatives. Hashing on name, last-4 and expiration ought to be fairly unique. False positive is like winning the lottery, we can deal with it at customer support. False negative could be induced by modifying the name, we are not clear on what assurances we have about the precision of name matching (potentially affected both by the gateway and merchant account is my understanding), so this could open a loophole.
Thoughts? Suggestions? Battle-tested Wisdom?
High-level: Use Existing Payment Systems
I think that this approach -- using credit card numbers to determine if a user already has taken advantage of a free trial and should be ineligible for a subsequent free trial -- is misguided. Firstly, you will drive away potential customers by requiring a credit card upfront (which many users don't give out unless they are actually ready to buy), instead of requiring it only after the trial period has ended.
Secondly, you are reinventing the wheel. There are a plethora of "app stores" (the Chrome webstore, the Android marketplace, the iTunes app store, etc.) which provide builtin mechanisms for payment and trial periods. Using these systems will give your product increased visiblity to consumers, will offer your potential customers multiple different payment methods (making them more inclined to buy), and will also save you the hassle of implementing this mechanism yourself. Plus, users generally prefer to give out their credit card to the least number of companies possible; not only would you have to implement this complex mechanism yourself, but you would also have to get users to trust you enough to use it.
Lower-level: Implementation Details
Any hash mechanism can have collisions, hence you would still need to deal with this problem. You should obviously use full disk encryption and other best security practices with your servers. The risk of having both the database and the salting algorithm compromised at the same time can be reduced by hosting the backend database service on a separate machine from the one that hosts this code. The main vulnerability of hashing is brute force attacks. And the best way to deal with them is to just make brute forcing expensive enough that it isn't worth the attacker's while. Using a separate salt for each entry (e.g. the customer's name, the customer's zip code, etc. as part of the salt) will make using rainbow tables ineffective. Of course making the data, itself, less valuable to attackers (e.g. not including the full credit card number) is also a good way to discourage these kinds of attacks. In any case, I again advise you to take advantage of the many app stores instead of implementing this yourself.
Forgive me if I missed something, but why can't you just have a table of "UsedCreditCards" that just has a single column, which is a SHA512 hash of the credit card number and maybe the expiration date. This could not be reversed, and by keeping it in another table and not storing any other data about the code, you could easily check to see if a credit card number has been used before.
I am not sure if this would violate PCI or anything (I don't think so, but I could be wrong)
I'm writing a POS application for the iPhone/iPod combination, using the same exact hardware used in Apple Stores:: EasyPay.
Ok, my hurdle is this: how do I identify which credit card type is being used as text is entered in the uitextfield?
I assume I've to use textField:shouldChangeCharactersInRange:replacementString:? However, I've got ideas floating around, but I simple cannot put them together to form code :/
Any help is appreciated!
Maybe I didn't uderstand your problem, but I think you can have a BIN's list (Bank Identification Number). For example, most credit card numbers beginning with '4' are Visa. If they begin with '5', they are probably Mastercard. This is only an example, you should have a complete list to identify each possible card. Unfortunately, a complete and updated list is paid, but you can have a good list searching for free information on the Web, like here.
You can make a reasonable stab at guessing the card type from the first six digits of the card number, which is known as the Issuer Identification Number (IIN)
The trouble is, you'll struggle to get a complete list of IINs. Even the major acquirers struggle to keep an up to date list, as issuers frequently add or remove ranges.
Luckily, the card type shouldnt generally matter. You should be able to perform basic validation of the length, and luhn check digit, then submit the card to the processor for validation and authorization.
You can contact Visa/MC and sign up for the BIN list updates. Visa is free but I believe MC has a fee. Once you sign up, you will get a cd mailed to you with the current BIN ranges monthly.
You can also go through a processor or ISO (independent sales org) if you are working with one. I assume since you have a payment app you have some sort of relationship with an ISO that sets ups merchant accounts for your customers. The ISO should be able to get the BIN list for you from the processor and probably for free.
I think you are on the right track with textField:shouldChangeCharactersInRange:replacementString:, as this gets called each time the user changes the content in the text field. It sounds like you do not actually want to change the textField, but instead want to change another, related control that identifies the card type. You can use the algorithm described in Determine Credit Card Type By Number as a helper function to adjust credit card type accordingly when the user begins typing.
You may want to skip the full verification until the input string has the correct number of characters.
Update: an interesting response in the same thread mentions that actually letting the user pick credit card type is a good idea because it at least shows the user the list of credit cards you accept.
I'm involved in building a donation form for non-profits. We recently got hit by a fast round of low dollar submissions. Many were invalid cards, but a few went through. Obviously someone wrote a script to check a bunch of card numbers for validity, possibly so they can sell them later.
Any ideas on how to prevent or limit the impact of this in the future?
We have control over all aspects of the system (code, webserver, etc). Yes the form runs over https.
When a flood of invalid transactions from a single IP address or small range of addresses is detected, block that address / network.
If a botnet is in use, this will not help. You can still detect floods of low dollar amount submissions and so deduce when you are under attack; during these times, stall low dollar amount submissions to make them take longer; introduce CAPTCHAs for low dollar amount donations; consult your bank's fraud prevention department in case they can make use of your server logs to catch the perpetrators.
Force donors to create accounts in order to make donations; protect account creation with a CAPTCHA, and rate limit donations from any one account.
Raise the minimum permissible donation to a point where it no longer makes financial sense for the scammers to use you in this way.
Instead of CAPTCHAs, which will annoy users, you might want to take advantage of the fact that most people have javascript enabled while bots don't. Simply create a small piece of javascript that when run inserts a particular value in a hidden field.
For those that have Javascript disabled you can show the CAPTCHA (use the <noscript> tag), and you can then accept a submission only if either of these measures check out.
For maximum annoyance to evildoers you could make the difference between the succeed message and the failure message computationally hard to distinguish (say everything is the same, except for one picture that displays the message) but easy to understand for humans.
limit submissions from the same IP address to one per minute, or whatever reasonable period of time it would take for a real person to fill out the form
Raising the minimum donation to a point where it no longer makes financial sense for the scammers to use you in this way will help in general.
This. How many legitimate donations do you get for under 5 bucks, anyway?