I am building a mobile-focused web application, to later convert to hybrid, and I would prefer new user registrations confirm the user's phone number versus their email address.
I would like to send a new user an SMS with a unique code. When they first log in, they must enter that code to activate their account.
I have a custom SMS service that is sending SMS fine, and would like to know how to integrate this into the Identity registration process.
Please note that I do not wish to use SMS for routine two-factor authentication.
You can use create additional actions in your account controller
and use methods from Microsoft.AspNet.Identity.Core
UserManager.GenerateChangePhoneNumberToken
Send sms with token
UserManager.VerifyChangePhoneNumberToken
Add custom logic to authorization
There are several ways to accomplish this.
Cheap but not reliable or enterprise ready is to build an app on a device you own and have those other devices send an SMS to it. You can process the SMS and reply however you like. With unlimited texting plans, it would be fine. It's just not redundant or reliable (the phone battery could die, you may need to do updates that could interrupt service, etc.)
Work with a company like Twilio (https://www.twilio.com/) and use their SMS gateway, API and services to build, quickly and cheaply (for the most part) the type of service you are looking to provide. There are competitors to Twilio and I'm not endorsing them, just providing them as an example.
Obtain your own SMS gateway (https://en.wikipedia.org/wiki/SMS_gateway) and then do heavily integrated and customized services.
If this is just a proof of concept at the enterprise level or you don't know what your user adoption rate will be, then #1 is probably fine until you need #2. #3 is rarely the best option.
Related
We are not prepared to persist customer's EIN's in our systems because of the associated risks and liabilities. Does Twilio have any alternatives for registering our low-volume customers? For example, an API that our web page could interact with for our customers to register themselves?
Is there perhaps an alternative path? For example, creating sub-accounts for each of our hundreds of customers that would allow them to register on Twilio and still allow our software to interact with SMS on their behalf?
Are there any third party apps that Twilio endorses that could assist in the SMS registration for us? Or even perhaps a third party API that persists encrypted data like EINs for us and assumes that liability for us?
Thanks.
Update: I realized we have options to pursue for registration without needing to persist sensitive data like their EIN. We could inject user interaction in the middle of our current registration steps, meaning the registration steps stop at the required points in the process, our user is notified of needed data, then the registration resumes when they furnish the data. The data like EIN would be transferred directly to Twilio API without being persisted on our server. Problem solved. Still, it would be good to know if there are any good answers to my other questions. Thanks again.
Twilio developer evangelist here.
Our Messaging Product Lead says they are not aware of any 3rd party apps that help with 10DLC registrations and believe the best option is what you mentioned in your update!
We currently have a solution where we implement 2FA ourselves over Twilio Programmable SMS.
We're also using Twilio Verify for Payment PSD2 authorization.
We're now looking to migrate everything to Authy to make use of the Authy app and I have the following questions that I'm hoping you can help me with.
User Migration. I understand in authy, users need to be registered to our application. How can I register all our current users? Is there any way to bulk upload them, or do I have to write a script that calls the API to register them one by one?
User Number phone update. Sometimes our users will update their phone or email in our system. If that happens, how do I update that info in Authy? I couldn't find anything in the docs about that. Do I need to call the api to remove the user and readd with the new info?
Migrating from Verify PSD2 to Authy PSD2. Is the implementation very different? Is there any sample I can look through, as the documentation seems to mainly be talking about QR codes, while what we want to do, is to send it over SMS or Authy depending on the user's choice.
Thanks for your help
Sam
Twilio developer evangelist here.
You will need to write a script to register your users. When you have registered a user, you will receive an authy_id for the user, which you will need to store with your user record.
If a user updates their phone number then you should update the Authy user. To do so, you will want to delete the old user and re-register with the new phone number. You will then receive a new authy_id and you should re-confirm the user can authenticate by challenging them for a new code before you complete the update. If the user updates their email then you can do the same process of deleting and creating a new user though you should receive the same authy_id back if the phone number hasn't changed (though this will add the email address to Authy's representation of the user).
Check the documentation on PSD2 compliant authentication with Authy here. If you are sending SMS messages, then you should set the action and action_message parameters, which tie the message to the authentication. For the app based authentications you can do it via Push Notifications (in which you can include transaction details in the push). If you don't want to implement push, then you do need to get your user to scan a QR code in order to tie the transaction to the authentication (the regular code generated by the app is not connected to a transaction, so is ineligible for PSD2 authentication).
Let me know if this helps at all.
I've set up Firebase to send push notifications to users of my app. However, I'm not sure what's best practice regarding user-to-user communication, such as chat clients. Should I get the device token at each startup of the app and use that for sending, or should I create a new topic for each "chatroom" that both parties are required to subscribe to? For instance when accepting a chat request.
If the first option is the best, how does this work? If the device is assigned a new token upon app startup, how can I be sure a given ID points to a specific device? The whole concept seems fragile - but could someone guide me to the most efficient solution?
I'm only looking to send chat messages / chat invites with push
Depending on the size and the privacy of the chatroom you can choose between using:
topics made for big groups, and without protections on joining / leaving
device tokens that you need to store in your server implementation.
On the plus side they allow you to control the who is receiving the
messages, and to send messages to individual device.
The device token does not change every startup.
It is created when the application is launched for the first time, and can be updated in special cases. When the token change (again, this is rare) the FirebaseInstanceIdService.onTokenRefresh() callback is called.
In a generic chat application you might want to:
first authenticate the user with your login system
upload to your server the mapping user-id > device-token
send messages to the users via the FCM server-side APIs.
Update to address one of the comments:
The server-side API allows to send the same message to multiple tokens in the same HTTP request. See registration_ids in https://firebase.google.com/docs/cloud-messaging/http-server-ref#downstream-http-messages-json
You should not use the server-side API in the client, because that would require you to add the API-KEY in the application which is a security issue (people could decompile the app and read the key)
The storage structure is up to you. For user-id > multiple-device-tokens a dictionary could work.
If the token are non reusable. So it's safe to send messages to expired token.
Token generation requires internet connectivity, so it could take some time.
To handle token after user registration see this question:
How to launch FCM ID Service only after a particular activity is triggered?
I'm planning introduce two factor authentication to my iPad application. Currently user login to my app using a username and password. That username and password is validate from the back end web server devloped using .Net. If user is authorize to login then he can access the iPad application.
Now I want to introduce two factor authentication to validate user. I want to know what are the options we have here. Since we have user’s phone no with us I was thinking of sending a passcode to his phone each time he tries to login to the iPad application. But iPad doesn’t support sending messages over the GSM/CDMA network. Is there a way to achieve this? (Thought about getting an SMS gateway from the local ISP and writing SMS a server. But it cost more) Third-party module will be ok.
Check google authenticator. https://code.google.com/p/google-authenticator/
I think it is quiet good for two-step authentication.
Here is source code for server side (it is on php but i think it is not big issue to convert it to .NET or another platform) https://github.com/chregu/GoogleAuthenticator.php
As I know it uses Time-based One-time Password Algorithm http://en.wikipedia.org/wiki/Time-based_One-time_Password_Algorithm
You can send an SMS to the mobile phone of the user with a code.
After that the user puts the code and the APP validates the code making a request to the server.
The SMS is sended after the user sucessful introduced the username/password.
Other option (less expansive) is to send that code by email.
You should try the google Authenticator
There are other's like https://www.gauthify.com, who offer this service.
You may be interested in looking in this StackOverflow Post.
I cannot fully express how much I am impressed by Twitter's recent TFA implementation, it is extremely convenient and (assuming they didn't botch the protocol) much more secure than many other forms of TFA.
Here's a description written by Wired.
But to summarize you activate a device for TFA and it generates a private (device)/ public (server) key pair. When you try to login after receiving correct username/password credentials the server sends a push notification to the application on any authorized devices encrypted with the public key and the application decrypts the nonce and sends the nonce back to the server and is given a session.
And of course as others have mentioned, there are prebuilt services you can use such as Google Authenticator, but they tend to be clunkier and there are concerns about SMS and TOTP security.
Two Factor Authentication means confirming something the user knows (their password) and something they have in their possession (like a physical key, a badge, or RSA key fob; the important part is it's a physical object other than what you are giving them access into). Sending a push of any kind to the iPad they are using to login to the app defeats the purpose and is no better than single factor (password only). Your only choices are:
Distribute an RSA key fob (or similar). Probably not an option because of the cost & management overhead associated.
Create an authenticator app that only works on a separate device than the iPad with your app on it (along the same lines as the Google Authenticator app). You can probably prevent the authenticator app being run on the iPad by registering a URI scheme for your protected app and trying to open it from the authenticator every time the authenticator is opened. If the protected app opens that means the user is trying to run both on the same device and the authenticator should not validate them.
Send a SMS to their registered phone with an authentication code. By using SMS here you're forcing the user to have both devices to be able to login, which is the key to TFA. Note that a creative user could register a Google Voice number (or similar VOIP with SMS app) on their iPad, thus circumventing the physical aspect of TFA.
I am used to building apps in larger infrastructures. In a startup, how do I setup SMTP for a mobile app? Is there a place I can use for hosting this?
There are a couple of possible approaches:
One option is to not attempt to interface with SMTP/IMAP/POP servers directly in your app. You can, alternatively, send emails from your app via MFMessageComposeViewController, which gives you a standard compose email user interface. This is very easy to do.
To handle inbound emails you can let the user receive their emails via the standard Mail app (that way users don't have to go to different places to receive their emails). You integrate inbound emails with your app using a custom URL scheme. You can then send the user an email using this custom URL scheme, and if they get the mail on their iOS device and have that app installed, when they click on the link they will be taken to your app, passing it information from the URL in the email.
For example, if you defined a custom URL scheme of yourapp://, you can just include a hyperlink to that URL in your email (or text message or your web site), and if the user is on their iOS device, when they click on that link, they'll be taken to your app. If you google "iOS custom URL scheme tutorial", you'll see examples of the plist entries you need to make in your app for it to respond to a custom URL scheme. The Implementing Custom URL Schemes reference shows you what sort of changes you need to make to your app delegate to actually pass data in your custom URL to your app.
Alternatively, you can (a) sign up with any Internet Service Provider (ISP) that offers mail hosting; (b) write an app that sends email by connecting to that ISP's SMTP server; and (c) retrieve email by connecting to that ISP's IMAP or POP servers. Clearly you'll have to pay fees to the ISP, the quality of your app is linked to the quality of the ISP you partner with (so pick a good one), and you'll have to do your own SMTP/IMAP/POP integration in your app (and you'll have to write your own code to do that or use a third-party library for that, as this is not standard Cocoa Touch functionality). In my opinion, you'd need a pretty compelling business case to go down this road, though it can be done.
You could avoid email altogether, and develop a web service for letting the users send and receive messages. (This might make sense if the app is just sending messages between users of your app, for example.) Again, you'll have to contract with an ISP for web hosting, and you'll of course have to undertake the non-trivial exercise of writing your web service code. But this is architecturally cleaner than integrating with SMTP/IMAP/POP servers if the purpose of your app to facilitate communication between users of your app.
You haven't provided enough information for us to assess which approach best suits your situation.