Reputation: 167
I am using firebase phone authentication in a website and react native application. We are getting an ~1,200-1,500 unknown sms sent in our firebase dashboard. None of these get verified, but we are incurring a cost for the same.
Basis our analytics software, we have requested for 257 OTPs in the past two days. The number of verifications are also in line with the analytics. Most of these unknown OTPs are from Lebanon, Israel, Timor-Leste & Palestine. We do not have any sessions from these regions.
Additionally, our analytics don't report any spike in even sessions on our app or website.
I have already blocked the regions. Any help would be highly appreciated.
OTP requests from client in the period
DAU and MAU on firebase console shows users < 400
Upvotes: 8
Views: 1564
Reputation: 599946
firebaser here
Update (August 11): We discovered that the emails mentioned below about the SMS price change were not sent to the correct recipient list. We are very sorry for the confusion that this has caused. We've rolled back the billing change for now, are reverting the related SMS charges, and sent a new notification to the correct recipient list with the new date that the price change will come into effect. At this point every billing owner of a project that uses Firebase or Identity Platform for SMS/Phone authentication should have received the new message.
First off, I apologize for the unexpected Phone Authentication charges on your bill. It's related to a notice sent on Apr 10, 2023 and a reminder sent on Jun 12, 2023 with subject "[Billing Notice] New SMS pricing for Firebase Auth and Google Cloud Identity Platform (GCIP) starting August 1, 2023".
Please reach out to Firebase support who can help verify the usage and configuration. In the meantime, here are a few things you can investigate right now that can help protect your project from excess charges and potential abuse going forward:
Understand your regional SMS usage
View your SMS usage and look for regions with very high sent SMS and very low (or zero) verified SMS. The ratio of sent/verified is your success rate.
Consider SMS Region Policy
Use SMS Regions to deny SMS regions with low success rates and/or where you don't expect any users of your app, or only allow certain regions.
Limit your authorized authentication domains
Use the authentication settings dashboard to manage authorized domains. The localhost
domain is added by default to the approved authentication domains, and you should consider removing it in your production project to prevent abusers from running code on their localhost to access your production project.
Additional options are available if your project is upgraded to Identity Platform:
Enable and enforce App Check
Enable App Check to help protect your project from abuse by validating requests. Check the pricing of Identity Platform before upgrading and remember that you will also need to enforce App Check for Firebase Authentication in the Firebase console. Double check your reCaptcha Enterprise approved sites list to validate that it only contains your production sites.
Reconfigure Multi-Factor Authentication
If you already have multiple providers, and can operate without Phone Authentication, you may want to disable Phone Authentication as a first factor option. This will remove SMS as an attack/abuse vector since the user will be able to request an SMS/Phone Auth as a second factor once the first factor is verified.
In addition to the above, you can also set budget alerts and automated cost control responses to help prevent this from happening in the future. You can find more details in Create budget alerts and in Selectively control usage. Keep in mind that using Cloud Functions to stop service usage will make all services on your project unavailable.
Upvotes: 10
Reputation: 1290
Is Firebase passing its inability to prevent SMS fraud to users? Firebase phone auth says it will "verify that phone number sign-in requests are coming from your app" (via Play Integrity API, reCAPTCHA etc).
However Firebase provides no controls to developers for rate limiting (for example, only 1 SMS/unique device/hour etc.) SMS is directly sent by Google, and apps have no control on this limit. It seems to me that AppCheck in this case is also useless because fake SMS traffic (SMS pumping) is being generated from app surfaces. So how does Google expect developers to manage usage? Blocking legitimate countries wholesale is not really a solution here.
Upvotes: 6