What can I do to verify that the mobile phone number on the registration form?
User: Website RegisterForm > Enter the telephone number > Phone confirmation code > Membership Ok!
How is this done?
You don't give much information on what technologies you're using, so there might be a better tailored solution for your case, but you'll need to generate your access code (ideally using a secure random generator), configure your backend to access a SMS Webservice like Esendex (please note, it's not free), send the code through it and then validate that the code the user inputs is exactly the one you've generated.
Here you can find a link to their SMS PHP SDK.
Consider using Twillio. They have an API to handle SMS and phone transactions. You can call the API from within PHP, and their rates are like 1 cent per text or less.
Related
I would like to to have a notification system to alert the user via Google SMS system and register user with their phone number. I would like to send the alert when certain condition is reached in a PHP web application. Would it be possible? Could you please give some suggestion?
Yes it is possible. There are apis available for this functionality. You could implement this yourself and you can send text messages via email if you use an api to figure out the phone carrier of the user.
I am building a cross-platform app and using PHP and MySQLi. Users sign up with either their Facebook account or phone number. If they choose phone number, they enter their number and an SMS is sent containing the verification code. The user enters the code and an API token is sent back to be used across the API requests. Tinder (for example) is this way.
I am considering Twilio for the verification.
My issue comes down to the security of this login process. Can a malicious user just rapid-fire the login request that creates a verification code over and over again... sending plenty of SMS and costing me a fortune on my Twilio account? Should I only allow so many attempts? Can a bot just eventually guess the code?
What is the security behind Tinder's API?
things to consider:
1- limit request per phone number
2- limit request per user (by ip)
3- use captcha (only after second attempts to keep your app user friendly)
4- use honeypots
"can a bot guess the code?"
verification codes should have a time constraint. after like 2 mins they should be invalid. time constraint and request limiting should make it very very unlikely for a bot to guess the code.
if you are using laravel it already have rate limiting middleware (limit by ip).
Twilio developer evangelist here.
I agree with all the things that Shalior says in their answer, so I'm not going to reiterate that.
What I wanted to share was this article on falsehoods programmers believe about phone numbers. It is a good reminder that phone numbers don't necessarily uniquely define a user, and worth keeping in mind if this is your intention for a passwordless login.
My problem is this:
I have a survey that is taken by people that they're paid for. I want to avoid the same person submitting the form multiple times. It is a web application.
What I have tried:
I have tried recognizing the IP address from which they try to submit the survey but it hasn't worked.(They could just change devices and so, IP changes) I could try 2FA (where I authenticate using SMS/Voice to phone numbers) but free phone services like Google Voice/Twilio will render that useless. Using a SHA/MD5 hash on a combined key such as phone number and email address still faces the same multiple emails/phone numbers problem. Uber has recently covered up its tracks and devised a way (or a partnership) to recognize Google Voice Numbers. I have gone through the Google Voice API and haven't found a way to find the actual phone number linked to the Voice number.
Is there any full-proof way of doing this?
PS: I am NOT talking about multiple form submissions on a form (say a ecommerce website) which causes multiple charges to a credit card. Please do NOT suggest CAPTCHA.
Scenario: I want to create an app where users register accounts and a server sends them a one time pin to verify their contact details via SMS. User enters the code received to verify their details.
However, sending an SMS costs money but receiving one is free and my SMS gateway lets me read incoming SMS messages.
So I could create a screen in my app that lets the user send an SMS to my gateway with the gateway number and message prefilled (eg. "Hi, please activate my account with code: 34GKTT551T"). User only needs to press send.
Instead of having the user type in a code they've received and verifying the code on the server, my gateway picks up a code sent by the user and sends the message to my server which then verifies the code and thus validates that the users phone number is the one they entered on registration.
Question: Is there anything fundamentally wrong with this approach?
What are the pros and cons of doing things this way? Yes, I know SMS messages can be faked but it's harder than faking an email which could also be used. I would not consider this an alternative to proper 2 factor authentication but this approach worth doing as a lower cost alternative that doesn't require users to do anything else special.
PS. This is my first question on stack overflow so be nice.
No this is not secure as the sender of an SMS can be easily faked. Take these instructions for how to achieve this on Kali OS.
There are also services such as this one.
All it would offer is a very thin layer of security against people who have the user's password but do not know the above information or the mobile phone number of their victim. The phone number of their victim may be achieved via other means such as social engineering. It may work if there is a separate phone used for the sole purposes of 2FA, however why not go with using Google Authenticator API, which is free (Google Authenticator app available for iOS and Android)?
I was following these articles: Verifying Back-End Calls from Android Apps and Stopping Vampires using License Verification Library (from 24:57 to 25:34) to implement an In-App Purchase verification system for our Android apps.
I am a bit confused about how this works end-to-end and what we can assume about the generated token from calling GoogleAuthUtil.getToken() with the first email address found--when AccountManager returns more than one account. My questions are as follows:
Should we assume that any e-mail address used by the user to buy our
app will generate the same token (i.e., same user + app ==> same
token)?
If the answer to question 1 is no, is there a way to launch in-app
purchase for a particular account/email?
It looks like Google is picking the first e-mail address returned by
AccountManager for its in-app purchase dialog. Can we assume that
this won't be changed by the user after in-app purchase dialog is
launched? How do we find out if this changed after the in-app
purchase returns?
What should we store in our database to identify this user? Is email
address and/or token allowed? When does the token expire?
The java-client library looks very promising and powerful at first
read. But, a number of things remains confusing. Is there an article
that describes the end-to-end scenario--from an app initiating a
call to a back-end server through launching the in-app purchase
dialog, getting the result and closing with commits on the server?
What articles are the most useful for accomplishing this on Android?
The main issue we are trying to solve is to to get the full picture.
We've gotten the idea that we can avoid requiring userid/password by using the java client features and using tokens. We have registers our project (both the web app and android app on the same project) per the instructions for Google API Console. We have the php java-client for Google Play Service on our back-end server. We got our Android app to generate a token using the first email address and then call the in-app purchase dialog and handle the user response at the end of the dialog. We've got the parts. Now, we need to glue everything together. We are at the point of integrating with the back-end server. E.g., What is Redirect URi supposed to point to in our server? We've got a php url that we do http post messages to for our server app. We've included the code example for Google API client example--with client-id, secret, simple api key, etc. filled in--as an include to our php. But, what should we put in the redirect uri (we are missing a usage instruction for the example code)?
Also, we want to avoid having the e-mail used for the in-app purchase be different from what we log on our server database as the address the user used to buy our app; if the address is the correct thing to track, we want it to be the same as what was used for the purchase. This could be frustrating for our user if we make this mistake and prevent them from the features they paid for. We don't want to make this mistake and need some clarification on how Google Play Service works. If we initiated the server part of the workflow to get app Nonce / Payload / Credentials for the first e-mail address on the Android device, we would want that address to be used throughout the workflow. If the user changed this along the line, we want to be aware of this and gracefully recover. So far the articles have been helpful but incomplete. Any insight/suggestion is appreciated.