One way or another it usually end up being stored in a completely unsecured manner.
This is even more outrageous knowing how secure Firebase actually is. The documentation even contains a "Securing your Data Model" section .
> 2.6 million plaintext passwords
Anyone who is actually competent knows hashing at a minimum; and it costs nothing to implement, both time and money wise.
All of this, because Johnny over here read a tutorial on how to make your own app.
The downside of development is that, you do get these people who 'stain' the title, because they just read it and followed blindly instead of actually learning.
A few weeks ago I found out a newer hire (at senior level) decided to build his own auth system, because the current one, "doesnt work". It doesn't work because it doesn't allow our employees to handle customer passwords. Even with high turnover, some people don't understand why that is essential.
When simplicity fights security in a corporate setting, simplicity nearly always wins. The exception is when an executive is security savvy and isn't a push over to their peers.
And the difficulty of setting up firebase's auth may also have changed over time. Did they always have hosted user/password auth or did they rely on third party pre-google?
I have had to figure it out myself. It isn't hard, just took some extra effort to look into.
This is 100% the fault of developers.
I don’t know enough about the exact security problem (I don’t use firebase) but I’m guessing tossing your hands in the air isn’t the only option.
Yes, Firebase team messed up here, but technically speaking it's not too late to fix if done right now. I noticed Firebase already added big banners in Firebase dashboard to make people aware of this issue, or maybe it's a way for Firebase team to cover their asses by saying we told you so!!
It's a good step towards fixing this issue but it's still not enough.
This seems really odd to me. If you use Firebase Auth, you never see or get the users's password at all unless you are also copying it (on user login or registration) and storing it in another collection on your own, and then not hashing or securing that. The 2.6 million number could also conceivably be just a handful of really popular apps (or even just one!).
My experience with Firebase Database is that it's great for apps with extremely simple models, or for PoCs where security and performance aren't a concern.
If each user's data is independent and isolated, then it's not a problem. But for more complex cases, e.g. two particular users can see a piece of data because they belong to the same group, the complexity of trying to properly secure the database isn't worth whatever efficiencies you would gain over using a more traditional database.
However, if your goal is to create an offline-capable app, then there aren't necessarily going to be any simple alternatives. CouchDB is good for offline but doesn't necessarily solve security.
1. You let inexperienced devs make big decisions.
2. "MVP" and ignore all of the other parts of the dev lifecycle.
#1 and #2 have been symptomatic of the tech industry since at least the 90s. The difference back then was the surface area was generally limited to your private network only.
Was the mistake in the default Firebase configuration settings, or were common poor choices made by each of the app developers independently?
It's the most irresponsible default I have seen in practice.
Let's not forget that there is a security/permissions testing feature built right into Firebase. It would literally take 1 minute for a dev to ask and test: hey, can people read each other's data?
That's not what "safer" means. You cannot say that that's what would happen, either.
Love this turn of phrase