We would like to store user CC information including CVV/CVC for some application logic.
Is that PCI compliant if we
Store CC number on server
Store CVC/CVV on mobile phone
When user approves send CVV to server & perform payment there. CVV is never stored on server.
Thanks
Store CC number on server
Only if you encrypt it and follow PCI guidelines for securing that data (i.e. physical and logical access to the server)
Store CVC/CVV on mobile phone. When user approves send CVV to server & perform payment there. CVV is never stored on server.
No. You cannot store this information, ever.
Related
I'm developing an application using react native and Stripe api in order to handle all the sensitive information about the users and their credit cards.
I'm trying to manage a digital wallet inside the application: one user can add/delete or see a list of their own cards (directly inside the mobile app). I am very confused about this point. For now I'm using my server side as an intermediate between my application and Stripe.
For example to add a credit card I give the possibility to insert card information using a form, then i create the token, and finally I send that token to my server-side (POST /users/cards body:{tokenId}) endpoint which, using stripe.createSource({ customerId, tokenId }), I can save a card into a customer object (In my DB I store only the customer ID).
For delete a card I use this endpoint of my server: DELETE users/user_id/cards/card_id and this endpoint use stripe.deleteCard({ customerId, cardId }) to delete the specified card from customer.
For get the list of cards: GET users/cards/ and the endpoint use stripe.listCards(customerId). My questions are: Can I do this? Is there a better solution? Is this PCI compliance? Can i use my server as an intermediate between my clients and Stripe?
The second point is simple: in a checkout phase (in the client side) how can I let the user to choose which credit cards use for the payment and create a token with that? Can I send the cardId to my server in a POST request? Is it secure?
I want to build a mobile app that requires the number of the user to be filled in. After that, the phone number is sent to a server, the server generates a random verification code that corresponds to this phone number. Then, this verification code is sent via SMS to the user. Next, the user sends the verification code back to the server to ensure that he/she has entered his/her real phone number and not anybody's else.
I was wondering how do you really authenticate against the server if you only have a phone number and nothing else? I mean, in the typical scenario you have a username and a password that are checked on the server and if both of them are correct you can have access to the server. But in the case of a phone-number registration, you have only a phone number and if you authenticate with it only, it means that anyone who knows your number or just picks it out, can pretend to be you.
If you send some sort of a unique device ID, that means that you won't be able to use your existing account anymore, for example, if you happen to change your device with a new one.
So, how do you solve this issue?
The pattern is always: client provides proof of something they have, in return they receive an identifying token. In a typical username/password scenario, this means the user proves that they have a secret (username + password), in return they'll typically receive a session cookie. In your case, the user proves that they are in possession of a specific phone, in return you give them a session token or other identifying token. The client holds on to this token and uses it to identify themselves to the server.
You're relying on the principles of the telephone system to make sure that's a uniquely identifying characteristic. You're basing your security on the assumption that only one person can receive messages for a specific phone number at any one time, and that you need to be in physical possession of the phone at the time of login to complete the proof. Of course you require this proof every time the user logs in. You do not let them register once with an SMS-loop, then afterwards you just ask them for their number and let them through.
If a user wishes to log in, they must proof they're in physical possession of the phone in question using the SMS-loop, then they'll receive a token. Period. That's the way it goes. No other way. The client (app) must hold on to the token for as long as it wishes to stay logged in. Obviously, you probably want this to last for quite a while and not require the user to do SMS confirmations all the time.
This obviously brings us to the topic of token theft, which can be a real issue. The token must be kept secret, since it essentially allows proof-less authentication. You may want to think about signing that token using some unique identifier specific to the device it's for, or encrypting it while it's stored on the device or other measures to make sure it can't be nicked from the device while it is stored on it.
As deceze points out, the best way to ensure the comm is safe is to use a temporal token signed with the device id. If the user logs out, changes device or reinstalls the app then they must go through the SMS verification process again to ensure the SIM cards is still in their possession. Keep in mind that the SIM card and device have different udids. To simplify this you can use RingCaptcha SDK on your app to generate the token, verify the user possesses the SIM card and store that token or id temporarily. Use the phone number as an identifier - similar to a username - and the temporal PIN code as the password. That pair plus the token will give you enough security that the device and SIM card are joined.
We currently use the API for embedded signing in our web application. When reviewing doc reference guide for offline signing, I'd say it's less than crystal clear how that really works. If I'm offline when I obviously can't call the API, so how does one in fact "sign" with DS?
I can appreciate how our client app (again, which currently does embedded signing) can prepare an envelope 'request' offline, and then send that request once we have connectivity. However the REST API guide says the user in fact "signs" the doc while offline -- how does the user ever get to the Docusign interface to do signing?
from the docs
To use Offline Signing, the customer using a client application to
create an envelope on an Internet-capable device, such as a smart
phone or tablet, that is not connected to the Internet and has a
recipient fill out and sign (or initial) the envelope documents. When
the device later connects to the Internet, the client application
uploads the envelope information to DocuSign where it is processed.
Does our offline app (running, say, in/as a Chrome app) somehow connect to local client Docusign software onboard the laptop or mobile device while offline? Any pointers to more complete documentation?
From the docs:
"IMPORTANT: Access to the offline signing capability is limited by
integrator key information. If your integrator key does not have the
correct authorization, you cannot use offline signing. Access to the
offline signing capability will be evaluated on a case-by-case basis."
The reason is because your software would be responsible for providing the legal evidence that the transaction actually happened with the proper security checks. This requires a tighter business arrangement and agreement between your company and DocuSign.
Please get in touch with your business development manager and they can set up a time to talk.
-mb
I am developing a project where I need to send an sms to the contact and if the contact doesn't receives the sms I have to send him another or choose another contact. So, for notifying my midlet of successful sms delivery i'll need to receive and read the sms delivery report.
How to read delivery report using j2me? Or Is there any other way to achieve this?
If you put your application on the Nokia store it will be automatically signed by Nokia to the 3rd party trusted domain, so the prompts will be less. Also i think if you implement SATSA JSR http://en.wikipedia.org/wiki/Security_and_Trust_Services_API_for_J2ME you can talk to the Sim card and get relevant information maybe on delivery of SMS also, but you need the app to be signed to the operator domain for permission. On the other hand, if you have an SMPP connection to a server you can send SMS to users with a port number and also view the message status there.
I am creating a j2me application for mcommerce, which uses mobile internet(gprs). I wanted make it more secured by binding the application to the SIM card and the device. That is a user should be able to login to the system, only using his/her SIM card or from the registered mobile number.
To achieve this I need to fetch the mobile number.
So, on login i thought of Triggering an SMS from the server with a key, which the application reads and uses the key for the entire session. Here the challenge is, that sms should not go to the inbox.
Any suggestions pls?
Yes it can be achieved using the Wireless Messaging API. Have the MIDlet set up a server connection on a chosen port number, then send the SMS to that port number. It will go straight to your app, bypassing the inbox. If you use the Push Registry, you can even make the SMS start your app if it is not running.
It doesn't matter if the user sees the number in his/her inbox.
As long as the key is only used that session, it is her/his responsibility to not share the key with others.
The one thing you make sure is that ONLY the person who owns the SMS phonenumber gets the key and is able to log on.
This doesn't take care of the phone being stolen though.