This is why I hate giving my personal info when "Signin Up" for online services of stuff made by startups. They usually know nothing about Back End security , and today's trend is to create product that "sale" and to ship as fast as possible regardless of compliance or security.
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 .
I don't think it is about compliance or security at all; just developers that aren't competent.
> 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.
I joined a company as a junior developer. Their senior developers did not see a problem with unsalted MD5 passwords. When I told them how unfathomable it was to think that was secure, they argued that there was a much larger problem if the database was breached. Not even a day later a company like ours was hacked in Canada and they went into bankruptcy because of it. I was called on a Saturday and asked how fast we could implement it. It took one hour to implement the new hashing and have a conversion strategy for the old MD5. The entire system is now upgraded to sha5 hashes with csprng salts.
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.
This is especially surprising because Firebase provides authentication APIs that do the right thing by default. This means devs are doing more work to get to a less secure solution.
Or treating it like any other database; and just using it because its 'popular.' Those 'developers' who do that (use popular just because,) are just the people who stain the title.
I think what firebase provides has changed over time. These problematic instances maybe be legacy.
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?
For sure incompetence is at play here, but if these teams had compliance and security procedures in place then their incompetence would have been accounted for.
Realizing you need compliance and security procedures requires competence. The two of you are basically saying the same thing. There is no world where a company that can't get the most BASIC security practices right will realize they should have security procedures in place.
Perhaps knowing that humans are fallable and that many of these app devs are educated solely in a 2 month boot camp, Firebase might do something to make this less likely.
Not allowing unauthenticated requests? Look for things like plaintext passwords from one of many giant dictionaries of commonly used passwords and flag that behavior? Look for fields that match credit card numbers? Do better in documentation, especially around any schema creator?
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.
You know what I mean: open to all authenticated users, authentication being cleared at the app level. Only having to create an account for full access to all data is indeed "open." Would that Facebook used this strategy, the implications would be clear.
The underlying issue here is that Firebase was sold as the answer to the not-so-techy people that wanted to create apps but couldn't necessarily handle the backend and here the issue is that Firebase should have thought that the majority of the audience thought Firebase would handle backend security for them as well.
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.
That is not a very good take. There have been dozens if not hundreds of similar leaks from people who thought they could handle the backend and used more traditional technologies. There's precious little evidence that I'm aware of that these apps are systemically less secure than apps that use bespoke backends.
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!).
I always figured there were a lot of poorly-secured Firebase apps out there.
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.
3. Everything critical to your company is a 3rd party SaaS accessible via public IPs.
#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.
Firebase Database default settings make the entire database world-readable and world-writable by all "authenticated users". But once you have enabled authentication, then that means anyone who signs into your app with a Google account. Restricting users to only access their own data requires understanding and writing "security rules".
It's the most irresponsible default I have seen in practice.
I disagree. I bet if the default was no access, developers would simply enable all access (and not even realize they could restrict access to authenticated users).
So the default is likely much safer than what would otherwise happen.
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?
developers would simply enable all access (and not even realize they could restrict access to authenticated users). So the default is likely much safer than what would otherwise happen.
That's not what "safer" means. You cannot say that that's what would happen, either.
We are using a system called Kinvey and there it's the same . By default everyone can read everybody's data. You can restrict it but I don't understand why they don't have a restricted model as default.
I'm not sure these cases are even using firebase's user authentication - the article is reporting plaintext username/passwords being stored in the databases.
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 .