I am considering building a Firebase + Flutter framework to small business solutions.
By providing a fairly high level of security, Firebase + Flutter seems quite good for a number of business applications especially based on Android.
However, for this to make sense I have to solve a few problems and I will be very grateful for help in any of the points below.
Is it possible to connect from within a firebase database via VPN
(mainly OpenVPN) to another database via odbc and/or through
webservice (strongly preferred odbc)? The goal is to connect
firebase with local databases in companies - especially MS-SQL
databases (mainly small ERP / WMS system). If this is not possible,
how can an equivalent effect be obtained? I also need a connection
from firebase to firebase to automatically download changes to the
framework from the main repository.
Many governmental and commercial systems require signing files with
a signature based on X.509 (mainly * .pfx, * .p12 password
protected). I would like all such a signature to be implemented on
the firebase server side (possibility of managing such
certificates). Are there appropriate libraries in firebase to sign
content in accordance with X.509? If not how to get the effect of
signing content in firebase + flutter and strongly prefer that the
certificate was not on the client.
In several places on the network I met the possibility of logging in
using a certificate compatible with X.509 or identical, but I do not
see such an option for selection in the panel in firebase? Is
X.509-compliant login support by Google in Firebase, and if not,
could I ask for a step-by-step link on how to handle it yourself in
two variants: a) external certificate , b) automatically generated
certificate by the client application.
Thank you in advance for your support
The subject of this question is so broad that I don't think its possible to answer on StackOverflow.
Generally Firebase is a set of cloud functionalities including databases, functions, authentication (and many more) that can be used in your mobile apps. One of the technologies that you can use Firebase with, but not only one, is Flutter which is engine using Dart programing language. But there are a lot of API from other programing languages like Java, JS, Python and many more. They might be different depending of the product you choose from Firebase.
Now pointing to your questions:
I am not sure what do you mean by "connecting from Firebase", but I suppose you mean connecting from your app. If you build the app in Flutter you will use Dart and it has VPN support of course like here.
Although I don't know much about X.509 I have found that dart will support it as well here example.
Authentication is one of Firebase enter link description here products. You can find there also custom authentication possibilities
I think all you asking is possible, but of course there is no simple answer for it. I hope it will help you.
Related
Could someone please explain to me why a bad actor could not create the following disruption for potential new users to my app?
The bad actor:
Obtains a list of emails from the dark web or some other nefarious source.
Acquires my Firebase keys by inspecting my app javascript -- yes my app is minified, but it would still be possible.
inserts malicious javascript code into my app sources on their local browser. The malicious code uses the Firebase sdk and my app keys to create accounts for each email address.
While there is no possibility that the bad actor could gain access to validated accounts;
nevertheless, creating these accounts would generate unsolicited email verification requests to the owners of the emails and it would also interfere with a smooth account-creation experience for those users when they actually do want to signup.
Am I missing something here?
firebaser here
As Dharmaraj also commented: the Firebase configuration that you include in your app is used to identity the project that the code should connect to, and is not any kind of security mechanism on its own. Read more on this in Is it safe to expose Firebase apiKey to the public?
You already in your question noted that creating a flurry of accounts doesn't put user data at risk, which is indeed also correct. Creating an account in your project does not grant the user any access to other user accounts or data in your project yet. If you use one of Firebase's backend services, you should make sure that your security rules for that service don't do this either.
The final piece of the puzzle is that Firebase has many (intentionally undocumented or under-documented) safe guards in place against abuse, such as various types of rate limits and quotas.
Oh, and I'd recommend using the local emulators for most of your testing, as that'll be faster, doesn't risk accidentally racking up charges due to a quick coding mistake, and (most relevant here) doesn't have the rate limits in place that are affecting your e2e test.
As the title states, I've gotten this email for both projects I've made public on Github. One is a landing page for a local business and the other is a CRUD app I have on the App Store; both of which are using Firebase as the backend.
Is the API key being visible on Github such a security risk?
I've done some research after following the instructions in the email to restrict my API and have heard that you cannot make web service requests with a restricted API key.
I just want to show my repos for the projects for the application process and obviously don't want anything bad to happen with them by doing so.
Aren't Firebase APIs meant to be public?
If so, is it just my database rules that need to be stronger/more verbose?
If any more context is needed, please let me know!
Cheers!
NOTE: I'm still very new to programming so a lot of this is over my head
For Firebase apiKey in a web app you are intended to make this key public, so you should ignore this email -- see: https://stackoverflow.com/a/37484053/771768
Hopefully Best practices for securely using API keys helps.
I'm uncertain as to what you're doing specifically that's resulting in the email but it is warranted.
Please be very careful with API keys.
As the name suggests, these are like keys in that they unlock access to stuff. With digital keys, the additional challenge is that, once obtained, infinite copies of the key may be distributed (and these are usable until the API key is revoked).
There are (often) other (complementary|alternative) ways to authenticate APIs but, as I think you've discovered, sometimes you are required to use API keys.
In the case where they're required, you should endeavor to use complementary authentication mechanisms too in order to try to mitigate overuse and you should continue to be very judicious in your publication of these keys.
I suspect you should not be including (any) keys (ever) in your GitHub repos.
One rule of thumb is that vendors (like Google) use API keys as a way to limit access to (often paid) resources. If the vendor is giving you a key, they're often (not always) using the key as a way to determine how to charge you for an API too. If you're giving the key to others, you're giving other people the possibility of potentially incurring charges on your behalf.
I don't wish to scare you but I would like you to leave this question being very cautious when using keys even if only this causes you to read up more on the consequences of using them.
I've never used Firebase (or Firestore) before and I'm considering using it for my new mobile application. And I'm wondering if using Firebase only, without any additional server is a good idea. Firestore does a lot of things I guess, like authentication, security and scalability. So I really hesitate putting an another server into Architecture. But I have a plan to do many server-side stuffs like searching for text or calculating something.
I think the answer is "it depends", but I want to hear some advices from people who have used Firebase before about this topic. Thank you in advance!
Is it a good idea to use an additional server with Google Firebase?
Firebase will help you build apps fast, without managing infrastructure. So you'll be able to focus on your app development and not on how to maintain servers. Perhaps, if you have requirments that Firebase cannot handle, which I doubt it, you can use an additional server.
I've never used Google Firebase (or Firestore) before and I'm considering using it for my new mobile application.
If you have never used the Firebase suite, I recommend you get started by reading the official documentation. Before starting to use Cloud Firestore, I recommend first get more familiar with NoSQL databases.
And I'm wondering if using Firebase only, without any additional server is a good idea.
There are many apps out there that are not using any other server than Firebase.
Firestore does a lot of things I guess, like authentication, security and scalability.
Firestore is a scalable NoSQL cloud database that allow you to store and sync data for client- and server-side development. It does not authenticate users. For that, there is another product named Firebase Authentication that I encourage you to use it.
But I have a plan to do many server-side stuffs like searching for text or calculating something.
Here you can find more details about Firestore search options. Regarding calculations, you can do pretty much everything you can do in a regular SQL database.
I'm thinking of using an MBaaS such as Firebase or Kinvey for my next app, and am wondering if any exist which encrypt application data end-to-end (i.e. such that the encryption keys are never shared with the service provider). This seems feasible in theory, since the server is not expected to do any computation on the data, only store it and deliver it to clients.
Does such a service exist? I've found ZeroDB and Crypton, but neither are available as services AFAICT, which means I'd have to administer, scale, and back them up myself. I also thought of using something like Firebase and encrypting my app's data before I pass it to the Firebase API, but I'm wary of writing a one-off crypto layer like that unless I have to (i.e. I'd rather use something that's been peer-reviewed).
Alternatively, if no such service currently exists, why not? Is it technically infeasible, or is there just no market for it?
Edit: This seems closest to what I'm looking for, but considering the broken links on their website I'm guessing it's defunct: Adreneline Mobility
The answer to your question is actually available on the market. CloudMine offers end-to-end encryption (disclosure - I work at CloudMine). They have a largely healthcare focused offering so it has to stand up to HIPAA and other government regs around data security.
Here's a good overview video on security featuring CloudMine's CTO. The first 45 sec. provide some more information on our encryption techniques.
I know I'm being the "sales guy" right now but I'm happy to hop on a call to share what we've built and discuss your specific use case. You can email me at nick at cloudmineinc.com if you're interested.
Virgil Security (full disclosure - I work there) has an end-to-end encryption SDK that works for any endpoint, and also has a special integration with Firebase. It's open source, of course. Check it out and feel free to ask any questions of the team here or on Slack - https://e3kit.readme.io/
Edit: see my answer for the solution
Currently working on a Hybrid App with Ionic where there is a requirement to store an authentication Token in order to keep the user logged in, and also guarantee that this data cannot be accessed outside the App context.
There is of course plenty of solutions for this task, each one with different pros-and-cons so it's confusing (for me) to locate the one technology that fits.
I've been looking at angular-localForage and other candidates:
LocalStorage
Obvious choice for small data.
Data gets wiped in iOS when the system is low on memory.
IndexedDB
Buggy support in iOS (IndexedDB support)
WebSQL (SQLite)
Apparently a good option for small data and decent support (WebSQL suppport) but it's deprecated.
SQLite
There are related issues with Cordova in iOS.
LokiJS
Looks like an overkill for this scenario but is definitely a strong candidate. Is the any security concerns I should be aware of (as I read it locally persist data to JSON files)?
PouchDB + SQLite
Well, it's a JS client to work with CouchDB or Couchbase databases wich can also work with SQLite but again I only need to store a Token..
So apparently the best option for Android/iOS cross-compatibility should ironically be WebSQL, but is no longer being developed and I have to guarantee long-term support.
So my question is: are there any other options I'm missing to securely store an access Token? If don't, wich of the above ones should be the best choice for this task?
After doing some research I will share my conclusion.
Funny enough, none of the above candidates are suitable for securely storing an access Token. The approach should be using a native solution for both Android (Shared Preferences) and iOS (Keychain).
In the particular case of Ionic, a broadcaster plugin for Cordova could be used to communicate JS with Native so you can access the stored data.
The only secure way is using "httponly cookie". However, since april 2020 Apple uses wkwebview which has cookie problem.
SQLite is the best option to go with as the content of DB will be encrypted and saved. Also native apps rely on SQLite to save data.
To make CRUD easier with SQLite, I have created a wrapper library. Please check it here
Go for LocalStorage, it is the best way to store