I need to store user credentials in my app. I can store and retrieve the password with protectdata. But as soon as I push a new revision of my app I loose the credentials. It seems like appharbor cleans the ProtectedData Store.
Is this behavior on purpose? Is there a better way to store user credentials on appharbor. OAuth is not an options since it's a ftp account.
System.Security.Cryptography.ProtectedData
Changes to the local instance file system are not persisted across deploys on AppHarbor, so you'll have to store the data someplace else. We generally recommend using Amazon S3. You can use System.Security.Cryptography.ProtectedData.Protect() from the same API to encrypt data written there. Here's some sample code: protect bytes data .net
I'm not super familiar with this API, but you might get into trouble if you app us running on multiple AppHarbor instances using different user accounts.
Related
I am working with Google Firestore in native mode and CRUD'ing data within it using the "cloud.google.com/go/firestore" api in Go. Access to the data is wide open as long as you know the project id and using the Firestore API on a server. I don't want to try the rules until I figure out how to secure the data from server attacks that. Again, all the API requires is the project id to access the data so I need to lock that down firstly before I move any further. Rules are only for mobile/web clients from what I read and Server side clients completely bypass the rules. Please help. I do not want to use the Firebase API because attackers can still use the Firestore api to access the data.
It's unclear from the limited information in your question but, your Firestore database is not open to anyone with the Project ID.
The service is only accessible to any thing (human|machine) that has valid credentials. Either humans with e.g. Gmail accounts or Service Account key holders.
In either case, only identities that you've explicitly added to the project will be able to access its resources and then only those with the appropriate IAM roles|permissions.
Google provides an elegant facility called Application Default Credentials (ADCs) that simplifies authenticating clients.
I suspect that your code is using ADCs to authenticate you to the project|service.
Access to the data is wide open as long as you know the project id and using the Firestore API on a server.
If that is a concern, consider disallowing all access in the Firebase security rules for your Firestore database.
Also have a look at my answer here to understand why sharing your project ID is not a security concern, and in fact is necessary if you want to allow direct access from client-side devices: Is it safe to expose Firebase apiKey to the public?. If you don't want to allow direct client-side access, closing down the security rules (as they are by default, unless you choose test mode when creating the database) is the way to go.
I'm using a Google Service Account to push MySQL backups from our webserver to Google Drive using a Google API PHP client script setup as a cron job.
I now want to run the same script across multiple webservers, I'm not sure how to correctly configure the service account for this, should I?
Use the same service account and service account key/credentials across all servers?
OR Use the same service account, but add a service account key/credentials for each server?
OR Setup a separate service account for each server?
Your requirements/needs/whatever may vary, but this generally it won't wont matter how you do it.
Single project
Create a project on Google developer console, and create a single service account key file and share it across the servers.
Is the same as.
Creating a project on google developer console and creating three separate service account credentials with different key files.
You will be bound by the same quota limits because all are under the same project.
Three separate projects.
Now if you created three different projects and create a single service account credential for each of the different servers. Then you would see a difference as they are different projects so should be bound by different quota limits.
quota
The Google drive default quota is so high anyway i'm not sure that it really matters what you do.
Security
Even security wise if you have a different file and you were hacked on one server you would't gain or loose anything by the other servers not having the same or different key files.
I want to use the Direct Mail SDK(Java) directly within client application which is distributed across. The way to authenticate users within the application, I need to provide access keys as below,
IClientProfile profile = DefaultProfile.getProfile("cn-hangzhou", "<your accessKey>", "<your accessSecret>");
How can I prevent user to know the Access Keys and still prevent the need of third-party API? Is it possible?
First, it is bad practice to code an application that requires secrets that runs on the client. You should manage everything on the server and provide an API that the client software interfaces with.
Second, there is no way to hide those credentials once passed to the client. You could encrypt the credentials but at some point the client application will need to decrypt them. Even amateur programmers can figure out how you are processing your credentials.
Ignoring the above advice, Alibaba Cloud supports STS which provides temporary access keys. Using your Alibaba credentials, you would call AssumeRole which creates temporary access keys giving the user permission call DirectMail. You can limit the time that the credentials are valid. The range is 900 to 3600 seconds. After that duration the keys become invalid.
Keep in mind that 900 seconds is a long time. A bad actor getting access to those keys could send thousands of emails using your account. Therefore implement strong user authentication, STS and temporary access keys.
If you think that just keeping your interface secret is enough, don't. There are millions of script kiddies on the Internet poking at every IP address. Launch a new ECS instance and you will see attacks within hours.
As you said since it is a Java Web Application(assuming), currently I think of something using similar to JBOSS Vault to store the access keys securely.
If it is some standalone client application still you can use some encryption methodologies to store the data. But this will only prevent easy access to the data/keys. But it is not impossible. The best bet would be creating another third-party API
I am working on writing a program using the Google Tasks API in Python. I have downloaded and run the sample application from Google, and it comes with a file called client_secrets.json. I understand that the file is used for OAuth authentication, but my question is should I distribute this file to users? Should I push it to my public source repo? Or is it supposed to be kept secret? If I shouldn't share it, how would other users do the authentication?
Thanks for reading.
The Google API Client Library OAuth2 docs states,
Keep your client secret private. If someone obtains your client
secret, they could use it to consume your quota, incur charges against
your Developers Console project, and request access to user data.
So don't commit or otherwise distribute the file.
If you want to publicly share your application source code, instruct others to use their own Google Developer account to register their own Google Developer project and generate their own app OAuth credentials (client_secrets.json file) for use with their "installation" of the app.
If you were making the application commercially available, you would seemingly need to share the app credentials with them in a trusted, legally protected, or secure manner.
Apparently the client_secrets.json file does not have to be kept secret for installed application. From https://developers.google.com/identity/protocols/OAuth2?csw=1#CS in the "Installed applications" section:
The process results in a client ID and, in some cases, a client secret, which you embed in the source code of your application. (In this context, the client secret is obviously not treated as a secret.)
So if you're making a webapp, keep it secret. If it's a python app that you distribute to users and they run on their own, it does not have to be kept secret.
We are working on a service that will have website access for stats and other tasks, but the majority of use will be through a client gem and rake tasks. What is the best way to handle authentication for both pieces.
It looks like fiveruns_tuneup, getexceptional, New Relic and others have websites with username and pass, but use API keys stored in ./config/serviceName.yml Any reasons it is better to have API keys opposed to user/pass in the config (do they use keys because often the key is checked into SCM and used across the project, where ours would not be checked in and would be a per user setting)
GitHub has you put your public key on the github servers and uses that, but I think git supports public/private key by default.
Would it be preferred to keep a ./config/serviceName.yml or since we have to create a subdirectory with other information have ./serviceName/config.yml? (does the per user, not stored in SCM mean it is better to keep it all in one excluded directory?)
Just looking for some thoughts and ideas on best practices before starting implementation.
I recommend that you use username/password combos for website accounts, and API keys for any web services. Here are the advantages of this technique:
By linking API keys to an account, you could have many API keys for the same user. Perhaps this could be used for many remote web servers that consume this data service, or to perform unique tracking.
Attaching API keys to an account also lets you keep the user's username and password uncompromised since an API key will not contain them. Many users use the same username and password on many services, so you are helping to protect them.
You could limit access to portions of functionality for each API key, but give their username access to everything their account should have access to. Additionally, you can even give them the ability to limit how much access an API key might have.
Most of the major services (Yahoo! API, Flickr, Google API, etc) use accounts with a username and password to login to the web account, and API keys for integration points.
Never use user/pass when you can help it. The security issues are horrible. If the user/pass leaks out, you have to change your password or they get access to your whole account.
API keys are better because they're easier to change and can be limited to only the part you need access to with the APIs (ie, if someone has your password they can change your password. They can't if they just have an API key).
Different API key per client or secure token exchange (such as OAuth) is the best solution if you'll have more than just your client on the API.
The github approach is bootstrapping on top of existing git practices, however it's not a bad idea since presumably each user will have their own private key to match a published public one in the central authority. Since key-agent's already furnish a means of safe authentication this seems like a very safe approach. Public/private keys are a well thought out authentication scheme, which has unfortunately been reinvented many times to limited success.
The problem with the API key is that anyone who gets a copy of the API key can do whatever that authorizes. Storing the API key somewhere in the project begs the users to share a key. If you are associating public keys with a user, it is possible to grant rights to the client on a per user basis, and a proper key-agent approach suggests that those will not be stored in an SCM anywhere.
I'm not sure I follow what the distinction between config/serviceName.yml, or serviceName/config.yml is. It doesn't seem as if it would be pertinent if you have public/private keys as an authentication method for the client.