I noticed that a GET on a notification feed responds with a next attribute containing the API key. Not the secret, just the API key.
I'm curious whether this is safe to expose to an end user?
Example:
"next": "/api/v1.0/feed/notification/user8/?id_lt=8a4ba960-76fc-11e7-8080-800139637857&api_key=blahblahblahblah&limit=1&location=unspecified&offset=0"
The data payload you send to any of our API endpoints is encoded using your API secret into a JSON Web Token payload in the header for most calls. And guessing your very long API secret to properly encode anything would take an awfully long time, so yes we feel it's safe.
Also, you cannot log into the dashboard using your API credentials in any way so your billing information is safe (we still recommend turning on two-factor authentication in the dashboard though)
Related
I would like to expose a problem to which I just cannot find a solution, although I have been informed several times on the web, the resources I find do not satisfy my curiosity.
The question is the following:
Suppose we have a rest API in node js (express) on the following endpoint -> / stars.
Suppose we want to sell this API with the endpoint/stars to a certain target of customers, the endpoint will therefore only allow customers who buy the API to use it.
The problem arises spontaneously, let's suppose that the pizza company buys my API and that I generate an access token for them, then they would call my endpoint with their token to have the resource, so far very good.
However, all the requests are easily visible.
Example Chrome> dev tools> network and I see not only the endpoint with the full address, but even the payload that is passed!
So as an attacker I could very well (without paying the API) catch the pizza industry using the endpoint/stars with a token, copy everything and slap it on my services by providing the same token and the same endpoint.
I already know the existence of tokens like jwt but they don't solve the problem anyway, as that different token only has the expiration.
Even if it expires after 15 minutes or after 3 minutes, just retrieve another one and provide an identical request with the same token, would anyone be able to direct me to a solution?
The only one I've seen to find a solution to this is Instagram that sends behind a payload of thousands of lines, is it really the only method?
note: it is not even public.
#xVoid
The first thing you can set an encryption/decryption module for your response data with the help of the crypto module in node.js, Here you send encrypted response and the your API client decrypt your response and use it.
You can set a key for your API it means every time your client or user send you a request they have to send that key in the body, not header so other people can't
get your data because they don't have that key, and in express you can set middleware to validate this key is exist or not if not simply return "You are not authorized"
If you aren't getting any point or you want to go deep on particular thing just let me know
You may simply use http-only cookie and send the token in cookie, instead of normal header
A customer using your endpoint should not be sharing their API keys with the end-users.
This means that any customer using your service should create at least a proxy server to your specific endpoint.
CLIENT GET /pizza FROM CUSTOMER -> CUSTOMER GET /pizza?apiToken=<...> FROM SERVICE
Obviously there can be a man in the middle attack between the CUSTOMER and your SERVICE but that's is unlikely to occur using SSL (Related: Are querystring parameters secure in HTTPS (HTTP + SSL)? )
If a CUSTOMER suspects that their api key was leaked they should revoke it and request a new one to your SERVICE.
I am building a API suite to connect to our application. Each user will have an unique API key which will be passed in the Header.
I am here to ask, what is the best way to authenticate the user? I donot want the user to pass the API key without any encryption ?
I am passing the API key like this :
$headers['x-axpr-auth'] = '<API-KEY>';
Since, I am building the API myself, I have the flexibility to use different encryption/authentication techniques.
Using HTTPS is pretty much mandatory in this case so I'm going to assume you (will) do that.
If you have an API key with long-term validity, then you should consider using some kind of "temporary token" with (very?) limited validity - so the attack window is much smaller.
This is similar to using Basic Authentication (sending password with every request) versus sending credentials only once and using session cookie afterward.
You should look at existing authentication/authorization schemes - OAuth2 (with access and refresh tokens) may be relevant since you're building APIs. OpenID Connect builds on top of OAuth2 and provides a proper authentication layer.
Apart from that, it's uncommon to explicitly encrypt API token in an HTTP header, since the whole communication is already encrypted using HTTPS.
I have a react native application that I want to make API calls from. I am getting confused about how I should be authorising these calls on the node back end.
Method 1:
User logs in to application and authenticates, I then return a JWT with refresh token. This is then stored client side / in react native app and is sent upon each request. If token expires, then refresh using refresh token.
Method 2:
Create API key for each client. When a user creates an account, I create an API key (or maybe access key and secret key like AWS does) and send that with each request.
Is there a preferred / recommend method out of these two? Perhaps they are not mutually exclusive? Do I still need to provide an API key to my react native app so that it can make API calls and then I use JWT for authenticating users?
In my personal opinion,
You may go for the Method 1, since it is not secure to store / create API keys or Secret keys on the client side.
JWT are more secure, you may read the following article
In the Method 2, you will most probably try this approach
Generate Api key based on client IP or the device token, whatever suits you, and set an expiration time including the AES techniques, then decrypt it on the server, check the client's IP against the requestor IP and also the expiration time.
Complexity and time taken to do Method 2 is much more that Method 1, also considering I might have not covered all the security use cases.
Do I still need to provide an API key to my react native app so that it can make API calls and then I use JWT for authenticating users
You can make the http calls normally. The recommended way is call your token generation api and then authenticate other valuable api's based on that token if you're using JWT
Hope it helps.
I figured this has been answered before, but a quick SO search didn't yield anything.
I have a private API that is locked down by an APIKey. This key needs to be passed for each request. With this key you can access any part of the API. Obviously that's pretty open. For the most part this is acceptable. However, there are cases where I want to ensure that the request is sent by the owner of the data.
For example, consider an update or delete request. You shouldn't be able to make this request for someone else's data. So in addition to the APIKey, I'd like to have something else to ensure that this user making the request is authorized to perform that action.
I could require that an ownerID be passed with such request. But that's quickly forged. So what have I gained.
I am interested to hear what other members of SO have implemented in these situations. Individual APIKeys? Dual-authorization?
If it matters, my API follows the REST architecture and is developed with PHP/Apache.
API keys should be unique per user. This will verify the user and that they should have access to the data.
If you want to be even more secure you can have that api secret be used as a refresh token that can be used to retrieve an access token with an automated expiration.
SSL for all requests is also suggested.
Each API user has a unique API key. This key identifies them as a single user of the system. When dealing with more sensitive data, I've used client side certificates for auth, however Basic Auth + requiring SSL is usually sufficient.
When the request comes in, map the API key to the user and then determine if that user "owns" the resource they are trying to interact with.
The whole "determine the owner" part is a separate issue that can be tricky to do nicely in an API depending on how well the system was built. I can share how we've done that in the past as well, but figured that's a bit off topic.
Suggest you should consider using Oauth. In summary this is how it should work.
Each application making the API calls will need the respective application level APIkey for authorization through the Oauth process. Apikey here would just represent the application (client) identity.
Each end-user associated with the usage must authenticate themselves separately (independent of the apikey) during the Oauth authorization process. The users identity, associated context such as scope of authorization is then encoded into a token called access token.
Once the application obtains this access token, all subsequent API calls to access resources should use the access token, until expiry.
On the API implementation side, the access token validation should reveal the end-user context (including the scope of access that is granted during the Oauth process) and hence the access/authorization to use a specific resource can be managed by the resource server.
in my project, I am calling webservice with http get request.
API key is also there in http get parameter.
in j2me devices before connecting to the internet it is showing the URL and asking for permission to user.Here user can easily see my api key.
and i don't want to store api key in my application also.because using decompiler
anybody can get api key from applciation.
So my question is where to store api key and how to use it for calling web services?
If the API key is required to use the webservice, then you MUST store it somewhere in your app...By the way, you can store it in some kind of an encrypted way, so a simple decompile does not reveal it.
If the user should enter the API key, the you can store it in the standard RMS store outside of your app, again maybe encrypted.
An for the URL issue, use HTTP POST request instead of HTTP GET, and send the key in the post data.
You could encrypt the api key and store it as you do just now and then POST it to the web service.