Is there any configuration present in Azure B2C to limit the number of verification emails ( used for email verification during create account & reset password workflows ) sent to users in a specified time window aka rate limit. We want to prevent malicious actors email bombing our customers with these verification emails.
You can add a retry limit in the selfasserted page if using Custom Policies. It will force the user to be sent back to the app, and they have to try the process again.
setting.retryLimit
https://learn.microsoft.com/en-us/azure/active-directory-b2c/self-asserted-technical-profile#metadata
The service itself has some throttling limits on how many can be sent from a particular IP within a certain timeframe.
Related
In Azure Logic Apps, there is an action for Send Approval Email under Office 365 Outlook.
I want to have multiple approval options in the same email. Is there a way to do it?
I tried looping over and sending emails but that sends a new email every time with option to approve.
Currently, this is not possible in logic apps. You can send only 1 approval from logic apps. However, if it is must to use an approval connector you can build a logic app where you can send multiple emails and track the options through Storage account or you can simply use a send email connector and get the replies from users. Below is an alternative approach if it is must to use an approval connector from logic apps.
I have used parallel branches to set a time for the responding by the user. If the user fails to select the options within the time limit the logic app fails. In my case I have used 1 minute. However you can even set time using Delay until and mention the specific date and time to respond back.
In the parallel step I'm sending the Approval email to the user and then I'm storing all the Lists of the blobs in storage account into a variable.
Note: This results to trigger multiple emails to the users
In the next step, I'm checking if the user's options has already been created by checking their mail id. If yes, it just stores the selected option by the user else it creates the file and then stores the selected options by the user.
RESULTS:
In mail
In LogicApps Run
In storage account
Yes, you can have multiple approval in the To configuration with multiple email ID's separated by semicolons of the Send approval email action of the office 365 connector.
Once it is approved you can get the email ID of the person who has approved the request using the property UserEmailAddress and other details of the output of your Send approval email connector.
I'm facing intermittently delay with polling email messages via Gmail API from GSuite user's inbox. Those calls origin from automatic jobs and use multiple G-Suite users to disperse the work and avoid reaching Quota limits.
However, there are still delay of at least 3 minutes in reading the email. Investigating message email headers showed neither errors (429) or delay time, nor quota limits are being reached.
I examined the push notification method and I'm limited to use it.
Are limit units calculated according to domain rather than per G-Suite user so I'm indeed reach quota?
What else can cause those delays?
The Gmail API has usage limits per method and per user.
Email sending limits are calculated per user per day, not per domain.
Limit units are calculated from all requests made from your application per day
You can check your quota in the Cloud console, choosing your project and API (in this case Gmail).
In my case, I could clearly see the email inside the 'Sent' folder but the recipient had not got any email, so I knew the limits for using the API had not been crossed. It was spam protection taking a ton of time to figure out if the sent email was spam or not. The most common case would be if your emails are all similar with a link in them. I removed the hyperlink in my template email notification and it started working again without any delay.
We are using Azure B2C for our Identity provider, but it is clear that users are finding the process a bit clunky. Mostly this appears to be because of the synchronous nature of the signup process.
We do want to verify the email address and MFA phone number, but ideally not at the point at which they are entered. Is there a way that we can leverage a graph API call to deal with this, or use a custom policy to achieve the same?
We would also like a clear separation of the signup/signin process. Such that a user can be directed to these pages directly and they can also be branded.
You might be able to implement this with two custom policies:
A sign-up policy that prompts the new customer for the email address and the phone number and creates a new user with these marked as unverified. This custom policy can be invoked at the Account Creation step.
A verification policy that verifies the unverified email address, via the built-in email message, and then the unverified phone number, via the built-in phone call or text message. This custom policy can be invoked at the Application Complete step.
Note that it isn't the sign-up policy that sends the verification code but the verification policy that sends it. I don't know if this is acceptable for the desired experience but the custom policy that sends the verification code must be the same one that validates it.
(There is an alternate flow where after the sign-up policy has completed, your end application sends a custom email message, containing a verification link, which when opened by the end user is validated by your end application and then the verification policy -- minus the email verification step since the email address has already been verified -- is started).
If this proposed solution is interesting to you, then I can attempt to provide the full details of the custom policies based on one of the custom policy starter packs.
Updated on 15 February 2019
I've published the following custom policy samples to this GitHub repository. The second and third policies implement the above flow.
sign_up_sign_in
Sign-up for a local account using an e-mail address and a phone number. The end user is prompted for verification of the e-mail address and the phone number.
Sign-in for a local account using an e-mail address or a phone number. If the e-mail address hasn't been verified, then the end user is prompted for verification of the e-mail address. If the phone number hasn't been verified, then the end user is prompted for verification of the phone number.
sign_up_without_verification
Sign-up for a local account using an e-mail address and a phone number. The end user is not prompted for verification of the e-mail address or the phone number.
sign_in_with_verification
Sign-in for a local account using an e-mail address or a phone number. If the e-mail address hasn't been verified, then the end user is prompted for verification of the e-mail address. If the phone number hasn't been verified, then the end user is prompted for verification of the phone number.
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.
We will be just an integrator providing DocuSign services to our clients that have DocuSign accounts via OAuth authentication in our application. Some of our clients will have significantly higher volume than others.
If we set the RequireAcknowledgement flag on the envelope's event notification and the initial post to the webhook url fails (due to server down, etc.) for account 1 (low volume client) and then a subsequent post succeeds (server back up) for account 2 (high volume client) will the post for account 1 be retried or would they have to wait for the indeterminate time (could be hours or days) between requests for their account?
In other words, is the retry tied to the individual account having a successful post or to our integrator key or notification url having a successful post?
The retry logic is based on the Connect subscription (also known as the Connect configuration.)
If you're creating a Connect subscription at the account level then each account has its own subscription. (Even though the same Integration Key is being used.)
If you're using the per-envelope eventNotification technique for creating per-envelope subscriptions, each envelope is a different subscription.
Details on the retry logic.