I am using Kloudless to enable efficient file uploading on the client side.
However, my app currently exposes both my Kloudless API key and account id -- they will be public on the client side.
In addition to setting the trusted domains, is there any way to protect my keys right now while still enabling efficient file uploading?
You are absolutely correct that the Kloudless API Key should be kept confidential and not included on the client-side. Instead, I would use the user's Account Key instead. Account Keys function the same way as API Keys, but only provide access to the connected account.
Here is some information on using Account Keys with the File Explorer:
Account Keys can be returned from the File Explorer by setting the "account_key" option to true. They are only returned to Trusted Domains (added via the Developer Portal). Once you have them on the client-side, you can make requests using them. In addition, they can be retrieved via the backend as well.
Account Keys also come in useful when you would like to show returning users accounts they have already connected previously. By storing Account Keys for the user, you can render them on the client-side and pass them in via the "keys" option while instantiating the File Explorer, which will display the corresponding accounts to the user automatically.
Related
I have a pretty standard application written in Java which also runs queries against a DB. The application resides on GCP and the DB on Atlas.
For understandable reasons, I don't want to keep the username and password for the DB in the code.
So option number 1 that I had in mind, is to pass the username and password as environment variables to the application container in GCP.
Option number 2 is using Secret Manager in GCP and store my username and password there, and pass the GCP Credentials as an environment variable to the application container in GCP.
My question is, what is the added value of option number 2 if it has any? It seems that option 2 is even worse from a security aspect since if some hacker gets the google credentials, it has access to all of the secrets stored in the Secret Manager.
I don't know what are the best practices and what is advised to do in such cases. Thank you for your help.
Having credentials in GCP secret manager will help you to keep track of all the secrets and changes in a centralized location and access globally from any of your app.
For a standard application where one JAVA is connecting to a DB, may not add much values.
You may look into kubernetes secret for that reason.
If your application resides in GCP, you don't need a service account key file (which is your security concern, and you are right. I wrote an article on this)
TL;DR use ADC (Application Default Credential) to automatically get the service account credential provided automatically on Google Cloud Component (look at metadata server for more details).
Then grant this component identity (by default or user defined, when supported), i.e. the service account email, to access to your secrets.
And that's all! You haven't secrets in your code and your environment variable, neither the login/password, nor the service account key file.
If you have difficulties to use ADC in Java, don't hesitate to share your code. I will be able to help your to achieve this.
To use Secret Manager on Google Cloud you need to install the Secret Manager Java SDK Libraries. This documentation shows how to get started with the Cloud Client Libraries for the Secret Manager API, you only need to go to the Java section.
This Libraries helps you to access your keys in order that it can be used by your app.
The following link shows how to get details about a secret by viewing its metadata. Keep in mind that viewing a secret's metadata requires the Secret Viewer role (roles/secretmanager.viewer) on the secret, project, folder, or organization.
I recommend you to create a special Service Account to handle the proper permissions for your app, because if you don’t have a SA defined, the default SA is what is going to generate the request, and it is not secure. you can learn more about how to create a service account in this link
On the other hand, you can find an example on how you can use the following guide that contains a good example of finding your credentials automatically, that's more convenient and secure than manually passing credentials.
Im writing a application where I can have multiple users login and store their password in windows credentials. I currently can successfully validate the user's login. My question is where is the proper place to store the permissions(ex access to a certain page). I have several databases but I don't think that's secure. Possibly encrypt the data in the table. Or maybe in the local settings
You should use the PasswordVault class in a UWP app for storing user credentials so the app can validate silently to your cloud service later. Here are details on how to use the API.
for non-password, non-sensitive data, you can store it in LocalStorage or RoamingStorage but that is not secure. The only secure location to store data is on your service. Look to use something cloud-based like Azure Mobile apps to store that kind of info.
I've built a simple messaging application with NodeJS on GCP that, at the moment consists of a single compute engine instance. I'm using this to learn the stack and how GCP sits together.
My application has it's own user/password registration system and allows users to message each other in 'groups'. These groups can consist of 1...n users and one user is responsible for adding/removing users from a group. They can do this at any time.
I want to allow the users to upload pics and ideally I will then store them in Google Storage. But I want to make sure that only users in a room where an image is uploaded can view that file.I know that GCP makes use of IAM roles etc. but with the authentication being in my system am I expected to update IAM policies every time via the API? In a scaled solution would this work?
My initial thought is that I should do the authentication at an app level. e.g my Compute Engine instance can talk to Storage so when a user requests to a view an image by its url - such as example.com/uploads/:id
I then validate that the current user can view the upload with id :id and if they can, then serve the image from the app. Would this work? Would it be compatible with utilising Google CDN? Is there a preferred solution for doing something like this bearing in mind I'm not using firebase (which I understand can use access tokens for auth) but I'm using my own authentication based on username/password combos with sessions?
For examples of sharing and collaboration scenarios that involve setting bucket and object ACLs, you may take a look at Sharing and Collaboration. As you mentioned and also noted here, you can create a service that authenticates users and redirects them to a URL signed by a service account and this solution helps the scaling amount of users as well.
You must give Cloud CDN permission to read the objects by adding the Cloud CDN service account to Cloud Storage's ACLs for restricting the users on reading the objects.
I should also add that Cloud Storage is integrated with Firebase and you may acquire Firebase Security Rules for Cloud Storage to authenticate and authorize the users.
So it looks like I actually have 2 options here.
I can use signed urls https://cloud.google.com/storage/docs/access-control/signed-urls#signed-urls and grant temporary access to the files to the users in question. I would just need to regenerate this whenever required.
My second option (event though I said I don't want to migrate) is to use Firebase Auth. I wasn't aware it actually supported email/password migration and validation and is actually free regardless of number of users. The only thing I'm not sure on here is how Storage is configured with relation to my current GCP project.
I make speech recognition App using Bing speech API with javascript library.
But I need to contain SubscriptionKey to Html/JS code using Library.
I think another person can see my key and use it.
How to save my key?
Can regenerate key dynamically on each user access?
or
Can set expire limitation to key?
You are recommended to make calls from the server side. You can initiate a call from your client to server, where your client is whitelisted and then make a call to the API. Alternately, you can use Azure Key Vault to generate secret and use that and change that often. Further, you are recommended to change subscription keys and/or Azure Key Vault secret often to limit exposure.
A similar question but for Bing Maps is posted here: http://www.garzilla.net/vemaps/Protecting-Your-Map-Key.aspx.
I want do develop simple web app using Node.js (MEAN.io Fullstack). I am using Passport as authentication middleware. I especially want that on my app users can login with Twitter account.
Are my API key and API secret that i define in config/production.js file "secure". Can someone see their value and misuse them ?
They are as secure as your server is. If someone breaks into your server, then it has full access to the source code and also the API keys.
If you trust your code to store passwords for databases, salts (e.g. for session cookies), etc, then you can trust it also for your API keys.
Please note that it's pretty standard to store API keys inside source/config files (in a non-publicly accessible folder - as would "public/" be, for example).