I developped a mobile app using our backend to register and verify users using Authy.
This is done by the backend in 3 steps:
1/ The app requests the backend to register the user.
The backend calls https://api.authy.com/protected/json/users/new (email, cellphone, countrycode). It provides back the userId later used.
2/ The app requests the backend to send a sms code the user.
The backend calls https://api.authy.com/protected/json/sms/{1}?locale={2}{3}" (userId, language, force)
3/ The user now receives the SMS. He fills it in the mobile app, which eventually is sent to the backend for verification.
The backend calls https://api.authy.com/protected/json/verify/{1}/{2}{3}" (token, userId, force)
I wanted to use Automatic SMS Verification with the SMS Retriever API in my mobile app (https://developers.google.com/identity/sms-retriever/overview) to avoid the hassle for the user to enter his verification code.
It requres to set up a hash in the verification code, but unfortunately I don't seem to have any control on what Authy generates.
Am I missing something here to get it work?
Rgds
R.
No, you just can't affect the text in Authy's SMS. So, for now, it looks like we can't support retriever API.
Related
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 am able to generate the token for users and successfully start the SinchClient by following this tutorial. Now, next step is to send and receive messages. Now, how do I recognize users? Since I am using authentication token to start the SinchCleint and not a particular username when starting a SincClient, then how can I send messages to a particular user?
As you recognize Sinch doesn't have the info about your users, you only start the client with a unique token. Sinch is built on the assumption that you have a user database and social network of you own, and the sinch client "address" to send messages to is something you keep track of. Does that make sense?
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.
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 have an existing web app built using Ruby on Rails. It already has a built-in email messages feature. Our users have requested for a functionality which is able to do the following (for US users only):
Get a unique and new US phone number which is tied to their registered email address (user ID in our web app
For others (users or non-users) to be able to send our registered SMS messages to this new number. The registered user will get a notification that he has received an SMS and will then go to Messages module to retrieve the SMS
The registered user should also be able to send an SMS message from his Message module to other users and their mobile numbers. These users will not be receiving the content of the SMS but rather be getting a notification that they have receved a SMS from our registered user and now they need to either creae a new ID or login using existing credentials and authenticate phone number in order to retrieve SMS from our user.
Question: What Ruby Gem could be used for such functionality?
Also, are there APIs and open source code available for such functionality?
I would also like to kee my costs low for all the above as we are still a start-up company.
Thanks in advance.
You might consider checking out Twilio (disclosure: I work for Twilio).
Twilio has a Ruby gem that provides a high-level API for sending SMS messages and buying phone numbers. You can also receive incoming SMS messages to a number by specifying "webhook" URLs that will receive an HTTP request when a message is received. You can sign up for a free trial account here.
Some relevant bits of documentation:
Sending an SMS
Find an available number (note: you can also do this through the GUI)
Buy the number you found (note: you can also do this through the UI on the site)
Responding to incoming messages