Explanation
I have an API running on Laravel 5.8 that uses Nexmo Verify API in order to send a code by SMS for two things :
(1) User account creation (check phone number before creating the
account)
(2) Forgotten password (check code sent before entering a new
password)
This PHP API is used by an iOS Application and an Android Application.
In the first case (1), I have to check that the phone number does not exist before sending a SMS.
In the second case (2), I have to check that the phone number exists before sending a SMS.
So, I may have two API routes :
One checks if a phone number already exists, so that the mobile applications can display the next page or display an error.
The other one simply sends a sms code to a phone number.
Problem
The problem is that we can have a route that looks like /api/phone/sendcode and anyone can call this route directly without using the mobile application if they find what the endpoint is (it's just an API after all). It can be easy to use this route to spam.
Or, they also could call a route api/phone/exists tons of time to try to get all existing users.
Question
How can I secure the endpoints in order to avoid people using them directly to SPAM or to check in a loop if an account exists ?
I already have a throttling system to block a specific IP address to request an endpoint more that X times in a minute, but I think this is not enough and can be bypassed (using a proxy or whatever).
Also, I prefer to avoid using Captcha.
Related
Firebase phone number verification authentication is triggered by the user from the client-side SDKs on my website I am developing. Is there a way to write code such that the firebase api:
a. sends SMSs to only registered phone numbers (existing registered users) and
b. not send SMSs to unregistered phone numbers (anonymous users)?
This is to prevent data abuse by anonymous users to my website.
There is no way within the Firebase Authentication API to limit what users can authentication through SMS, or any other provider.
The logic here is that in order to know whether a user is authorized, you first have to know who that user us, which already requires them to authenticate.
This does indeed means that a malicious user can make calls through the API with your configuration data. You'd then typically prevent those users from accessing your application by a further check, for example by having the list of approved phone numbers you mention. The difference is that this check happens after the authentication step, and not as part of it.
Firebase has abuse prevention methods in place already, so there's usually nothing you need to do beyond calling the API and protecting your backend resources. If you suspect you're seeing abuse on your project, reach out to Firebase support for personalized help in troubleshooting.
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.
I'm working on a platform which requires users to have access and control of bitcoins that they deposit. I figured it would be better to generate an address per user, rather than a whole wallet.
I need to create a transaction where I can specify the sending address as well as a receiving address. Is this even possible with Blocktrail? If so, how?
This is all being done in PHP.
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.