The question - Our payment flow is as follows:
1 - Customer adds items to basket.
2 - When viewing basket, customer can see products & also has the option of entering a delivery address AND a billing address, but NO sensitive card details.
3 - The customer proceeds to a new page, hosted on our website. Customer enters sensitive card details here.
4 - Crucially, on pressing "order", the card details are POSTed directly to our Payment Processor. They are NOT sent to our server first.
I'm trying to argue with my merchant bank that we fall under SAQ A - Is this the case?
My reasoning:
1) Our dedicated server is managed by a third-party, PCI compliant host.
2) We never store card details.
3) While the customer enters their card data on a webpage hosted by ourselves, this is dynamically generated and so only exists in the customer browser. On submitting the order, the details are POSTed directly to our payment processor. These details therefore never touch our server and A) Are not stored on the server HDD or database as a Session or B) not even fleetingly held in the server RAM
4) We have passed a number of PCI scans from different authorities to make sure we are compliant and have SSL, TFA for the server etc etc
5) As far as I can see, the two main attack vectors here would be a compromised customer computer (not under our jurisdiction) or if someone managed to gain control of our server and changed how the checkout works. But this surely affects ANY eCommerce site, even one that outsources the pages the card details are entered into to (a malicious attacker with server access could just redirect to a fake set... it's pretty much game over)
However, the eligibility criteria for SAQ A is slightly ambiguous (to my mind anyway). It states:
Merchant does not store, process or transmit and cardholder data on merchant systems or premises but relies entirely on third party service provider(s) to handle these functions *
For me, that 'merchant systems' could include the wider meta-system of the checkout as a whole. In which case, our checkout DOES transmit card details, albeit in what I believe is a secure fashion. However, if 'merchant systems' means, for example, hardware, then we do NOT have any POS systems or servers that transmit details.
I've not been able to get a straight answer out of my compliance liaison. Sometimes they suggest I fill out D, then say it's not applicable for me so say to fill out SAQ C, but then say this is specifically for 'payment applications' such as physical terminals that are connected to the internet.
I think the crucial pivot to our argument is that even though we host the payment pages, the card data never reaches our server.
Any help would be gratefully appreciated. I'd offer a bounty but it won't let me atm :(
Thank you very much in advance!
Sorry to disappoint you, but you are an A-EP.
For SAQ A: Your company has no direct control of the manner in which cardholder data is captured, processed, transmitted, or stored
For SAQ A-EP: Your e-commerce website does not receive cardholder data but controls how consumers, or their cardholder data, are redirected to a PCI DSS validated third-party payment processor.
"In a Direct Post implementation, the merchant website produces the web page that is used to accept payment data, and then passes it directly to the third-party payment processor."
https://pcissc.secure.force.com/faq/articles/Frequently_Asked_Question/Why-is-SAQ-A-EP-used-for-Direct-Post-while-SAQ-A-is-used-for-iFrame-or-URL-redirect
I think that you are right and you should be able to use a SAQ A. However, how is this "3 - The customer proceeds to a new page, hosted on our website. Customer enters sensitive card details here." implemented? Is it a full redirect, an iFrame or something else? The hand off effects things. Remember, it's between you and your bank, if they want you to do a SAQ D, you may have to do an SAQ D.
Cheers,
Nate
I'm new here, can't comment,
I'm trying to figure out myself which SAQ to use A or A-EP in case if I use 3rd party provider.
So for discovered the following:
SAQ A: Your page is NOT originated on your server. You may have a shopping cart and pay button which redirects customer to a processor which hosts a payment form. Example: PayPal Express.
SAQ A-EP: Your page is originated on your server, you fill it in with data and submit via post to a 3rd party. As long as data is not captured by your server and POST payload flies directly to your processor via normal form submit or JS ajax - it's A-EP.
SAQ-D: you submit data to your server. They probably worry that you can log sensitive data, or forward it somewhere else, etc.
IMHO SAQ D is way over complicated for small business that doesn't store data.
Related
Me and my team will be developing a POS system for a restaurant chain.
In addition to a windows application for the POS, the main idea is to make a native (not HTML5) mobile application that will help in tracking orders.
The mobile app should do this -
1. Waiters will take and track order.
2. The manager should be able to check employees's leaves,timings,etc.
On the POS part -
We are thinking to make a particular restaurant work with its local database that will get synced with the central database.
Are we on the right track?
Can HTML5 help us in the mobile application?
How many do you willing to pay for me to give you the architecture? Just kidding.
Think of a retailer that:
Has only 10 kind of items
With sell only 5 quantity of each items each day
That has only 1 staff and it is his/her family
That sell only with cash and not electronic payments
Do you think that kind of retailer need a mobile application which can do POS with cloud computing support? Of course not. He/she maybe only need a book written manually with simple accounting debit credit to track his/her income/expense. But a big company like W*lmart will do.
If you want to make an application, make sure that you has the requirement. Why bother create something that is not needed?
If you want to make a general POS application, collect the basic requirement first. What they need. Will they do input by entering the item code, or scanning using barcode? Will they need to make a payment after the item being entered (typical retailer system), or they need to make a payment after they asked for the bill (typical restaurant system). It will later decide your architecture.
Now asking your question:
In addition to a windows application for the POS, the main idea is to make a native (not HTML5) mobile application that will help in tracking orders
As I have have said before, the architecture will depend on the device used and how the process be done.
The mobile app should do this -
Waiters will take and track order.
The manager should be able to check employees's leaves,timings,etc.
First point is your requirement but 2nd point. What? Track employee's leaves, timings,etc? It should be included in HR module, not POS module. Keep your application scope to the smallest and make sure that each of your module are in same topic.
On the POS part -
We are thinking to make a particular restaurant work with its local database that will get synced with the central database.
Try it and you will know whether this distributed database design are good or not. Search for articles about pros and cons for this design and make sure you know the sequences before starting design.
Are we on the right track? Can HTML5 help us in the mobile application?
It is like a same question as: Can a keyboard help us type? HTML5 is a language used in any web - server programming. It is kind alike of rendering / layout technique. If you want to aim for modern browser such as latest version of firefox, then go for it. But really, do you know how HTML5 can help you, or do you know what are the downside of using HTML5?
Since this app will only be used by employees of the restaurant,
(not by customers), it would be safe to assume targeted mobile
platform, Android or IOS.
Since, the inventory, employees leaves etc is being tracked in
restaurant locally, the idea of using local DB which syncs with
the remote DB seems the right approach.
The menu of items and their codes should stored at central DB
server and fetched from there.
We use a tool that tracks individual users' mouse movements and clicks on our site. Right now it only tracks anonymous visitors, but we're thinking of using it to track specific logged in users' data. We'd be using it for analytics, but we'd like to have the data in case we need to analyze how a particular person uses the site.
Are people, in general, alright with this? Does this constitute privacy infringement?
The short answer is it is your site, for the most part (for now) you can track whatever you want on it.
However, some things to consider...
a) 3rd party analytics tools have their own privacy policies and Terms of Services that may or may not allow this, so if you are using something like Google Analytics, Omniture SiteCatalyst, WebTrends, Yahoo Web Analytics, etc.. then you need to read over their Privacy Policy and Terms of Service to make sure you are allowed to track this sort of thing. Offhand I don't think any of the ones I mentioned disallow tracking mouse movements/clicks specifically (and in fact, some of them have features/plugins for it, called "clickmap" tracking, or similar), but some do have restrictions on other data you may couple with this. For example, I know Google does not allow you to associate any data with the user's IP address. You cannot send it to GA in a custom variable, nor can you store it on your own server in any way that you can associate it with data you send to GA (for example, storing the user's IP in your own database along with a unique id, and then sending the unique id to GA, where you can then lookup IP by that unique id).
b) Privacy is indeed a concern that is currently being discussed by the powers-that-be, and your ability to track certain things may indeed be limited in the future. For now, it's mostly about personally identifiable information, and it's mostly happening in Europe, and tracking mouse movement/clicks generally isn't personally identifiable, but who knows what the future may bring.
c) Make sure you understand the costs involved in tracking mouse movements/clicks. In order to track something, a request has to be made, data sent somewhere. The more granular the data, the more requests and/or data needs to be sent. Whether it is your own baked up tracking solution on your own server or a 3rd party, this will cost something one way or the other. Imagine sending a request to a server for every x,y position of the mouse as it moves...this could quickly add up, and a lot of 3rd party solutions place a limit on how many requests can be made per visit(or) or day on an account.
d) On that note, if you are using a 3rd party solution, tracking something this granular may affect tracking more important stuff. As mentioned in "c", many 3rd party solutions limit how many requests can be made per visit(or) or day on your account, etc.. and if you hit the limit, any requests after that won't be tracked. Imagine if you have tracking on a sale confirmation page, tracking details about a sale made, which is very important tracking, being tossed out because of too many requests of mouse movements on some random page...
e) On that note... consider how actionable tracking mouse movements and clicks really is to you. This is a question you have to really ask yourself whenever you want to track something: "How actionable is this?" Basically, imagine yourself having the tracking in place and looking at the data...then what? What will you do with that data? Assuming the ultimate goal is to make more money, increase conversions on your site, etc.. do you really think knowing the paths a mouse cursor took on a given webpage will help you increase sales/conversions? How will you be able to know if the mouse movements are related to content on your page, or if they were just some random jerks/movements while reading content or making room on a desk, etc..? At best, the data will be polluted...
Clicks on links or specific action buttons on a page? Sure, those are certainly worth tracking. And most 3rd party solutions automatically track a lot of that stuff, or offer custom coding solutions for manual wiring up of things. And there are plenty of reports that can be made showing activity from them.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I am at the first experience of releasing my windows application and I don't have a cue how I should move on. Here my question:
I have my own website running on hosting. I would like to implement a customer
portal so after receiving an order I will provide a username and password via email
where users can download the activation code. I know that this is a big question...How to protect my application against duplication? Do you know what is the "best" solution to apply license system to my software?
How I can force the application to be excuted just on specific pc? Is it complex to achive?
In this scenario should I create a new build for each user so the activation key will
unblock just the right build?
If so I understand that each profile will have its own build file along with activation code and a sort of service agreement information (i.e. 1 year of free updateds).
Again I see it to complex to manage, for every changes in the application I need to compile, build and upload new version...? Ok... my application right now is a simple exe file with some folders and xml configuration files but what in future...?
Is it possible just to share among all user a single application file which can be activated by using the user activation code (in this scenario user will have his own profile just for activation key and SA information). what about security? if someone share the activation code I guess the application can be unblocked anywhere.
Should I implement the customer portal on a dedicated server (i.e) ? I don't have possibility to install my own server. What do you think about virtual server on ISP?
What about invoicing and ordering process? You think that an ecommerce commercial solution is a good choice? For istance I was thinking to get order via email or fax and then process the license (still don't know how) and send invoice whith information for payment (i.e wire tranfer). What do you think?
If the software it would cost (still don't know the price) let's say less then 30 dollars does it make sense to use as payment method a wire tranfer? What about share-it.com? Is it safe? Do they also handle customer portal?
Thanks a lot.
The usual way to prevent users from just replicating your application on many machines is 'node-locking' - at runtime the application checks that certain machine parameters match the values recorded in an encrypted license key or activation record. The Ethernet MAC address is a popular locking parameter, but this is not a good choice as on some systems the MAC address can be set or spoofed. A combination of parameters such as Windows ID, machine name, perhaps user log-in name etc. is more secure.
To issue a license you either request these details from the user or have them run a small utility that writes them to a file they send to you. You can then encrypt them in the license key, which can also contain other information such as a trial or subscription time limit, feature configuration info etc.
Alternatively, all this can be done automatically using [product activation][2]. When your application first runs it connects to a hosted license server, checks it is a valid license, and automatically reads the names of the locking parameters on its host, so it can then encrypt them and persist them in a local file it then reads each time it runs after that (so the app does not need to connect to the server again after the initial validation). If you go the activation route it is much more convenient for you and your users.
Whatever route you go, you need to think about:
- Integration with your chosen ecommerce provider/payment processor?
- How to handle users who don't have an Internet connection?
- How to support users who want to relocate their license, perhaps because they bought a new system? Can you ensure they have only one copy active at any one time? (and you may also want to limit how often they can relocate their license).
- If you lock to several machine parameters, can your locking system accommodate the user upgrading part of their system, so potentially causing one of the node-locking parameters to change?
- If the user's system crashes, how can they get their license running again on another machine?
- How do you issue trial licenses?
- How do you protect against people who try to hack your license protection?
- Might you in future want to configure features in your product e.g. offer different price points, or different combinations of features to different types of users. Can your licensing system handle this?
All these issues and more have of course already been considered and resolved by competent commercial licensing systems.
i would go with similar system to what i have seen used by Nod32 ( which is why i don't use it anymore, but still suggest to buy for everyone else ).
Application has two states: demo and full.
You can use the demo version for time period of 30 month.
And each application has a product key, which is daily verified against remote server. If verification fails, application slips back into demo mode.
If the verification server is unreachable, you show user a message that "verification server unreachable, check your connection or verify manually". Then try again in an hour. If for .. lets say .. 3 days application hasn't been verified. It does into demo mode.
If user, which has connection issues clicks on notification bubble, he sees a view containing information about how to verify manual or button for "try again".
For manual verification you have a generated code (based on his hardware data), which he can enter in your website together with his product key. And get a number for manual verification.
my 2 cents.
How I can force the application to be excuted just on specific pc? Is
it complex to achive?
You can store his computer ID/Key pair in your database.
In this scenario should I create a new build for each user so the
activation key will unblock just the right build?
No. Definitely you do not want to create 1000 builds for 1000users.
If so I understand that each profile will have its own build file
along with activation code and a sort of service agreement information
(i.e. 1 year of free updated).
It is easy to manage it with a right tool. You can ‘bind’ each key to a specific version range of your product (say v1.0.00 – v2.0.00) or specify the validity period of the key ( SaaS scheme)
Is it possible just to share among all user a single application file
which can be activated by using the user activation code ..?
Yes. It’s called floating or network licenses.LAN license server allows to run some limited number of product’s instances in corporate network. This approach is widely used by corporate customers.
Should I implement the customer portal on a dedicated server (i.e) ? I
don't have possibility to install my own server. What do you think
about virtual server on ISP?
It depends on what you mean under ‘own server’. You can’t run separate daemon/process on shared hosting, you need VPS or dedicated server. But you can use the solutions that are present on the market already.
Why do you need to implement activation system yourself? And run servers yourself? It may appear a far more complicated and costly as it seems.
ActivationCloud https://activation-cloud.com provides a good set of features that can fit needs of ISVs that is selling software to home and corporate user. Consider to use it.
Read my question "A licensing system for my (WinForms) application. Would this be secure enough? (Within reason)"
I listed a few possibilities.
Mainly, I noticed that you wanted the program to be only runnable on a specific PC, for which I used a function which returns a unique code for each PC, and required it to be the last 5 characters of the Product Key.
Hope this helped. :)
I have a service which process emails in a mailbox and once processed, stores some information from the email in the database. At the minute the schema looks something like:
ID
Sender
Subject
Body (result of being parsed/stripped to plain text)
DateReceived
I am building a web front-end for the database and the main purpose of storing the emails is to provide the facility for users to look back and see what they have sent. However, another reason is for auditing purposes on my end.
The emails at the moment are being moved to specific mailbox folders. So what I plan to start doing is once the email is processed, record it in the database and delete the email from the mailbox instead of just moving it.
So a couple of questions...
1) Is it a good idea to delete the actual email from exchange? Is it better to hold onto it just in case?
2) To keep the size of the fields down I was stripping the HTML out of the emails, is this a bad idea? should I just store the email as it is received?
Any other advice/suggestions would be great.
In both cases I think you should hold onto the original emails. Storage is cheap, but if disk space is really an issue look to compression rather than excision to solve it.
Both your of your use cases (historical record and audit) will be better served by storing the complete unabridged email in the database. Once you start tampering with the data, albeit "just" removing formatting, it becomes difficult to prove that you haven't edited it in other, more significant ways. Especially if you have deleted the original email instead of archiving it.
You don't say what business you're in, but the other thing to remember is whether there are any data retention policies active within your organisation or in the wider jurisdiction. Compliance is becoming gnarlier all the time.
I would maintain the messages on the Mailbox on a specific folder as you are doing and probably wouldn't even save anything on a database given you can access the Mailbox from within your application.
The Exchange team over the years has developed several APIs for accessing the Mailbox's contents.
With Exchange Server 2007 and 2010, the recommended API would be Exchange Web Services which can be used from any language/environment that is capable of accessing Web Services.
If you are developing with a .Net language (C#, VB.NET for instance), your best bet would be EWS Managed API.
If you are really going to do something meaningful with the body, you can save the results as named properties (extended properties in EWS parlance) on the message itself.
There are other APIs with corresponding functionality for previous versions of Exchange.
Premise: The requirements for an upcoming project include the fact that no one except for authorized users have access to certain data. This is usually fine, but this circumstance is not usual. The requirements state that there be no way for even the programmer or any other IT employee be able to access this information. (They want me to store it without being able to see it, ever.)
In all of the scenarios I've come up with, I can always find a way to access the data. Let me describe some of them.
Scenario I: Restrict the table on the live database so that only the SQL Admin can access it directly.
Hack 1: I rollout a change that sends the data to a different table for later viewing. Also, the SQL Admin can see the data, which breaks the requirement.
Scenario II: Encrypt the data so that it requires a password to decrypt. This password would be known by the users only. It would be required each time a new record is created as well as each time the data from an old record was retrieved. The encryption/decryption would happen in JavaScript so that the password would never be sent to the server, where it could be logged or sniffed.
Hack II: Rollout a change that logs keypresses in javascript and posts them back to the server so that I can retrieve the password. Or, rollout a change that simply stores the unecrypted data in a hidden field that can be posted to the server for later viewing.
Scenario III: Do the same as Scenario II, except that the encryption/decryption happens on a website that we do not control. This magic website would allow a user to input a password and the encrypted or plain-text data, then use javascript to decrypt or encrypt that data. Then, the user could just copy the encrypted text and put the in the field for new records. They would also have to use this site to see the plain-text for old records.
Hack III: Besides installing a full-fledged key logger on their system, I don't know how to break this one.
So, Scenario III looks promising, but it's cumbersome for the users. Are there any other possibilities that I may be overlooking?
If you can have javascript on the page, then I don't think there's anything you can do. If you can see it in a browser, then that means it's in the DOM, which means you can write a script to get it and send it to you after it has been decrypted.
Aren't these problems usually solved via controls:
All programmers need a certain level of clearance and background checks
They are trained to understand that rolling out code to access the data is a fireable or worse offense
Every change in certain areas needs some kind of signoff
For example -- no JavaScript on page without signoff.
If you are allowed to add any code you want, then there's always a way, IMO.
Ask the client to provide an Non-disclosure Agreement for you to sign, sign it, then look at as much data as you want.
What I'm wondering is, what exactly will you be able to do with encrypted data anyway? Pretty-much all apps require you to do some filtering of the data, whether it be move it to a required place, modify it, sanitize it, or display it. Otherwise, you're just a glorified pipe, and you don't have to do any work.
The only way I can think of where you wouldn't be looking at the data or doing anything with it would be a simple form to table mapping with CRUD options. If you know what format the data will be coming in as you should be able to roll something out with RoR, a simple skin, put SSL into the mix, and roll it out. Test with dummy data in the same format, and you're set.
In fact, is your client unable to supply dummy data for testing? If they can, then your life is simple as all you do is provide an "installable" and tell them how to edit a config file.
I think you could still create the app in the following way:
Create a dev database and set up a user for it.
Ask them for: the data type, size, and name of each field that needs to be on the screen.
Set up the screens, create columns in the database that accept the data type and size they specify.
Deploy the app to production, hooked up to an empty database. Get someone with permission (not you) to go in and set the password on the database user and set the password for the DB user in the web app.
Authorized users can then do whatever they want and you never saw what any of the data looked like.
Of course, maintaining the app and debugging is gonna be a bitch!
--In answer to comments:
Ok, so after setting up the password for the Username in the database and in the web app's config, write a program that connects to the database, sets a randomized password, then writes that same randomized password to the web config.
Prevent any outgoing packets from the machine except to a set of authorized workstations - so you can't install your spyware.
Then set the Admin password on both servers to the same random password, then delete all other users on the servers, delete the program, and delete the program source code.
Wipe the hard drives of the developer machines with the DOD algorithm, and then toss them into an industrial shredder.
10. If the server ever needs debugging, toss it in the trash, buy a new one, and start back at #1.
But seriously - this is an insolvable problem. The best answer to this really is:
Tell them they can't have an application. Write your stuff on paper. Put it in a folder. Lock it in a vault. Thrust, repeat.
Wouldn't scenario 3 just expose all the data to the magic website? This doesn't sound like a solvable problem (at least I can't think of a solution).
Go with whatever solution is easiest for you to implement, I think the requirements show the the client does not understand software development and so it should be easy to sell any approach you take.
I have to say I really don't like the idea of using JavaScript on the client to decrypt the data. That is a huge hole as any script (hacker, GreaseMonkey, IE7Pro, etc.) can access the DOM and get data out of the page.
Also, it is very hard to get around the problem of key stroke loggers. If you throw those into the mix, then your options are limited. At that point you need a security FOB such as RSA (commonly used with corporate VPNs) to generate truly random PINs. That will probably be expensive, and it is a pain, and I have only seen it used with VPNs but I assume it could work with websites as well.
As far as the website, I'd stick with HTTPS and find a way to encrypt/decrypt through the WebServer rather than relying on JavaScript. The SSL traffic isn't very prone to sniffing (very difficult to decrypt), so that allows the encryption and decryption to happen server-side which (IMHO) is more secure.
Look at banking scenarios and other financial institutions for a starting point, and then go from there. Try not to over-complicate if possible.
You can't guarantee against hacking into the data as long as you have access to the server it lives on. So tell the employer they have to host the data somewhere else and grant access to the client's browser via a secure HTTPS connection.
You can design your web page to dynamically load an XML data stream securely, and format it into a web page using an XSLT script on the client.
See http://www.w3schools.com/xsl/xsl_client.asp for examples
That way you produce the code, but you never have access to the data. Only the user has access to their own data.
As for how the employer is going to host the data without granting any IT people access to it, that's their problem. It's a foolish requirement.
I think that I'll just tell them that they either have to trust a couple of us to have access (and not look at it) or they don't get a project.
Thanks for the answers. Feel free to post more thoughts if you have them.
You can never have 100% security, and extra security comes at a cost of speed/price/convenience etc.
Let's suppose you take scenario 3 - one of your programmers can use social engineering to get the password from one of the users. Goodbye security.
There's no point having a high-security iron door as a gate if people can just walk around it. Just implement a decent level of security.
(They want me to store it without being able to see it, ever.)
Hey, the recording industry wants people to be able to listen to their music, but not copy it. Sounds like they should get together sometime!
Their idea won't work for the same reason DRM doesn't work: the trust chain is inherently compromised. Encryption examples often use Alice, Bob, and Charlie where Alice is trying to communicate with Bob without Charlie listening in. With DRM, the trust chain is compromised because Bob and Charlie are the same person. With your situation, Charlie is the guy writing the software that Alice and Bob use to communicate. There's an implied trust, because if you don't trust Charlie then you can't trust Charlie's software, either.
That's the root of the issue: trust. If they can't trust the programmer, the game is over before it starts.
There are lots of options based on what their goal really is, but I am confused by their paranoia, er, intent:
Is this their (and end-user) data that they wish to keep private or end-user data to be kept private from everyone?
Is it just that your (or any contracted) company is suspect?
Are they afraid of over-the-wire snooping?
Are they afraid of DOM access through JavaScript or browser plugins?
Are they planning staged deployment? In that case you work on test/dev server w/o real data but have no access to the production server with the real data, and DNS logging and/or firewall rules inhibit all of your hacks from working undetected.
Ultimately if the data is stored in a DB then the programmer and DB admin can, by working together, get it. Period. A good audit should uncover that, though.
If this is truly a requirement, the only way to guard against this is to hire an outside firm to audit the code prior to releasing the software, and that's going to be very expensive.