I am using Twilio's verify API for TOTP services (Authy, Google Authenticator, etc).
I am trying to figure out how to handle the case where a user has lost access to their phone and cannot get past the TOTP 2FA challenge. Can I create a new Factor for that user and somehow "invalidate" the previous one?
Anyone know how to do this?
You can delete a factor, which would remove it from the entity. You can then create a new factor.
How to handle how you re-enable access to the user's account in your system is up to you though. Presumably after the user has convinced your support team that they are the rightful owner of the account, you could turn off 2FA verification for their account, allowing them to log in, and then have them go through 2FA set up again themselves. You might also want to consider generating back up codes which they can use in the case that they lose their device again.
Related
If I notice fraudulent activity on my application by an authenticated user (by Firebase Authentication), can I block the device associated with this user so that he can no longer access my application? And if so, how do I do it?
Thanks for your attention !
A Firebase Authentication user has a UID, that you can use to allow them to access certain resources. To block a specific user from Firebase Authentication itself, you can disable their account. So don't delete it (as they can just recreate it in that case), but disable it. After doing that, they won't be able to sign in, and will be unable to refresh their ID token (which happens hourly).
If you use one of the Firebase databases (Cloud Firestore, or Realtime Database), you can also implement a list of banned UIDs in there, and then check against that in your security rules.
I have a Slack App (source code) where I want to send reminders to channels where a certain piece of text has been mentioned the most on a schedule. It works, but there's a limitation:
The search.messsages API method only supports user tokens. I want this to run in the background, without interaction. Approaches that have come to mind:
Store my personal user token
Con: Would allow others with access to the token to be able to see my private messages
Create a fake user whose only purpose is that user token
Con: Have to pay for that fake user indefinitely, manage shared credentials, etc.
Any other ideas?
Here is what you can do:
Switch on distribution of the Slack app.
Have the admin, or an existing user on the Slack channel install the app. During the time of installation, you can ask for permissions with user token and search:read scope.
Now you can make all the searches using this user's token. You'll need to plan for the scenario where this user is deleted from the Slack workspace, your user token will stop working.
I don't think there is a way to control it from searching for your personal messages. Search functionality is dependent on the user token.
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 implementing a web application using laravel framework. I used twilio /Authy 2FA for adding an extra layer of security for users to make login their account. Authenticate with email and password they are asked for OTP to login, that is working fine. But now I want is their any solution for my problem- "If user login using 2FA then , they are not required OTP to next login for one month on same device. Means I did not want every user requested for OTP on every login from same device, and want also stores thier trusted device". please suggests me solution.
Is their any third party library or api that provide soltion of this problem.
Thank you
Authy developer evangelist here.
If you want to avoid users having to 2FA every time they log in then you'll want to drop a cookie that signifies that the user trusts this device. You can make the cookie live as long as you want, 30 days is probably a good idea here.
Then, when the user is logging in, check for the existence of the cookie, if it is there then there is no need to 2FA again. If the cookie isn't there, then present the 2FA flow.
Let me know if this helps at all.
Note: This is the first time I'm trying to implement a social login API, so thanks for bearing with me and helping me out!
I am developing a web application and I have a login and registration system already developed. Now, I am thinking of adding Facebook and Google+ login - with a backend. I went through their docs and other tutorials and they require to implement considerably a lot of things.
But, since I have a registration system already, I thought of doing something like this:
Have the social login buttons on the login page.
When the user clicks on a social login button and authorizes the app, the user data is returned from Google+, for example.
Now, instead of proceeding with the OAuth procedure like getting the user ID, secret ID and contacting their server from my server for token verification and getting data, is it possible to just use the data returned (after the user authorizes) and do the normal registration with the registration system that I already have?
These are the advantages that I see in doing this:
No need of extra code or database fields like token ID, etc.
User can add a password to their account whenever they want and login to the site or access their account by logging in through Facebook or Google+ given that they use the same email ID.
It's enough to use the social login providers' API once - the first time the user logs in (which technically registers the user to the site).
I know the advantages are the same when following the full OAuth2 implementation, but what difference does it make?
Now my questions are:
Is it OK to cut short on the social login as mentioned above?
Will I be losing any obvious advantage doing so (given that I already have a registration system in place)?
If yes, is anyone else cutting short on the flow in their website?
The system proposed by you has certain flaws, especially security related flaw. I would give you to the point answer:
You will send data from client after getting it from google+ or other provider and use your registration process implicitly.
This approach is wrong as I myself as an attacker can send you the data from google+ using my clientid for an app. Will you register or login using the info I am sending? I can pretend to be anyone in your system if you do that.
Is it OK to cut short on the social login as mentioned above?
Will I be losing any obvious advantage doing so (given that I already have a registration system in place)?
If yes, is anyone else cutting short on the flow in their website?
No. (see the reason above).
No. You won't be losing advantage as you already have system in place. Most of the sites have a system in place for normal registration. They give oauth login by leveraging it. Some will say that the password is cumbersome or such, but all famous sites provide login and password including SO.
Now the question comes, how to simplify the oauth system given that you already have a system in place.
I recommend this(I would assume Google as a provider) flow with things starting with dot are what you need to do:
You have a Google login button.
User click on Google Button.
The User is redirected to the Google site.
The user gives you permission.
Google redirects and give you a token.
You can now send info and token to your server. (You need to send only token as backend will get info. Otherwise, a user with valid google+ token for your website can send you any info).
Backend verify token and match that "aud" is equal to your client id. Or it can happen via a library. You will need to give only your client id.
Backend get profile info from token in case of Google+(Name, email) while verifying which you can store as part of your registration process or login process if that email already exists. You can store google id of user also. This is useful as some provider like fb don't always provide email for every account. (For some fb don't give email but for majority of cases it give you the email.)
Backend send back session info or jwt token or any other time bounded process which tells that the user is login.
Your user can login via email also. If he isn't already registered then, then he will need to register. Otherwise, using forget, he can set password or from accounts settings he can set password.
You also need to be careful if the same user is connecting via a different provider, he need to have the same account in your system which you can handle via email.
Kevin,
Authentication is a complex procedure involving lot of measures to ensure security. Hence Web-application/ App developers, delegate this critical piece of work to Identity providers like Google, Microsoft, Facebook etc. These Identity providers are trusted by the app developers and more importantly the consumers trust them too.
Why do app developers provide third party/ social logins? Because, it gives the users of the app some advantages.
They don't have to create new account with the app and remember the new set of credentials. Instead they can use the same credentials they are using with the Identity provider, to gain access to the app. This is huge.
They don't have to trust the app completely, means how the sensitive information like passwords, security questions are handled in the app, as they are not providing any sensitive information directly on the app. Only needed public information is fed to the app from the Identity provider. This is huge too.
No need to worry about the system compromise and leak of sensitive information as all Open ID providers have better security policies in place. This gives consumers a high degree of confidence when using your system through third party logins.
"All the advantages you mentioned will be great for the app developers
at the cost of disadvantages to the consumers of the app."
Lets put the consumer disadvantages on the side and look at the advantages you mentioned:
No need of extra code or database fields like token ID, etc.
You still need code/setup to validate your own tokens. You have to add more logic to verify the external tokens, but the consumers will have the advantage of using the external providers like they are in any other application.
User can add a password to their account whenever they want and login to the site or access their account by logging in through Facebook or Google+ given that they use the same email ID.
This is little confusing as users may choose external provider, so they don't have to remember a new password. Also, the account validation process is different if you use external login vs id/password login. If you are willing to provide both, then you already have the system in place, to verify the account for external logins. Then your first advantage is void and you are better of using Open ID spec.
It's enough to use the social login providers' API once - the first time the user logs in (which technically registers the user to the site).
This approach adds confusion to the flow for consumers. They expect to see a login screen from third party provider for authentication (when they click on google+ or FB), but instead they see your login screen.
Instead of cut short approach, it would be worth to use the complete flow. You might add more logic to handle the token verification with external providers, but, actual complex logic of token validation is delegated to the external providers. This adds no confusion to the end user and they can trust your application easily through social id providers. Even though, users can authenticate through social Id providers, it is always a best practice to have the profile object of that user in your system (without the sensitive information like password).
Since you have your own registration process in place, this may not be a huge advantage. But, please look into the open source implementation of any of the Security Token Service (STS) providers, to see if you can borrow some of the features for validation external providers.
Please let me know if you have any questions.
Thank you,
Soma.