I’m sure it’ll be all Apple’s fault somehow. News sites will post about iOS apps sending out data, totally missing the fact it happens on Android and is Google’s product at fault.
Totally missing the fact that it’s not anything to do with the apps, per se, but with the underlying developers’ choice to use that server database. No change to the apps could be made to close that leak, so why it’s presented by the press as an app issue is a bit odd.
Think what you want, but any info put up on the internet may be compromised whether its an App or Form etc. We are not at the stage yet where security and Privacy are insured.
Storing plaintext passwords is *inexcusable*! The most common practice is to one-way hash passwords, and then store the hash. But there's still value in storing the original password in certain cases. When doing so, though, a developer MUST respect the privacy of the password owner and encrypt it! No excuses for not doing that!
As for the databases being used without authentication, I peg that on pure laziness and a blind trust of Google's Firebase infrastructure.
I'm a web app developer, and I do use MongoDB without authentication in my implementations, because the environment they exist on is already locked down tight! The databases are *not* exposed to, and *not* accessible on the internet. Apps using Firebase *are* using internet-accessible databases, so to not have protections in place is absolutely mind-boggling!
Now, Appthority reports that the problem is occurring when app developers opt not to require authentication for Google Firebase cloud databases, something that is not done by default when developers use the popular development tool.
That's such a bad sentence. I would have gone with:
Now, Appthority reports that the problem is occurring when developers opt out of Google Firebase cloud database authentication.
The fact they opt out implies that the default is 'opt in', so now you have a sentence you don't have read a few times to make you're not interpreting it incorrectly.
I'm not much of a Google fan, but if the developers are wilfully bypassing security then it is down to the developers, though one could easily argue that it's Google's attitude to privacy that led to the problem in the first place: why give the developers the option of running insecure databases on your production cloud environment?
It's an interesting case because it actually justifies one of my more unreasonable prejudices (of which I have many – fruit topping on cheesecake being one of the more extreme examples).
When looking for an app on the iOS store, I try to avoid apps that don't use iCloud for cloud syncing. There are a lot of apps that support Android and iOS, which I don't have a problem with, unless they're storing the data on Google's cloud.
Now, it's a fair enough argument to say that storing it with Google means they can sync between Android and iOS, which you cannot do with iCloud. But since it's a safe bet that I'm never going to own an Android device (which is why I'm happy to behave like an asshat here, but don't troll Android forums, unlike some folk who like to make their asshattery cross-platform), then I don't see the need to take the risk.
Reading this, I see that I wasn't being unreasonable at all. The iOS apps at risk are the relatively small number that have to use Google cloud because they have to sync between iOS and Android. These are the ones I avoid; and this is why.
Storing plaintext passwords is *inexcusable*! The most common practice is to one-way hash passwords, and then store the hash. But there's still value in storing the original password in certain cases. When doing so, though, a developer MUST respect the privacy of the password owner and encrypt it! No excuses for not doing that!
As for the databases being used without authentication, I peg that on pure laziness and a blind trust of Google's Firebase infrastructure.
I'm a web app developer, and I do use MongoDB without authentication in my implementations, because the environment they exist on is already locked down tight! The databases are *not* exposed to, and *not* accessible on the internet. Apps using Firebase *are* using internet-accessible databases, so to not have protections in place is absolutely mind-boggling!
Allowing developers to opt out of security on the production cloud is also mind-boggling.
Plain text passwords being stored in the database? How stupid is this? And that means that they must have transmitted them in plain text too.
I am sure Gatorguy will explain all this away on behalf of Google with tons of links he'll be given. We are just silly Apple enthusiasts, we need guidance from Google experts.
That's not his MO.
In cases where he cannot defend Google, he'll spend some time trawling the net, looking for dubious links in an effort to prove Apple is doing the same thing.
Probably why he hasn’t arrived yet.
Right, I'm in a hurry, so I'll summarise:
GatorGuy posts: "But I have proof that Apple is forcing Chinese children to attend school without shoes!" I respond: "That is so desperate I almost feel sorry for you. Is this proof as solid as the proof you had that you have to unlock an iPhone to answer it?" Everyone else: "Christ on a bicycle, not these two again …"
So, how long before we are told of the companies out there brokering the data syphoned from Google Firebase? Google are masters of data extraction and manipulation for which we know third-parties pay handsomely.
Apple can, and has the responsibility to inform all compromised-app users of their vulnerability, and to put those apps off the App Stores until they prove that the issue has been fixed on a new version.
Now, Appthority reports that the problem is occurring when app developers opt not to require authentication for Google Firebase cloud databases, something that is not done by default when developers use the popular development tool.
That's such a bad sentence. I would have gone with:
Now, Appthority reports that the problem is occurring when developers opt out of Google Firebase cloud database authentication.
The fact they opt out implies that the default is 'opt in', so now you have a sentence you don't have read a few times to make you're not interpreting it incorrectly.
I'm not much of a Google fan, but if the developers are wilfully bypassing security then it is down to the developers, though one could easily argue that it's Google's attitude to privacy that led to the problem in the first place: why give the developers the option of running insecure databases on your production cloud environment?
It's an interesting case because it actually justifies one of my more unreasonable prejudices (of which I have many – fruit topping on cheesecake being one of the more extreme examples).
When looking for an app on the iOS store, I try to avoid apps that don't use iCloud for cloud syncing. There are a lot of apps that support Android and iOS, which I don't have a problem with, unless they're storing the data on Google's cloud.
Now, it's a fair enough argument to say that storing it with Google means they can sync between Android and iOS, which you cannot do with iCloud. But since it's a safe bet that I'm never going to own an Android device (which is why I'm happy to behave like an asshat here, but don't troll Android forums, unlike some folk who like to make their asshattery cross-platform), then I don't see the need to take the risk.
Reading this, I see that I wasn't being unreasonable at all. The iOS apps at risk are the relatively small number that have to use Google cloud because they have to sync between iOS and Android. These are the ones I avoid; and this is why.
I agree with this sentiment and clarification completely. As much as we enjoy kicking Google in the ass this one is not Google's fault. Rather, it's the fault of developers who have decided to opt out of the authentication feature of the database. The tool is not broken, the person using the tool is.
I’m sure it’ll be all Apple’s fault somehow. News sites will post about iOS apps sending out data, totally missing the fact it happens on Android and is Google’s product at fault.
Totally missing the fact that it’s not anything to do with the apps, per se, but with the underlying developers’ choice to use that server database. No change to the apps could be made to close that leak, so why it’s presented by the press as an app issue is a bit odd.
I'm not sure I understand what you are saying here? "It is not the apps fault, but the app developers'"?
I have developed a Firebase app for learning purposes. I don’t think most people understand...this is 100% the fault of the app developers. Not Apple. Not Google. Unless you add authentication someone could just suck the data from your Firebase database via a URL. Google can’t stop stupidity from an app developer. But.....It’s so trivial to add authentication however it boggles the mind why any app developer would not add it as it is simple and the default setting. That is one thing that bothers me about this report. I think the apps they are talking about are highly unlikely to be apps developed by professional developers and more likely to be fringe hobby apps and they are hyping it up to get people to buy the report.
I have developed a Firebase app for learning purposes. I don’t think most people understand...this is 100% the fault of the app developers. Not Apple. Not Google. Unless you add authentication someone could just suck the data from your Firebase database via a URL. Google can’t stop stupidity from an app developer. But.....It’s so trivial to add authentication however it boggles the mind why any app developer would not add it as it is simple and the default setting. That is one thing that bothers me about this report. I think the apps they are talking about are highly unlikely to be apps developed by professional developers and more likely to be fringe hobby apps and they are hyping it up to get people to buy the report.
If it’s so simple /trivial why is there even an option to opt out?
Can anyone think of a single reason why you would use Firebase without authentication? If there isn’t a valid use case then the fault lies squarely with Google for not enforcing its use.
I’m sure it’ll be all Apple’s fault somehow. News sites will post about iOS apps sending out data, totally missing the fact it happens on Android and is Google’s product at fault.
Totally missing the fact that it’s not anything to do with the apps, per se, but with the underlying developers’ choice to use that server database. No change to the apps could be made to close that leak, so why it’s presented by the press as an app issue is a bit odd.
Late to the party this morning. From what I'm reading going to a couple of Reddit sites is that this a failure by the affected developers and not something on Google's end. I can't verify that for myself as I'm not either a Firebase user or a developer. No doubt someone who is can cast a better light on it.
Having used Firebase myself, you cannot blame Google at all. Quite literally, when you open a project it is secure by default. You have to turn off database authentication yourself with a nice warning modal telling you it’s a bad idea. People turn off authentication when building the app for testing purposes but it should always be turned back on. This is just laziness on the part of the developers. Also, why in the heck are they storing user passwords instead of using Firebase Authentication? And isn’t health data supposed to be encrypted on the database?
Yep, leaking private information and Google are synonymous.
Anybody know where to find the list of affected apps?
It would be nice to know which apps have this issue.
Report is pay to view but
Enterprises are at significant risk from the Firebase vulnerability because 62% of enterprises have at least one vulnerable app in their mobile environment. The vulnerable apps are in multiple categories, including tools, productivity, health and fitness, communication, finance and business apps.
Worse, the data being leaked is highly sensitive including PII, PHI, plaintext passwords, social media account and cryptocurrency exchange private access tokens, financial transactions, vehicle license plate and geolocation information, and more.
Our Mobile Threat Team discovered over 2,300 unsecured Firebase databases and 3,000 unique iOS and Android apps with this vulnerability. The Android versions of these apps alone have been downloaded over 620 million times.
More than 100 million records are exposed, including:
2.6 million plain text passwords and user IDs
4 million+ PHI (Protected Health Information) records (chat messages and prescription details)
25 million GPS location records
50 thousand financial records including banking, payment and Bitcoin transactions
4.5 million+ Facebook, LinkedIn, Firebase, and corporate data store user tokens
Why on god's green earth are plain text passwords even stored..., why not store salted hashes, who the hell does that... It wasn't even good security practice in 1993, let alone 25 years later!!.
I just don't get it.
Seems it's not just Google that were idiotic here; most IT and devs are lazy ass that wouldn't know security if it bit them in the ass.
Then there devs like me who like to put emphasis on security but can’t because the business doesn’t make it a priority. I have even pointed out and executed attacks on our system to show that they are viable. I get blank looks and get told to work on the next new feature they promised to clients a month ago. Small businesses just don’t put emphasis on security because it’s not sexy or doesn’t “sell”. In an industry where we deal with PII and HIPA, it should be required and absolutely the most important feature... but alas, I digress.
I’m sure it’ll be all Apple’s fault somehow. News sites will post about iOS apps sending out data, totally missing the fact it happens on Android and is Google’s product at fault.
Totally missing the fact that it’s not anything to do with the apps, per se, but with the underlying developers’ choice to use that server database. No change to the apps could be made to close that leak, so why it’s presented by the press as an app issue is a bit odd.
Late to the party this morning. From what I'm reading going to a couple of Reddit sites is that this a failure by the affected developers and not something on Google's end.
Yes and no. Good product is a product that lets you do what it claims on a tin without problems, while a great product is designed in such a way that minimizes mishaps mentioned in the article, instead of simple pushing that as a sole responsibility of an end user.
Comments
Think what you want, but any info put up on the internet may be compromised whether its an App or Form etc. We are not at the stage yet where security and Privacy are insured.
Play but be ready to pay for it!
A list of apps would be nice, though.
As for the databases being used without authentication, I peg that on pure laziness and a blind trust of Google's Firebase infrastructure.
I'm a web app developer, and I do use MongoDB without authentication in my implementations, because the environment they exist on is already locked down tight! The databases are *not* exposed to, and *not* accessible on the internet. Apps using Firebase *are* using internet-accessible databases, so to not have protections in place is absolutely mind-boggling!
That's such a bad sentence. I would have gone with:
Now, Appthority reports that the problem is occurring when developers opt out of Google Firebase cloud database authentication.
The fact they opt out implies that the default is 'opt in', so now you have a sentence you don't have read a few times to make you're not interpreting it incorrectly.
I'm not much of a Google fan, but if the developers are wilfully bypassing security then it is down to the developers, though one could easily argue that it's Google's attitude to privacy that led to the problem in the first place: why give the developers the option of running insecure databases on your production cloud environment?
It's an interesting case because it actually justifies one of my more unreasonable prejudices (of which I have many – fruit topping on cheesecake being one of the more extreme examples).
When looking for an app on the iOS store, I try to avoid apps that don't use iCloud for cloud syncing. There are a lot of apps that support Android and iOS, which I don't have a problem with, unless they're storing the data on Google's cloud.
Now, it's a fair enough argument to say that storing it with Google means they can sync between Android and iOS, which you cannot do with iCloud. But since it's a safe bet that I'm never going to own an Android device (which is why I'm happy to behave like an asshat here, but don't troll Android forums, unlike some folk who like to make their asshattery cross-platform), then I don't see the need to take the risk.
Reading this, I see that I wasn't being unreasonable at all. The iOS apps at risk are the relatively small number that have to use Google cloud because they have to sync between iOS and Android. These are the ones I avoid; and this is why.
Plain text passwords being stored in the database? How stupid is this? And that means that they must have transmitted them in plain text too.
Jesus Schwepped!
That's not his MO.
In cases where he cannot defend Google, he'll spend some time trawling the net, looking for dubious links in an effort to prove Apple is doing the same thing.
Probably why he hasn’t arrived yet.
Right, I'm in a hurry, so I'll summarise:
I'm not sure I understand what you are saying here? "It is not the apps fault, but the app developers'"?
If it’s so simple /trivial why is there even an option to opt out?
Can anyone think of a single reason why you would use Firebase without authentication? If there isn’t a valid use case then the fault lies squarely with Google for not enforcing its use.
Google should NOT have allowed an insecure database in the first place.
EDIT: I see @Loopless already chimed in. Thanks!
People turn off authentication when building the app for testing purposes but it should always be turned back on. This is just laziness on the part of the developers. Also, why in the heck are they storing user passwords instead of using Firebase Authentication? And isn’t health data supposed to be encrypted on the database?