Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 4 months ago.
Improve this question
So, I am trying to safely store an authentication token using Angular, processed with additional encryption on top (in front end) and put it in browser local storage (so that not anyone can de-code it).
Many people recommend this method, but I came across several opinions that say even in such case one can access your source code through your browser and get your secret key to decrypt the Auth Token (for example experienced hacker).
Many people claim that Access + Refresh tokens are the best in terms of security.
So, my question is - what are standard practices for serving/ storing authentication token? Is token encryption in local storage good implementation or should we use refresh tokens (although, they are harder to implement)?
I think you should use both a refresh and access token for maximum security...the access token should have an expiration date and should be blacklisted after rotation(when you use the refresh token to get an access token)...if you need even more security,after rotation,the user should get a new refresh and access token
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 months ago.
Improve this question
If I have AppCheck enabled, how would it be possible for an attacker to make any Firebase call they want? What other vulnerabilities exist even with AppCheck enabled on a mobile app?
Firebaser here!
Please see How strong is the security provided by App Check? in our documentation for a high level description of the security offered by App Check.
App Check is only as strong as the underlying Attestation provider (such as SafetyNet/Play Integrity on Android, Device Check/App Attest on iOS, or reCAPTCHA on Web). If an attacker can bypass the security of the attestation providers (such as tricking reCAPTCHA into believing they are not a bot, or tricking SafetyNet into believing a rooted device is legitimate) they can abuse that vector to making calls against your API.
Additionally, App Check intentionally allows for limited time-bound replay (configured by the TTL on the App Check token). This allows you to use a single attestation to protect multiple API calls. However, if an attacker uses a legitimate device to obtain a valid App Check token and then somehow intercepts that token (by either rooting the device or sniffing their network traffic), they can use the token to make calls against your API until it expires. However the cost of performing this attack generally outweighs any benefits, and becomes very costly and infeasible to perform at scale.
This is all assuming App Check is not only enabled but also enforced, and you are using it in conjunction with secure user authentication and rigorous authorization logic such as well defined Firebase Security Rules.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
In my app, I use a rest API to connect to an online web service. For this, I use sensitive data like username password but also some keys. You can see the problem when someone decompiles my app and sees the sensitive data in my code. I am using Firebase in my app. My question is what the best way could be to store sensitive data. Remember that this is the same for all devices and the info would be around 5 strings. Things I have found online are: using Firebase Database with security rules (this would be ideal but I cant get it to work for only my app), using the last pixels of a picture to store strings. Specifically, I am using Salesforce as my web service.
Thanks in advance.
I would not use username/password for your app to connect to Salesforce. Use oAuth instead and then you don't need to worry about storing passwords. You can also look at encrypting the key fields using shared keys. Your Salesforce app can decrypt the data using the encryption classes OOTB.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
If I have a webapp (website) and I am posting data from the user's browser to Firebase, how does it prevent some other website or hackers from posting to my database?
If there is an API key or token, it is viewable from the traffic from the user's dev console. Can it be identified by which website the user is on, but even so, the hackers can spoof a website in the HTTP traffic data.
Without backend code, if I post 10 game coins for a user, how can I stop the user from posting 100 game coins to the same Firebase database if there is no server code to control that?
(there is a post about other hackers hacking it will be difficult, but what about a hacker hacking his own account?)
If I have a webapp (website) and I am posting data from the user's
browser to Firebase, how does it prevent some other website or hackers
from posting to my database?
It doesn't really "do" anything by default. You have to do something.
If there is an API key or token, it is viewable from the traffic from
the user's dev console. If it is identified by which website the user
is on, the hackers and spoof a website in the HTTP traffic data.
All traffic sent between client apps and Firestore is encrypted, usually over HTTPS or other encrypted socket, so it's not visible to anyone who can just see the stream of encrypted bytes between the client and server.
Without backend code, if I post 10 game coins for a user, how can I
stop the user from posting 100 game coins to the same Firebase
database if there is no server code to control that?
Your security rules will prevent that, but security rules might not be robust enough to stop unwanted changes. So you might need a backend for that. You shold always assume client code has been compromised, since it runs on hardware you don't control.
(there is a post about other hackers hacking it will be difficult, but
what about a hacker hacking his own account?)
When you use security rules (or whatever mechanism) to gate access to individual authenticated users, you should assume that the user isn't bound by the logic in the app. Someone can take their own auth token and use it in calls to Firebase services to do whatever they're allowed to do with that account. This is really not any different than any other permission system.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
So, I'm using a simple, email/password authentication system and I wanted to know if there is a way to encrypt the information that I push there. If not how can I assure the user that their data is encrypted and their privacy is safe? Thanks for the answer!
No, you can't encrypt anything in Firebase Database. Google encrypts everything by itself and you don't need to care about hacker attacks. The only things you need to care about are the security rules and keeping your program, not too server or mobile dependent.
If you do want to assure your users that their information is completely private and only known to them, then you can manually encrypt the information. There are many encryption algorithms, but I would recommend the AES Algorithm, as it is fast and efficient. The encryption key can be stored locally on your device without having to transfer it to the server, ensuring the user's privacy.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
How do we go about generating a firebase download token within the admin SDK, knowing it can easily be done with the client SDK.
I understand the client SDK acts as a wrapper on the storage SDK, therefore it adds this functionality, but then, why not giving the admin SDK the same option. I just want to know how to generate that token myself, with the current SDK, because I need the URLs to have the same format as the ones generated within the client, and using getSignedURL, the format is way different and does not abide to the firebase storage rules, nor it is permanent, as it expires after a set amount of time.
It sounds like you're mistaken on one point. The download URLs created by the Storage SDKs on the client do not actually "abide by security rules". Anyone who has that download URL can read the object. This is no different than signed URLs generated by the server SDKs.
Both types of URL are functionally equivalent. The obvious exception is that signed URLs have an expiration, but you can set that expiration arbitrarily far in the future that it makes no difference.
To put it in short - client download URLs can't be generated by the server SDKs, and signed URLs can't be generated by the client SDK, but it doesn't matter because they serve the same purpose.
In order to get an URL exactly like the one getDownloadURL from the client SDK, while using the admin SDK, all you need to do is to update the object's metadata with a key called firebaseStorageDownloadTokens. Contrary to what everyone else says, you don't need that signedUrl.
$uuid = someUuidMethod();
$object->update([ 'metadata' => [ 'firebaseStorageDownloadTokens' => $uuid ] ]);
The moment you run the above, you'll get an error as follows:
serviceaccount does not have storage.objects.update access
In which case, you need to go to the IAM section in GCP Console, select your service account ( the one mentioned in the error ), Edit roles, and add another role Storage > Owner.
Run the update command again, and job is done. You can now generate your own tokens. It's needed when you rely on cloud services to work on your storage files.
Hope it helps :)