building a server for an app and one of the steps of the registration in the app is to enter a phone number verification code. The verification code will be sent to the phone through sms and the verification code needs to be entered to continue the registration
The app will send a request to the server and is it possible for someone to find out the url and keep sending fake phone verification code requests to the server? How do you prevent the attack?
I assume you are doing this to confirm that the phone number that is being registered is real and belongs to the person who is registering.
Scenario 1:
-Legit user registers
-Legit user receives an sms
-Legit user sends the verification code to server
If code matches the one that was sent then activate the user
Scenario 2:
-Attacker registers
-Attacker does not receive an SMS because he entered a phone number that is not his.
-Random person receives the SMS
-Attacker starts DoS against verification server and tries to guess the code.
The DoS problem in this case can be solved with simple block after X failed attempts. For example, store each failed verification attempt into a table and when there are 5 failed attempts for an account, block the verification for X minutes. This is similar to failing to login with username and password several times. The verification code must have enough possible combinations so that a brute force attack is not viable.
The other problem is that your service could be used to spam random people with the verification SMS. You'd have to limit registrations per IP per X time interval or something similar. You could also use captcha to prevent automated registrations.
Scenario 3:
-Attacker registers
-Attacker entered fake phone number so nobody receives the SMS
-Your SMS server get's delivery failure of SMS so nothing really happens. The verification code that was used to send the SMS is invalidated.
I hope this was somewhat helpful and I understood your intentions correctly.
Use a CAPTCHA to prevent automation.
Limit frequency verification requests for a single number, ideally using exponential backoff.
Don't forget that the verification endpoint also needs securing; you must limit the number of attempts for a given verification code or use a long enough verification code such that it doesn't matter.
Related
To send sms/text via email to a verizon number you can email PHONENUMBER#vtext.com. To send it to att number you can email PHONENUMBER#txt.att.net . This requires knowing which mobile operator the phone number belongs. Is there any way to send sms/text to a number without knowing the operator the number belongs to.
If there is some such third party services, how do they implement this service. Do they email all the operators and hope that it reaches through atleast one of those emails OR do they use any sms gateway?
Twilio developer evangelist here.
Using the Twilio SMS API you can send messages to numbers all around the world. This is not using the often undocumented and potentially flaky phone number email scheme. Instead Twilio has deals and connections to carriers and other partners that we use to route messages around the world to the destination hand sets. We call this the Super Network and you can read more about it here.
I've an Azure AD B2C setup that no matter which email I insert in forgot password email's field it will send the verification code email to that email.
Even if the email doesn't exists in the Users list.
Is this the default behavior?
This is the link I have for recover password
Is there any missing property in the url that force check if the email exists in User list ?
I can confirm the behavior but I couldn't find any reference on why exactly it works that way. Like many things in security, I'm pretty sure it's a design trade-off.
Some services (e.g. Evernote) do the same, i.e. they send a password reset email no matter if the address is registered with them or not.
On the upside, this is an early alert for the user that someone is trying to get access their (nonexistent) account, so a phishing attempt coming from a different website is likely.
The problem is that the user gets an unsolicited email message, and if somebody wants to annoy him/her, all it has to do is to send multiple reset password requests. The user is helpless, there's nothing he can do to stop the emails. So I presume the service mitigates this by limiting the number of reset password requests to a reasonable amount (say max 10/hour, but no more than 3 in any 5 minutes).
Other services (e.g. Dropbox) take the other approach and only send email messages to addresses registered with their service.
this prevents the "email bomb" issue
on the other hand, it doesn't alert the user about the login attempt
Like you, I would argue that the latter approach is better, as the only benefit I can see in the former one is the "early warning" issued to a user that's not even registered with your service. Also, understanding the early warning requires some user sophistication. But obviously Microsoft went the other way.
There's a Password Reset item in the Users blade, but the only options are None and All. Interestingly, the tooltip on this option mentions an nonexistent "Selected" option, so some more fine-grained settings may appear here in the future.
If you want to exists if the users exist before sending messages then you have to edit the SendCode Action . So it will only send verification code when user exists in B2C side.
Below is the very good link which can help you with that.
https://github.com/azure-ad-b2c/samples/tree/master/policies/pwd-reset-email-exists
It is by design. And it will try to send out the verification code without validating whether email exists or not.
By considering security measures this is how it should work.
So I'm writing a mobile app and have reached a point where I need to allow users to register a username. I'm doing this by asking for an email address, username and password.
Typically, it's been normal to set this sort of thing up on the web by having the user confirm his email address by clicking on a link sent to his inbox.
Needless to say, on a mobile app this is a bit clunky as the user will be redirected out of your app and into his browser.
So I had a look at how other mobile apps are doing it (WP7) and was surprised to see that DropBox and Evernote both allow you to sign up without confirming your email address. The end result of this is that I was able to sign up with completely bogus email addresses and/or valid email addresses that don't belong to me.
I assume this is done on purpose.
Your thoughts?
I came across the same issue when writing a social networking style app. I chose to have the user create a username and then provide and email and password. I do not verify the email address and I've never attempted to send any email to them (yet).
What I would suggest would be alternate ways to validate a users email address. My app allows users to do Facebook Connect. All they have to do is log into Facebook, and the app talks to Facebook to confirm that they are using a valid email address. No need to verify it with a URL in an email.
I believe Twitter has a similar service and there may even be a few others that provide an API.
I've also discovered that a lot of people just want to tinker around in the app and not create an account at all. It's definitely a balancing act
I'd say it depends on your app and how important it is to ensure users have valid email addresses. In an app I'm creating now, we want to discourage users from signing up with multiple bogus accounts (because our system could be gamed that way) so we're not allowing users to log in until their email address if verified. On other sites however, it might not be such a big deal so why bother users with that extra step?
As for a mobile device, I don't see why you can't still send a verification email that sends them to your website to verify their email address. There are plenty of mobile apps that also have a website users can log into to manage their account.
Another option is have multiple "states" for users. Before they validate their email, they are in a "pending" state. Once they click it, they're in an "active" state. If you store the createDate for the user, you can periodically remove pending users older than 1 week (or however long).
The bonus is that you can easily add more states, such as suspended or deleted.
Personally, I wasn't too happy for users to create accounts with any old email address.
I think a few decent options are:
send a confirmation email with a link that uses a Custom Url Schema to redirect back to the app (although this is only good if they use the link on the same device)
send a short PIN in the email for them to enter back in the app.
send a confirmation email with a web link, have your server confirm the valid email/token, and have your app check the account status either periodically or with some sort of realtime tech like SignalR or Firebase.
I prefer the last one, although hardest to implement. A user might well have their phone in their hand and their laptop next to them, register in the app and try to click the link in the email that just showed up on their laptop. I like the idea of the app then just "knowing" that they've validated.
Do you have a web server? Write a web service that does the validation for you on the server side, and sends back the result.
Either you can use some platform, such as Facebook connect as #Brian replied above, or you may give users a reasonable timeframe to verify, for example, a few days or even a week. After that, the account gets removed.
You can even have your app issue notifications to remind the user to verify his account (such as every day, or on the last date of the verification.
Don't ask for email confirmation on mobile and allow the user to use the service. When the user is using a PC, then ask the user to confirm his email.
I won't defend my recommendation because most of the solutions here are valid. There isn't one correct way. You asked for ideas and here's one.
A good strategy is to allow people to use as much of your app as possible given the amount of data they've provided.
For example, in the case of a newsreader you might let someone browse your app without registering, then require an account for offline syncing, and a verified email for alerts. Always give people a good reason to take the next step, and build engagement first, then people will forgive you pestering them later.
Someone invited me to be a developer on his app. I did not get the email invite?
I have had others invite me and it works (and works well!)
We got around the problem by having an invite sent to another account. That works for now, but I really need the invite to be sent to the correct account.
Gary
The question is borderline off-topic in that it's not usually a programming question, but it comes up so often, from programmers and the customers we support, that I wanted to put an answer here in the hopes that it would be helpful.
I see that it was in your spam folder, which is one of the more common causes of "lost" emails.
In short, when an email is sent from one server, it goes through several other servers and routers on the way to the final user's PC.
Any one of the following conditions could cause a sent email to not reach a recipient:
Blocked Outbound Mail - The sender's company/business/ISP has email scanning software that scans outbound email, and blocks suspicious outbound emails.
Our workplace has this to limit sensitive data being sent out accidentally, to block outbound infected emails sent from infected PCs.
Relay Server Permissions/Configuration - Your code is sending through a relay server that has rules blocking unauthorized use of email relay functionality.
In most shops with good security consciousness, email servers are configured to disallow email relay except for known IP addresses and/or known, explicitly authorized users.
External party blocks the email - The sender's company has been blacklisted.
Blocked Inbound Mail - The receivers company has email scanning software that scans incoming email (similar to #1) to block malicious/non-work related/bad emails from reaching the recipient's inbox.
Receiver's Spam Filtering - The receiver's email inbox has spam mail filtering, which may automatically move the email to a spam folder, delete them, or other action depending on how you have it configured.
Receiver's Inbound Mail Rules - Similar to the above. The recipient may have rules defined that block, delete, or move emails.
Outlook allows this, as do other email clients. Emails can match the patterns set for existing rules and result in false positives that trigger the rule execution.
Human error - the sender sent the email to the wrong email address.
Human error - the recipient accidentally deleted the email and just didn't see it. (You'd be surprised how often I've seen this.)
Bad programming - there was an error sending the email, but the exception handling ignores the error, so nobody ever knows any better.
Only #9 is actually a programming issue, and it's also (in my experience) the least common. Odds are that the problem has nothing to do with code that you'd be writing.
I'm sure there are more, but these are the ones I've seen the most frequently. I'll add as I think of others.
I have an application that runs on Windows Mobile 6 Professional PDA devices. The application is installed by browsing a url from the device and downloading a cab.
Users capture information in the application and this is then replicated back to a SQL 2005 server using merge replication and IIS v6.
Although the user needs to log into the application on the device anybody who knows the url could download and install. Also if you know a users password anyone with a device could update that users information.
I would somehow like to authenticate the devices either at the installation or replication stage (or both).
Is it possible to authenticate a device based on serial number or IMEI (mobile phone ID) number?
Is there a way to load a certificate onto the device so only certificated devices are allowed to connect?
I want a system that is not too hard to implement and support. The users must be able to update their own devices and they are not very good at remembering complicate procedures or password.
One possible solution would be to send the unique device id as part of authentication. There's a post on using GetDeviceUniqueID on the Windows Mobile Team Blog.
You could store this unique id when the user first connect to the server and verify it prior to each merge.
This approach helps to ensure that the user logging in is doing so from their own phone. It solves the problem of a remote intruder downloading your program to their own phone and logging into a legitimate users account. Of course, if such an intruder has access to your users phone AND password, all bets are off.
You have conflicting requirements:
The users must be able to update their
own devices and they are not very good
at remembering complicate procedures
or password.
and:
Also if you know a users password
anyone with a device could update that
users information.
If your users can only (barely) be expected to use a password, then you cannot expect to be able to protect in any case against anyone else who has their password.
There's no 'magic' authentication that will tell you a particular user or device is legitimate beyond what you provide.
You can password protect the download, you can load certificates, you can get the PDA information (and even the cellular information), but unless you add another authentication mechanism, at the end of the day all you've got is a password.
The password is your weakest link, and you seem to be indicating that you can't provide more strict access, but you somehow need it?
If you have another authentication channel (phone, email, SMS) then you can provide a more robust, meaningful authentication.
For instance, you could make your program operation dependent on a "public.key" file with a per-user public key that your server requires for use. Once the user logs in to your website, have them give you their phone number (so now you have the phone number and the password) and send an SMS with a link to a temporary download for the key. Make a new key for each user, keep their private key on the server, and encrypt (or at least authenticate) every transaction between the device and server using this key pair.
Now if someone else wants to pretend they are their user, they have to get that file in one of three ways:
They take it directly off the PDA (they also need the password, as the public key should be protected by the user password)
They get the user to request a new SMS link, and somehow get the link without having the phone
They change the phone number and request a new SMS link
In any case, you are validating not only the password, but also an associate phone number. You can make it hard for users to change the phone number (validate against their email as well when they request a phone number change, have them call in, etc).
Of course you can do the same with other channels of communication, but users are getting more and more used to SMS authentication and download, so it isn't too much more hassle.
-Adam
You could generate slightly different cab file for every download. The only difference would be security token your application would use as user/password analogue. That should be a public key for real security.
You could send them SMS with a code each time they access your application.