I use Firebase Auth with Phone in my application. This kind of auth provides sending sms to a user with code to be entered.
I wonder if there a way to configure how much sms could be sent to a particular user at time period.
I know that there is FirebaseTooManyRequestsException which means that the server handles such situations, but I want to limit the user by my own rules.
See phone_number_sign-in_limits. If you want to change limit then you should contact support.
Related
On a website using firebase that contains auth I'm implementing a "forgot password" feature.
The return status of sendPasswordResetEmail() is 400 if the user supplies an email that doesn't have an account associated with it. It returns 200 if the email does have an account.
That means that an attacker can keep guessing emails until they get a 200. Then they know of a valid email. Then they can start guessing passwords for it.
Is there a way to get sendPasswordResetEmail() to always return 200? I'll like the only response, whether a good or bad email is entered, to be "Check your email for a reset link". If the email is invalid then firebase should quietly not send an email.
Or is there some other mechanism that would increase security?
firebaser here
API calls from client-side SDKs to Firebase Authentication are rate-limited to reduce the risk in such a dictionary attacks. We also just launched new configuration options that allow you to enable email enumeration protection for example by always returning INVALID_LOGIN_CREDENTIALS regardless of the type of error.
If you suspect you're project is actively seeing such an attack, reach out to Firebase support so they can investigate and adjust quota if needed.
According to firebase doc, it seems that client side SDK allows email address as well as user profile information to be updated directly.
https://firebase.google.com/docs/auth/android/manage-users#update_a_users_profile
If I build an android app without any UI workflow for users to change email address, I am confident that majority, 99.99%+ of the regular users, will use the app as intended.
However, if certain users investigate/reverse-engineers into the app, learns that it uses the firebase, wouldn't it be possible for them to debug and invoke any one of the Firebase Auth client SDK methods provided? (e.g. Wouldn't it be possible for hacker to change email address [not supposed to be allowed in my app after initial registration] & change photo url to point to something inappropriate images?
With Firestore database, I could use security rules to prevent read/writes, but I wasn't sure how I could do something similar in Firebase authentication.
Yes, it's possible for users to get a hold of the token that would be used to call the backend APIs exposed by Firebase Authentication that would normally be used by the SDK. There is no equivalent to database security rules.
The fact of the matter is that users normally should be able to change their email address, as they might actually need to change email provider at some point. If your app doesn't allow this for some reason, and you have a hard requirement to only use the email address provided by the authentication provider(s) you allow, you should consider writing that value to a database at the time the user account is created. Then, use security rules to prevent the user from changing it there. From that point on, you would only ever trust the value initially written to the database, and never use the email address from the auth provider.
You would probably want to handle writing to the database from a Cloud Functions auth onCreate trigger, so that you control all the logic.
I am now facing the same issue, and I think I will just not worry about the 0.01%. This is mostly because if they change their own email with Firebase Authentication via reverse-engineering and my web server is unaware of their new email, this would not have any impact on the other genuine users except maybe not being able to find them (email is only used in searches for now).
I'm setting up a new application using Angular with Firebase. I'm using only Auth system. But like said in the Firebase docs, only 150 emails/day can be sent for Password reset.
https://firebase.google.com/docs/auth/limits#email_limits
I have two questions:
1) If a user spam the recover password button (that use the function sendPasswordResetEmail() ) does it consume this email limit ? If yes how to prevent that ?
(Doc: https://firebase.google.com/docs/reference/js/firebase.auth.Auth.html#sendpasswordresetemail )
2) Does the SMTP parameters (own server or other mail service) from Firebase project settings use the email limits ?
The 150 emails per day for passwords resets limit applies to emails sent through Google's mail servers. If requests are identified as spam, and email doesn't get sent, they don't count. If spam requests are not identified and email is sent, it does get counted. If you're running into spam problems and hit this (or other limits) because of that, reach out to Firebase support for personalized help in troubleshooting
The limit is on emails sent through Google's mail servers, if you use your own mail server, the limit doesn't apply.
Firebase now provides an authentication method using the users phone. A user opens a web page, and the page initiates a SMS verification process.
Firebase stores the users phone number (Identifier) and a randomly generated User UID. This is great if you want to validate phone numbers of your users, but not so great for restricting access to a whitelist of known phone numbers. Using Firebase phone auth and the very handy firebaseui-web library you receive an authorization when a phone number (ANY phone number) is validated via SMS message.
I guess I could perform a test in the browser client to see if the phone number (after SMS validation) is on the authorized whitelist via an API call to another server; If valid team member, redirect to the team directory site and to a "thanks anyway" site if not. I will say, performing that query in the client browser JavaScript seems like the wrong thing to do. It would be too easy to cheat it. Definitely not a good thing to do,
I'm hoping to use Firebase and phone SMS authorization to restrict a web page's access to a white list of authorized phone numbers. My use case is a group of people who need access to a simple web page showing the phone numbers of others in the group. We don't want that visible to the world, but it would be nice to have in a handy form (i.e. Look up web page, press the 1-408-555-5555 phone number for quick, easy access on a mobile phone. We intend to make the page persistent via Progressive Web Application methods.
Any hints on how to proceed on using Firebase to restrict a webpage to a whitelist of users' phone numbers?
Note: I've seen this response that hints that it may be possible to use Cloud Function to restrict access to content but its not clear to me how that would work.
(edit) Hmmm... Maybe I'm overthinking this. I could use a node.js server as the host with a res.redirect('SuccessPhoneList.html')to handle an Ajax call back to the server. That would fix my client Javascript redirect issue. I can make that work, but sure would like Firebase to handle this without the extra Ajax call.
There is no way in Firebase Hosting to restrict access to files, and no way in Firebase Authentication to limit who can create an account.
Typically this use-case is solved by:
Storing the list of phone numbers in a database, such as the Firebase Realtime Database, or Cloud Firestore.
Limit access to that data to users whose phone number is in your whitelist, with Firebase's server-side security rules.
Also see these related questions:
Can Firebase hosting restrict access to resources?
How to prevent other access to my firebase
Firebase Hosting: Preventing unauthorized access to URL
I'm working on a push architecture that needs to support applications which allow for multiple users. This means more than one user can log into the application with their credentials. The problem I'm running into is what if user A allows push notifications, then logs out, then user B logs in and starts getting user A's push notifications?
What are some best practices for handling this type of thing? One thought I had was you could remember the last user who logged in and only display push notifications to the "logged in" user. You would have to send some sort of user context in the message payload so it could be checked against the logged in user. However this feels a little funky.
Anyone else ran into this? It's seems like a really relevant problem, especially for tablets where families tend to share the device.
We're implementing this by Registering the device with APSN, getting the device token and sending this to our server through a ws.
On the server side the device token is only associated with the last logged in user.
New app
User A (first ever user) uses IPAD A
Register with APSN, get token
Send token to our servers through ws
Search for token in db, token is new, store it
assign token to USER A
Next user logs into app
Register with APSN, get token
Send token to our servers through ws
Search for token in db, token exists already
Remove connection to USER A
assign token to USER B
SEND Notification to device WITH USERNAME
if username is logged in show it - else dont
Still not perfect as its sent to home screen first so to ALL users
I think your suggestion is acceptable in a multi-user app. It is much simpler to implement this in the client side, than on the server side. The downside is extra bandwidth wasted to send an unneeded notification. But vast majority of the usage is probably single-user so this may not matter much.
The alternative is to track the logged on users on your server and their current reg_ids. This could be more complicated because A could be logged on on multiple devices, then logs out from device 1, and B logs onto device 1, etc. and your server has to track all of these. So probably another table to track the relationships between 'Logged On Users' to 'Reg Ids'.
If you hate the idea of sending unneeded notifications, go with the server route. If you value Keep-It-Simple principle, go with the client route.
Let's suppose users of your app can logging on multi devices.
We have to make two API on server side:
func setUserDeviceNotifyToken(userId: Int, deviceToken: String) {}
func removeUserDeviceNotifyToken(userId: Int, deviceToken: String {}
On your app side, you have to call setUserDeviceNotifyToken API on every Login In and call removeUserDeviceNotifyToken on every logout.
On server side, you can track every user with its deviceNotificationToken and send notification for correct device.
Notice: If your service doesn't suppose to support multi device login with one user, you can handle it just by one updateUserDeviceNotifyToken and pass null for remove user's device token.
Notice 2: Do not let user logout before calling removeUserDeviceNotifyToken API.