Is Firebase Auth Secure?

Updated 31 March 2023

Firebase Auth is the authentication system provided by Firebase. It’s used by almost every other client-facing part of Firebase to authenticate users, manage their identities and store user info.

It’s really easy to integrate into an app, with SDKs for Android, iOS and web among others. It supports standard username/password authentication, or federated third party identity providers including Google, Facebook and Twitter.

But is it secure? We’ve fully audited Firebase Auth and this post lays out the issues we’ve found.

It lets users use insecure passwords

Firebase Auth has a complete lack of password complexity rules when using standard username/password auth. It will quite happily, for example, allow a user a password of “123456”. This is commonly cited as the most popular password in the world, and probably literally at the top of any hacker’s list of passwords to try.

In fact Firebase Auth’s only rule is that passwords must have at least 6 characters, which is horrific. (For something a bit more scientific than “horrific”, take a look at OWASP rule MSTG-AUTH-5, which it contravenes.)

A naive developer is likely to try to address this by adding a complexity requirement in the UI of their app, so that the front-end app (rather than the back end) validates any proposed password against stricter requirements. But this doesn’t make the back end any more secure, and the app will still fail its security audit (in fact, it will fail at the same OWASP rule as if they hadn’t done anything at all).

A proper back-end solution to this problem proves almost ridiculously complex to solve. You have to create your own custom authentication system and create your own JWT tokens. I’ll provide a step-by-step in a future post, as this isn’t simple at all.

The easiest answer is to just stick to a combination of Google, Microsoft, Facebook, Twitter or Apple logins, which should account for practically everyone with a smartphone.

If you have no choice but to implement your own password complexity rules in-app, then there is a further gotcha: you also have to handle password reset. This is strangely difficult. I have written a whole blog post on the subject.

Update 31 March 2023: Anton Reindl points out that Google Identity Platform now has a pre-GA feature which allows you to specify password length and whether the password must contain uppercase, lowercase, numeric and symbol characters. This is great progress!

It does of course require your project to use Firebase Auth with Identity Platform, which has a potentially very significant cost impact. Once switched you need to contact Google to enable the password policy feature as it’s not yet generally available. And of course your users will still be able to use passwords like Passw0rd! — the new feature isn’t yet flexible enough to use something like zxcvbn.

It doesn’t limit login attempts

It’s sensible to limit login attempts to prevent the bad guys from trying millions of passwords against a named user account. This would be a really effective way for a hacker to gain access: it’s one of the first things on a penetration testing list.

Firebase does have a limitation, but for unclear reasons they don’t publish what that limitation is. We technically can sign it off against OWASP rule MSTG-AUTH-6, but without a definitive spec we’ll feel a bit uneasy about it.

Its 2FA / multifactor authentication is very hard to implement

Multifactor authentication is when the user has to present multiple credentials for validation. For example, they log in with a password and a code which has been emailed.

Multifactor authentication is a very important weapon in the security arsenal. It prevents password guessing or brute force attacks, because simply knowing someone’s password isn’t enough to get access to their account. It’s mandated by OWASP MSTG-AUTH-9 for certain kinds of data.

Up until 2020, Firebase Auth didn’t support multifactor authentication at all, which was terrible. Now it does, but you have to use Google Cloud’s Identity Platform and the process is somewhat convoluted. But at least you can do it.

By the way, you can’t rely on multifactor authentication support in third party auth providers (Google, Microsoft, Facebook, …) to say your app supports it. Whilst those third parties do generally support it, it’s sometimes configurable by the user who can switch it off. And in any case, third parties’ policies and specifications are subject to change, which could affect you adversely.

Step-up authentication is also hard to implement

Step-up authentication is about re-authenticating users, via a different factor, if they want to perform particularly sensitive tasks. For example, a cycling tracker might give you access to your mileage and other stats when you enter a password, but require further identity confirmation (e.g. via email) to track your GPS location.

OWASP rule MSTG-AUTH-10 mandates step-up authentication for sensitive actions, though of course it’s not needed if the whole app is protected by multifactor authentication anyway.

Google Cloud’s Identity Platform does support step-up authentication. Whilst it’s easy to implement on the Identity Platform side, we have seen various degrees of success when auditing Firebase applications with it.

Note that Firebase Auth’s reauthenticateWithCredential sounds a bit like step-up authentication, but it isn’t. It’s about re-confirming using the same credential as the user logged in with, not using an additional factor. It’s a good idea, but not to be used in place of step-up auth.

You can’t implement account activity auditing

Where particular security is needed, good practice dictates that users should be able to audit which devices are logged in to their account, and from where. They should also be able to block certain devices if they look suspicious.

That’s enshrined in OWASP rule MSTG-AUTH-11. But it’s not a rule that necessarily has to apply to every app. For many it would be overkill, and from a security audit perspective it’s one we discuss with the client first to gauge whether it’s appropriate or not.

But if it’s needed, Firebase Auth can’t help you. You won’t be able to get that information using username/password auth, nor with any of the third party auth providers (Google, Microsoft, Facebook, etc). If using a third-party auth provider, it might be possible for users to find that information and functionality within their account by going directly to their provider. For example, Google users can log into their account using a web browser, and use the “My Account” area to review logged-in devices. But that information isn’t available through Firebase, regardless of auth provider, so it isn’t possible to provide it inside the app.

If this is needed, the only solution is to create your own custom auth provider within Firebase Auth.

Its Android SDK doesn’t store tokens securely

Conseal Security’s recent ethical hacking / DAST testing on Firebase revealed a flaw in the way the Android SDK stored its authentication credentials on the device. This renders it incompatible with OWASP rule MSTG-STORAGE-1, and therefore many organisations’ security policies.

A full write up of this issue is in this blog post.

In conclusion

Firebase Auth is effective and the features on its feature list are secure. But in many cases further functionality is needed for apps built with it, to meet even fairly basic security requirements.

In most cases above, the problems exist only when using standard username/password authentication. Often the solution is to create your own authentication provider and hook it up to Firebase Auth. You can equally address many potential security failings simply by using third party providers instead.

But sometimes organisations’ policies preclude — for good reason! — the use of third party providers. They mandate that security and authentication work has to remain in the organisation’s domain.

In that case, Firebase Auth does have its limitations, particularly when using it to store sensitive data. That is where issues like its patchy multifactor authentication support and lack of account auditing might mean it’s incompatible with your organisation’s policy.

In which case, you can patch it up yourself by creating your own provider, or if not, unfortunately Firebase Auth isn’t for you.

I’ll be back next time with a look at Firebase Firestore security.

Tom Colvin is CTO of Conseal Security, the mobile app security experts; and Apptaura, the app development specialists.