Here is the scenario:
For a person to become a member of a club, the person needs to register and upon registration the member:
must provide a mobile number
is given a unique card associated with
his or her person
In order for the member to make use of the club computers and services, the person must:
Step 1: get the physical card scanned in front of a machine (RFID) stationed in a specific shop/branch/office
Step 2: enter a one-time-use random 4-digit code received by SMS on the mobile number originally registered. (The code expires after 5 minutes.)
I consider the membership card as something-that-you-own and the random one-time-use code as something-that-you-know. The card and the 4-digit code are therefore the two factors. If the card is lost or stolen, the 4-digit-code is still unknown to the thief. And if the mobile phone (SIM Card) is lost or stolen, the card is still required to proceed in making use of the club services. . Hence the two are independent from each other.
Is this correct?
Thanks
It was concluded that the above scenario is a grey area, leaning however mostly to the conclusion that it is not a 2-factor-authentication scenario.
Rationale:
When someone presents a bank credit or debit card at an ATM, the person has two tools: the card and the pin.
The card is the something-that-you-own; and
The pin is the something-that-you-know.
Therefore the PIN is definitely a knowledge factor...
The above scenario also has exactly the same two tools, a card and a pin.
However
The bank card pin is theoretically stored in your mind while in the above scenario, the PIN is received by SMS.
A mind cannot be stolen. A mobile phone can be stolen. For these reasons, the SMS PIN seems to become an invalid knowledge factor in this case.
The argument that follows is: What is the SMS PIN then? Why send it in the first place?
The SMS Pin seems to be a method to verify that the phone is still in your possession. But it cannot be considered as a knowledge factor per se.
Related
Before you ask for some code, understand that this question is about the implementation technique than code mongering.
OK, so in order to save a customer in stripe connect to charge them later or monthly, here is the prescribed process:
step 1. Use Stripe.js to get card details of the user such as card numbr, exp date, cvv etc. which will be sent to stripe.
step 2. Stripe returns a token corresponding to the card like: tok_xyz, now this token can be used to generate a customer in Stripe and you will get customer id.
step 3. Once you have customer id, you can charge them anytime.
Now I have two questions:
If I provide same card details in the step 1 above, will strip return same token everytime? I am asking it so that I may know how to handle the condition when a user enters same card details twice and I don't accidentally create multiple entries in the database for same card again and again.
It's documented in Stripe that after they issue card token (step 1 above) the CVV remains valid only for few minutes and if you don't make a charge in that time, later on the card will become invalid so do I need to charge the customer right away with a small amount like 0.01$ or something? or when I create customer (step 2 above), stripe takes care of that?
Thank you for any help in advance.
No, you will get a different token and tok_xxx ID value every time. However, there is a fingerprint property you can read from the token and compare to cards saved to the customer, to check for duplicates. There are some good answers on StackOverflow showing examples of that.
True, the CVC value is only held for a short amount of time. If you make a charge during that time, it can be checked by the bank. Creating a charge outside that time doesn't make the card invalid, but it will likely lead to more chance of a decline. Luckily this isn't an issue — when you create a customer object Stripe performs a $0 authorisation charge(as described in the blue box here). So as long as you either charge the token directly, or use it to create a customer object, as soon as you get it, you don't need to think about this.
I have a scenario where the credit card number is being sent over the wire (HTTPS) from application server to browser. Thus, doing a view source of the payment page would display the entire credit card number.
Is this really a security vulnerability ? Since the data is sent over SSL(the entire flow after login is https and the page in question is 3rd or 4th one in the flow), there is no way for man in the middle to get this information. Also,I tested for session side jacking (getting the session id when user is on http and try to impersonate...) - the application is intelligent enough to prevent this attack.
I was thinking in the lines of adding a secure cookie in addition to not sending the entire credit card number over the wire, but is that an overkill ?
HTTPS, implemented properly (most browsers do, check your server), provides complete end-to-end secure delivery of the data. There will be no man in the middle attacks.
We're also assuming your website is safe from cross site scripting attacks.
Still, it's best to show just the last four digits. This is for such cases as someone wanting to do their banking or shopping or whatever from a public location. It prevents those snooping over their shoulder from getting entire account numbers.
It's still an issue if someone want's to enter a new credit card (watch your back), but there's very little reason to show the entire credit card number once you've verified it. Let the customer name the account though, just in case they have more than one card with the same last 4 digits, plus for ease of use.
I'm working on a system that will require a user to log in on a device using an account that they created on a website. Authentication will be over HTTPS, so that is not an issue. The application running on the device will allow in-app purchase using a credit card linked to their account, so it's important that the login credentials are secure enough that it would be difficult to attack using brute-force. The only problem is that the device that the user will be using will have limited user input capabilities (essentially, arrow keys and a selection button).
In this case, a typical username/password may be too cumbersome to enter, also requiring the development of a on-screen keyboard that is navigable via the arrow keys. Users would likely end up creating simple passwords that are easily cracked. However, once logged in, the user will be using an access token behind the scenes so they may not need to enter their password very many times.
The first step is that the user will need to enter their username or ID number. Using a number may be easier to enter, but also easier to guess. I'm open to suggestions in this area as well.
Next is the process of entering a "password". So here are a few ideas that I have, but I'm not a cryptography expert so I don't know how to gauge the level of security.
User must first register the device. This might be a step that I require anyway, for extra security. The device would generate a key that is sent to the server and stored with the account. The key would be required when performing future authentication requests. The user would need to log into the website to approve the device. The device isn't going to have any sort of identifier, so unless you log in soon you wouldn't know if it was your device or someone else trying to spoof you. It would be nice to be able to create some sort of additional identifier, maybe a short code, phrase, or an image is displayed so you can know it's the same device that you just tried to register.
Since entering a text password may be too difficult, as long as the device is registered, maybe a 4 digit passcode can be used when confirming in-app purchases. This may be nice anyway to prevent other users of the device from using your account without your permission. However, if they are watching you enter your passcode, then it's not really good for that purpose anymore.
If registering the device is not necessary, instead of logging in with a text password, maybe the user is presented with images or phrases as options and they must choose the right combination of images/phrases that matches their account.
That's all I've got so far. What are your thoughts? How can I create an easy, but secure, login when in-app purchases are involved?
I have been dealing with limited user input capability scenario. Would you describe the platform your app running on?It helps to fit the solution according to the platform security model.
Update: I hope you are not considering multi-user per device scenario. So, I am assuming that there is one user per device. The second assumption is the device may have a unique serial number that can be accessible through some APIs and the serial number is registered on the server in advance.
At the initial stage, the user generates a random key through the device select button and the app confirms the success of key generation probably it display the serial number (the user may need to register the serial number for latter configuration). Behind the scenes, the app sends the new key with its serial number to the server. The server updates its serial number with the random key in the database entry. The device can block further key generation or may allow until it is finally configured with a dedicated user. The device also persist the serial number with the random key in the local database/file. The user is then login to their account through a web interface to configure the device. For logged in user, the server presents a list of available devices and the user can choose a specific one that belongs to her/him and set four digit pin code. The server performs the following:
Link the user account, the serial number, the random key (the one the device sent at the beginning).
generate a token
generate a key using pin code and the random key as a salt through Password based key derivative algorithm (PBKDF2)
encrypt the token using the key derived at step 3
Update database user row with the cipher token.
The user can sync the cipher token through the device select button. To unlock the app, user must enter the pin code through a simple numeric screen. The app uses the pin code and a random key (persisted at the beginning) and generates a PBKDF2 key and decrypt the token. PBKDF2 helps us to slow down the brute force a bit but it is possible to enforce time based or attempt based lockout as well. For instance after some trail, the app can drop the user credentials and force the user to configure from the scratch.
How do I confirm that a phone number is legit, or that it is connected? I want to prevent users signing up with bogus numbers.
Is there a way to programmatically make a call or something? Or find out if the phone is alive, connected?
The only way you can be sure that the phone number is actually connected is to send them a text-message with a unique verification-key and then have them enter that in your web-form.
Check out VoiceXML. That's a service that allows you to interact with a caller by reading and writing XML.
Also checking if a number is legit or connected isn't the same as proving that's the user's phone number. They could be entering a number of someone else that exists, or even a random phone number that happens to work.
This depends heavily on the country the mobile number is in.
I know a SMS Gateway service in Germany, for example, that checks out whether a number is connected (at least for german numbers, maybe for other european countries too) as an addition to their SMS delivery services. It costs a few cents per poll.
You would have to check with SMS gateways around the world to see what they can offer in that department.
The safest and simplest, as Espo says, is certainly to just send a confirmation SMS.
I'm writing a system where, as usual, the client is asking for a convenience "remember your credit card details" option.
I've told them that this is in all likelihood a no-go. However, I did have a good idea (tm) just now, and seeing that Good Ideas in Encryption(tm) are actually Bad Ideas (tm), I thought I'd put it up for review here and see what holes can be punched through it.
Essentially, I'm thinking of xor'ing the credit card information plus some message signature using a one time pad that's generated per client. This pad is stored as a cookie variable on the client's browser.
Next time that user tries to place a purchase, the pad is sent to the server, and if the server can properly decode its encrypted data, it shows the credit card information as already being filled. (The cc info isn't actually transmitted back). The server will never store the pad in anything more than memory or page file. In fact, I intend to have the pad be sent twice: once upon arrival on the CC page (where the server checks if it should ask for CC information), and once on CC submission to get the actual information.
The user will also be instructed that their information is "partially stored" in their cookie cache, meaning that they will expect that if their cookies are flushed, their CC information is lost.
Let me know where you think this scheme is horribly failing.
Sounds sketchy, and I'm pretty sure you're misusing the term "one time pad."
Instead of going this route, look into using a service like Authorize.net's Customer Information Management. Basically, you give them the card info, and they give you back an ID that you can use to charge the card. The ID is linked to the website's merchant account, and can't be used to charge the card with any other merchant.
It's much, much safer, and should get you the same results.
Note: I'm not endorsing Auth.net or its CIM. It's just the example I'm most familiar with.
Storing the pad client-side leaves it vulnerable to XSS, I would think.
Technologically: flawed.
Legally: probably flawed. talk to a lawyer.
A one time pad only works if the pad is securely kept secret. Storing it in a cookie definitely doesn't count as secure or secret (it's sent to and from the server, it's dropped onto the user's machine, which might be a public terminal or shared machine). This is a really bad idea. It's a clever idea but ultimately very flawed. I suggest you read the PCI compliance documentation and do what other people do which is (generally speaking):
Don't do it.
Use a payment processor that will securely store the CC and handle billing (i.e. PayPal).
Setup a separate and strongly secured payment gateway, this machine only processes credit card transactions, and it in turn accesses a secured machine that stores the credit card data.
Remember that storing credit card numbers will basically violate PCI and will probably violate any merchant agreements and might even be illegal in your jurisdiction (privacy laws, etc.), consult a lawyer please.
Don't do it. Seriously. Find a payment processor who will handle this for you.
If the credit card is being stored client side then you're storing it with the key which means it's vulnerable.
If you are storing the credit card server side then you don't need a key of an encryption key stored on the client.
It sounds like a very dangerous situation if what you are describing is a case where the user is not only not being given the option whether or not they want to store their details but is also going to have them re-populated without having to authenticate in any way. I'd be pretty happy if I came along to an internet cafe and got the credit card details fields pre-populated for me!