This is more of a general question regarding the storage and retrieval of payment information for web commerce applications
Our current approach is to have the user enter their payment details after a redirect on a 3rd party web form, similar to what one might do with PayPal.
In order to make it easier for repeat orders, obviously involves storing payment information details, such as credit card numbers, PII information.
Since this has serious security implications, I am wondering what the general accepted best practices are. Is it basically recommended to handle all of this with other tools such as Stripe? Or have others gone with in-house solution ?
For reference, we are working with Java Servlets/JSP.
Your question is rather wide-ranging, and "best practice" is often another word for personal preference and prejudice.
However...
In most countries, to process credit card details requires you to have an arrangement with your bank (often called "cardholder not present"), and the bank will impose fairly strict security requirements on you when you take up that arrangement. In the UK, these requirements are known as "Payment Card Industry Data Security Standard (PCI DSS)".
There are varying options here - a large online store may invest in storing payment details on their infrastructure, but the cost for meeting the required security standards is significant.
You can also work through a payment gateway - an intermediary company which manages the interaction with the banks. They usually have several different integration options - from "Paypal-like" redirects to an API which allows you to collect the credit card data, and pass that through an API to verify payment. Many payment gateways allow you to store the payment details on their infrastructure (which is PCI compliant), and retrieve a token for future payments.
The process is something like:
customer places first order
customer enters payment details
payment gateway verifies payment details
payment gateway collects payment
payment gateway stores payment details
payment gateway sends token to website
website stores payment token with customer profile
customer places second order
website retrieves payment token
website asks "use previous payment details"
customer agrees
website sends token to payment gateway
payment gateway retrieves payment details
payment gateway collects payment
payment gateway tells website payment succeeded
The general answer for this question is NO, don't store anything. Let's 3rd party payment gateway like Paypal do it for you.
It's not only about security (which you will likely do wrong), it also has to deal with regulations, such as the right to store sensitive data such as credit card.
An alternative, very-risky-and-should-be-avoided answer is to store it in browser's session storage. As for this answer, session storage is reasonably secure. Remember to use HTTPS and have XSS prevention in place. But again, this is not recommended by me.
Related
I have a doubt about stripe subscriptions when using them with connect accounts.
I want to allow my clients to create subscriptions for a product set up by seller. I have seen how to set up the connect account and the application fee for my business, and here comes my question.
I also offer some extra service that is not related to the merchant so the price of these services should go to my business without any repercusion to the merchant but as far as i have seen the application fee goes to the subscription and not per item.
Maybe i could create 2 subscriptions to achieve this, but if i'm right it will create multiple charges on each billing cycle and same with the invoices.
Is there any way to tie several subscriptions or apply a fee to a specific subscription item?
Thanks a lot in advance
No, what your asking is not supported. Your options are:
Create multiple subscriptions (docs), but as you noted this will involve multiple charges
Set an explicit application_fee_amount on each Invoice that is created, based on your business rules (docs)
Create manual transfers for the correct amount after invoice payment events, similar to "separate charge & transfers" (docs)
Option 3 is fairly advanced, and I would not recommend it unless the first two don't meet your needs.
Suppose we have two users doing following operation -
User1 requested to the auth server for access token and granted also.
Now user1 save the token into localstorage/cookie for future api access.
Now User2 approach User1 browswer and get the access_token some how.
Now User2 call the api using user1's access_token and get the access too without login.
Now Can we validate the token anyhow?
You can't avoid that happening. However, the token should have an expiration time, so the attacker will only have access during that time. Also, if you know that a token has been stolen, you can revoke it so it's no longer valid.
You could apply more security measures such as associating the token with a specific IP address, or some advanced services that even use machine learning to detect unusual behaviours.
Confidential information such as an OAuth Token should never be stored in HTTP Cookies unless encrypted. The encryption should be client / session specific meaning that a different encryption key should be used for each client session. If an intruder were to extract the encrypted cookie and attempt to use it for a different session the decryption would fail rendering the cookie invalid.
In your scenario, User B obtains access to User A's session. There is not much protection available. This would be similar to you logging into your bank, leaving your desk for coffee and someone else sits down and starts transferring money using the same browser window that you logged into.
Security is only as strong as the weakest link. Each component must implement strong security. If a single component can be breached, then the other security components might also fail.
There is a tradeoff between very tight security and convenience. Human beings tend to sacrifice security if the processes are too tedious or too difficult or just plain get in the way.
My bank does something interesting. Once I login and keep doing stuff (clicking links, moving the mouse, etc.) I stay authenticated. If I pause for one minute, then the next time I click a link I must reauthenticate. Interesting strategy to detect a person who might have left his desk unattended.
I am trying to figure out where or how i should store application secrets and keys inside a desktop application.
For example a facebook app key or dropbox key and secret.
So I've read that i should hash, salt, encrypt etc etc these values. This is to prevent someone from reverse engineering my code and seeing the keys.
The is all good and well, but with all these methods, i'm just storing a salt or hash value somewhere instead of the key itself, in the end. Surely if a hacker can get to the salt/hash and possibly the source code, they will be able to decrypt the encrypted key and get my password/key/secret anyway?
One option I've read about that seems the most secure is to not store this value in the desktop app at all, but to call a web service to obtain the key (probably encrypted).
But my question is, even in this case, a decent hacker will surely just do a memory dump or something to see what the value returned from the web service is, and then we're back at square 1.
The next best alternative seems to be obscurity.
Am I missing something completely?
On a side note, what use will a facebook/twitter/dropbox/etc key/secret be to a hacker anyway?
Surely they would still need a user's credentials or access token to be able to use it anyway?
Any advice or suggestions will be appreciated.
For each user account generate a new access token for the application when they successfully log into your service. Your login service should be designed much like a login for a website:
The API should only allow a set number (say 5) bad login attempts that reports back to the desktop client that the username/password do not match.
The API should return a token affiliated with only that user when the user successfully logs in.
Use SSL and a localized hashing method to pass user passwords to your API
This auth token provided by your API will only work for the individual account and as such should only allow the user to perform operations to their individual account. So for instance, if a user wants to perform an operation they must be able to provide a valid auth token in order to complete the action. Using this method attackers will still be able to obtain an auth key, but that auth key will only be able to perform operations for the account in which it is generated. It will not be able to perform operations on anyone else account. The idea here is to let them mess with data but to keep the bad activity compartmentalized to one account.
From there, if you do have generic API calls (say an image search) that accesses data from multiple accounts make sure that you are never returning or allowing for any account to access all the data in your system outright. Provide only a limited number of records. In this case the system is still performing its job, but at no point allows all the records in your system to be accessed.
I typically implement a service like this:
User logs in and gets an auth token. I store said auth token in a database associated with that user.
User calls web service with auth token. I lookup user account by the transmitted auth token and User ID (two forms of authentication) and use the discovered user account to perform all operations. I don't just assume the User ID is correct, it has to be the one the auth token authenticated against.
If a user needs to perform a delicate operation like reset a password, my app opens a browser window or browser task in the app where the user can request and administer a reset. I can more-easily secure a web application than one on an unknown client.
Using these methods you should be able to make a fully operational desktop application. There are outliers to this functionality, if you have any post them up in the comments and we can dive further into the problem and see if this solution can still work for you.
I am creating an app store for digital services. I want the user to be able to choose multiple products with different quantity before confirming the order and pay for the services. This requires that something keep state. From REST Wikipedia:
Each request from any client contains all the information necessary to service the request, and session state is held in the client.
I got state that I need to keep somewhere, and I also have a flow. The flow I can mange, but it is the state that I don't understand how and where I should store. The user may add several products to a shopping cart before checking out.
I have thought of a endpoint like this where you post a cart-item object each time you want something.
POST /shopping-cart
But I shouldn't use HTTP sessions if I understand it right? I have seen someone saying to store it in database but would you use a in memory database then? When should i flush the database if the user doesn't confirm and pay? I could need some input on what I should do to keep it simple and RESTful.
I am using Spring 4.x and Java EE for the record.
But I shouldn't use HTTP sessions if I understand it right?
Correct.
I have seen someone saying to store it in database but would you use a in memory database then?
You should keep in in a disk-storage database. This allows you to add nodes to your server without having to worry about routing all requests from one client to the same node.
When should i flush the database if the user doesn't confirm and pay?
That's a business decision.
I came across a serious issue with our payment workflow today.
Once a payment is completed, two things happen:
the user gets redirected to a success-page on our server, the redirect also appends the payment id
the payment provider sends a payment notification including the payment id to our server
When the user gets redirected to the success-page we check whether a payment with the payment id exists. If this is not the case we create a pending payment that we can show to him.
When the payment provider sends a payment notification we check whether there exists a pending payment with the payment id and set it to active, if no payment exists we just create an active one.
Here's the problem: Both events can (and did!) happen simultaniously such that both routines did not find an existing payment and so two payments got created. One pending and one active.
Is there a good way to circumvent this behaviour by possibly using locks or something?
I'm using the default Ebean ORM on a java based play 2.1.0 with a MySQL db.
This isn't a Play thing at all. My advice is to not use locks. If you do then you will limit the scalability of your application.
You need to cope with this race condition. Race conditions will always occur and there's nothing you can do to prevent them. So, embrace them.
In the instance you describe its sounds like the pending state should be overridden by the active state if both exist in the database.
I don't know if this answers your question or not, but here is a link to the Ebean transactions page.