I'm using parse.com is there a way to reset the client and rest keys?
I reset the master key, but that didn't seem to do it. (I verified that the Master key changed).
I could delete the app since it isn't yet in production, but was hoping there was a less draconian alternative
Your only option is to e-mail parse.com support and ask them to do it. There is no option on the web interface to do it. Generally changing these keys breaks clients so it isn't something you do regularly (if ever).
Related
I'm following the instructions in the Heroku Postgres docs for creating an external application that connects to Heroku Postgres for its data layer. The instructions mention that the credentials are automatically rotated and I must handle this myself.
I read more docs to learn about webhooks existing to help notify the rest of your system that changes have happened in your Heroku services. This made sense to me to be an area where the Heroku devs would have implemented this. There must be a webhook that exists that I could use to be notified when the credential rotation happens. I found that there was the api:addon webhook which had the update event. I tested this webhook, expecting this to be what I was looking for, but I found that it was not fired upon credential rotation. It was only fired when I provisioned or deleted more Heroku Postgres add-ons.
Since the webhook I need doesn't exist, I coded a workaround where I expect a PostgreSQL library auth error to be thrown while my AWS Lambda executes. If an error is thrown, I assume it's from the rotation and I have the still running Lambda function fetch new credentials using the Heroku API and try the PostgreSQL query again, at which point it works unless there are other errors. I tested this while manually rotating my credentials and it worked okay, but it's kind of ugly code. See here for a detailed example.
So at this point, I'm wondering if the webhook I'm looking for does exist and I just wasn't able to find it. Or, if it doesn't exist, I would like to request it as a new feature. I understand that the Heroku team may not want people picking their add-ons a la carte, and they want people to use the entire Heroku platform, but I think it would add a lot of value to the Heroku platform. Personally, I've enjoyed getting into more and more cloud services as I learn since I'm usually able to choose them a la carte. For example, AWS doesn't forbid me from only using S3 and nothing else from them. They do as much as they can to make it easy for me to link my applications to it, no matter what other cloud services I use.
I contacted Heroku directly to ask if this type of webhook existed and I received a useful response from them:
There isn't a webhook specifically for credential rotations, although
with a bit of logic you can sort of recreate the same thing. Whenever
you Postgres credentials rotate, it will trigger a new release, which
does trigger a webhook. You can use that to inspect the release via
the API to determine if the values changed.
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
Starting completely from scratch with a new server. Do we need to specify a filekey? If so, does it has to be something specific when I use AWS storage or not?
In parse-server you dont have to put this keys
this is from parse-server wiki
Parse Server does not require the use of client-side keys. This includes the client key, JavaScript key, .NET key, and REST API key.
The Application ID is sufficient to secure your app.
However, you have the option to specify any of these four keys upon
initialization. Upon doing so, Parse Server will enforce that any
clients passing a key matches. The behavior is consistent with hosted
Parse.
The problem with this keys that they publish with you app and all of them (javascript key file key...) are not private. So their is no security benefit to use them.
Our organization has a number of Rails applications (websites) deployed to Heroku. A former devleoper has left the organization, and as good practice we want to change the Heroku API key associated with our account to prevent any modifications to the apps via the Heroku CLI.
I know that the Heroku API Key is used for Heroku CLI access (it gets cached in ~/.heroku/credentials), but not certain what else it is used for. Specifically, do 3rd-party add-ons in the Heroku platform (e.g. New Relic, Hoptoad/Airbrake, Sendgrid, etc) use this, and therefore require reconfiguring if the API Key is changed? Heroku throws up a fairly generic (and non-informative) error message when you click the "regenerate" button to change it.
Because the term "API Key" is so generic, want to be clear that this is the single API Key associated with each Heroku account accessible via "My Account" link. Image (and warning message) below.
Asked Heroku Support. This is what I got back:
"you can safely change your API key at any time, as we don't give it to any add-on providers. That alert is meant to remind you that if you added your API key to any application or service (ie for auto scaling, manually provision workers, etc) it will stop working until you provide it a new key."
I requested that they update the interface/documentation to make this more clear.
Also remove him from being a collaborator on all your projects so he can't push to them via git.
Out of curiousity (i'd never seen reset key in the admin) I tried it. When I then tried to use the CLI against one of my apps I was asked to reauthenticate - but i can't now get back in - doh! The same username/password works via the site. I'll ping support and report back,
UPDATE:
So it appears my problem is entirely due to the Heroku Accounts (https://github.com/ddollar/heroku-accounts) plugin that I'm using which stores a copy of the key in the ~/.heroku/accounts/ file. Support got me to remove the folder and it all works now - just something to be aware of if you reset your API key.
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.