I’m building an application and I’m thinking about asking user phone number to send a verification SMS. Though, imagine if the phone number is cancelled and attributed later to someone else. Then, the new person would be able to connect to my app in the name of the old one...
So is there any way to prevent this behavior ?
I want to make it like tinder : sign up possible by 2 different ways : (facebook connection and phone number) or (phone number and mail)
I have another question : I see that many sms sending services are not free (all of them actually). If I make an api with these services, anyone can send a lot of http request to it and make me pay 0,05€ times 100000000 ? And I can’t rely on IP adresses because with 3G an ip is not associated with a particular person...
To your first question:
You are describing Two Step Authentication (aka Two Step Verification) which you can read about in the Wikipedia page: Multi-Factor Authentication (MFA):
a method of confirming a user's claimed identity by utilizing something they know (password) and a second factor other than something they have or something they are. An example of a second step is the user repeating back something that was sent to them through an out-of-band mechanism.
You are correct that a phone number can change owners (as can an email address though over a longer time period on average). You are using their phone number as that out-of-band mechanism described above.
If the user has recently authenticated with their password, when you send the user an out-of-band code and they re-type that into an input box you have some degree of confidence that the end user both knows the password and has access to the SMS message and are choosing to trust that association.
You will need to consider if, and for how long, you can trust that association within the security context of the use case.
For example, adding two step verification when detecting the end-user has just authenticated on a device you have never seen before is a nice additional protection. However, using the out-of-band SMS verification in account recover could open up a big security hole. You do not want to bypass the authentication with something they know (password) in a password reset flow by simply having access to that SMS number. SMS is also not an appropriate mechanism for one-time-password (OTP).
If you want to offer you users more protections on their accounts look into implementing true MFA with software tokens (eg. Google Authenticator, Authy, etc.) and hard tokens (eg. FIDO U2F devices such as Yubikey, Google Titan, etc.).
To your second question:
You are correct, IP-based limiting is insufficient. With SMS services you are likely going to be making a server-side API call to the SMS provider. First check to see what security features your provider has out of the box. Next, protect your endpoint that is triggering the API calls to the SMS provider.
Rate limit the number of SMS messages to any one given recipient (eg. no more than X SMS messages to a single number per Y minute window)
Rate limit the number of SMS messages one person can make to different numbers (eg. no more than X different phone numbers per user per day).
Do not allow unauthenticated requests. The user should have already completed the first authentication step (something they know eg. username/password) before performing the out-of-band SMS step.
Protect the SMS form from Cross Site Forgery Requests (CSFR). Your back-end should only make the API call to the SMS provider if it knows the request came from your front-end and not another host.
Protect the SMS form from bot attacks. There are many approaches with Google ReCaptcha being one of the more common.
Related
I am prototyping an automated messaging system with a few pilot companies and about 10 users. They want my system to send status emails on their behalf, from their gmail accounts. This can easily be accomplished when they enter their gmail usn/pwd into my system (it is AES 256-bit encrypted before being stored in the DB). The problem is that the first time my system tries to send a status email on their behalf, using their account, the message is blocked until "Allow less secure apps" is enabled. When they try again, it's blocked again, along with scary warnings being emailed to them by google saying that someone has their google password. Only after they click through that and verify that my system has permission to do this, all is good, no more warnings, and everything works.
I have been researching this and I have found 2 potential approaches for smoothing this process and avoiding the scary warnings to the users:
Enable 2-factor authentication in the google account, and use an app-specific password (per user I think??) to send the emails without any warnings.
Have my system use oauth2 with the gmail accounts so that google no longer considers my app "less secure".
My question is, what is the best approach, and how do I set this up? If my gmail users enable 2-factor authentication, can they store their code into my system, and my system uses that code for future auto-emails? Does it even work that way? My experience with 2-factor auth is that a code is sent to the user's phone each and every time. Is that not the case? Would a stored code on my server (1 per user) work over and over? Does it expire after a certain amount of time?
And my understanding with oauth2 is that my users would need to be actively logged in with their google account and somehow exchange tokens with my server, but I really don't know. Is there some way for my web server (PHP) to implement oauth2 in connection with gmail accounts?
In summary, what is the simplest way to send auto-generated gmails for my users who are paying for this service without triggering scary warnings from google? The volume of emails is low -- this isn't spam -- it's a status follow-up system for the workplace.
You are right on your second point; that is an easy way to accomplish your objectives. You'll first have to authorize your app with Gmail to work with OAuth. You can follow these links to learn how to implement authorization in your server, but you can also enter here to appreciate some examples. When you develop the authorization protocol, you can read the Gmail API to start working with your customer accounts.
my case is simple:
I need an application layer solution to identify and then apply some sort of rule to requests coming from the same origin.
If a guy will request my server from Postman, or from a browser or from a cURL I want to identify this guy and then do something with this information.
In my particular case I want to blacklist a guy who would be attacking my server for sometime.
Is it possible in Node/Express?
There is no uber identifier that comes with a web request that tells you who the user is behind the request, no matter how the request was initiated (browser, cURL, Postman, node.js app, PHP app, etc...).
This question comes up pretty regularly among new web developers. In the end it boils down to two things:
Requiring users to have an account, login to that account in order to use your service, requiring login credentials with every use of the service and then tracking their usage to see if it meets your usage guidelines. If it does not, you can ban that account.
Rate limiting users either by account or by IP address or some combination of both. If they exceed a certain rate limit, you can slow them down or deny access.
A browser provides a cookie so you can attempt to identify repeat users via browser cookies. But, this can be defeated by clearing cookies. Cookies are per-browser though so you can't correlate the same user across multiple devices or across multiple browsers with a plain cookie.
cURL and Postman don't provide any identifying information by default other than the originating IP address. You can attempt to track IP address, but there are some issues with relying only on IP address because corporate users may be going through a proxy which makes them all appear to come from the same IP address. If you ban one user for misbehavior, that may affect lots of other innocent users.
If you look how Google, Facebook, etc... do this, they all require you to create some sort of account and then provide credentials for that account with every request. This allows them to track your usage and manage your traffic if needed. And, for free usage, they generally all have rate limits that limit how frequently you can make API calls. This prevents any single user from using more than an appropriate share of the load of the service. And, it allows them to detect and regulate accounts that are abusing the system.
One step further than this concerns how an account is created because you don't want an abuser to just be able to run a script every 10 minutes to automatically create a new account. There are a variety of schemes for protecting this too. The most common is just requiring some proof that a human is involved in creating the new account (captcha, question/answer, etc...) which prevent automated account creation. Other checks can require a valid credit card, unique email address verification, etc...
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.
I'm working on a simple web service that allows users to sign up for free and upload a small amount of data. I can easily establish a quota for each user, but malicious users could create fake accounts to upload as much data as they like in a denial-of-service attack.
Obviously, there's no perfect defense against this type of attack, but what can we do to mitigate this problem?
Tie it to a more-or-less unique identifier (phone number, bank account number, facebook/google/etc account) or to a finite resource (such as time, by using a captcha).
use a captcha on account creation to ensure that it's a
human and not an automated process.
require a valid email address and require that they click a link in their email to validate that that's their email address and continue the registration process. This cuts down on their ability to create many throwaway accounts because you can limit them to only having one account per email address and they have to then create a new email address for each account they want to create.
When the user signs up, the user supplies a valid email. Most accounts are not enabled until a response has been received, usually by clicking a link in the body of that email. When that click-through is received, you should be able to grab an IP address. That should help you curtail an abundance of casual DOS attacks.
Consider Phone Number Verification
Requiring phone number for account creation is the best approach I've come across; Creating a new email or cycling an IP address is pretty trivial, but genuine sms phone numbers cost money to activate & grant your service the ability to restrict access by country-code.
An important caveat: Virtual phone numbers (like google-voice), temporary-phone number services, & burner phones can make sms-verification ineffective at preventing duplicate user accounts. Depending on your use case, it might be worthwhile to use a service, like Vonage's Number Insight api, that lets you identify those types of numbers.
Authillo is a passwordless authentication provider that prevents duplicate/fake accounts by leveraging sms verification, liveness detection, & facial recognition. Depending on how critical it is that you prevent fake accounts on your service, their base plan might be what you're looking for.
Just log the IPs and assume the same user if the IP does not change within a time interval. This is bad, because it would prevent multiple users in the same house (same IP) but it is a good start.
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.