I am using amazon MWS service but getting throttling because i'm using the same key for entire application. Can we create multiple access and secret key to handle this throttling issue?
Please anyone can help me... what can be the best solution for this?
In principle Yes BUT it's not as simple as that, and I suspect that Amazon's certification process would not authorise your 2nd app if you supply the same developer info (address etc...).
To recap, when you want to write an app that accesses MWS info, you need to submit your app's details for authorisation by Amazon. eg what kind of security do you implement to protect buyer sales order details etc and if granted, you are then able to "attach" your app to a seller's account via Manage Third Party Apps, and, with your Apps credentials, get the auth token - but you knew this already...
And if you're getting throttling issues, then I'd revisit the help page and digest what they say.
Related
I am trying to setup Web Security Centre for my Google AppEngine App.
I tried using Google as well as Non-Google Account for Authentication where I provided Username and Password but it errors out saying
Could not sign in using the provided username and password
I tried below things:
Tried creating a test account vikash-security#gmail.com (in compliant with google naming convention) in my gmail and using the same for authentication. (this user had same domain name as my company's)
Created a test user with different domain name and used it for the authentication.
Both the above users have access to my Google App.
Both of the way did not work and throws the same error. Can anyone help me out with the same?
Google enforces a real name policy on G+ accounts. Your test account may be blocked from G+ if the name does not look real. at [1]. It will only work if the Google account you provided should have been G+ verified (with proper G+ setup), but still need to retry after the first failed attempt and it eventually will work.
There are few issues related to this and if this is a bug it will be resolved soon.
I raised this concern with the Google support team and got to know that there was issue from their end and they got this fixed and now my web security custom scan is working with non-google authentication.
I am developing an api that will be eventually behind a paywall - In my scenario, clients would sign up, pay for an api tier/plan and afterwards be able to consume that api from their own apps. Depending on the tier chosen they will have certain usage limits on the api ( e.g. throttling/limits and various apis available depending on tier)
I was thinking of distributing an api_key for ease of use by clients but not sure if thats a good idea or how it would fit in with the Jhipster security model.
I guess I can just have clients sign in to grab JWT access/refresh tokens but that makes things a bit more complex for prospective clients.
Is the answer to go 'full Oauth2' and create separate 'App Clients' of an Okta Authentication server and give each customer their own "clientId + secret" that they can use to obtain access tokens ?
Any advice ?
thank you
I think it would be easy for you to go with jhipster UAA server which It serves as:
An OAuth2 Authorization Server, based on Spring Boot's implementation
An Identity Management Server, exposing a user account CRUD API
it is easy to integrate with your already jhipster tech stack and it is based on OAuth2 standard.
but for the metric and limitation part you’ll need some coding and a separate fast and high available storage to keep track of the usage of API's and a file provided to your HAproxy as a blacklist for people who reached their limit to be redirected to purchase page.
Is there a comprehensive list over which keys and UUIDs provided by Azure are sensitive information?
For context, I am setting up a react app using react-adal. This requires me to provide the tenantID and clientID to the app. It would be trivial for anybody with a little know-how to extract those UUIDs from the application given the way I currently have it setup. It's a static app with no back-end service, so it all runs in the browser. I have the application setup as a App registration (registered app?), in AzureAD to allow users to login with their Office365 account for my organization. Almost all the tutorials online show setting it up the same way I am. However, some tutorials with screenshots almost always have the clientID censored in the screenshots.
Edit: While this question does solve my immediate need, I am in search of documentation from Microsoft concerning security best-practices in regards to Azure keys, UUIDs, etc.
Your tenant ID is public and refers to the entire Azure AD directory. It must be in order to be used for authentication. You can find it here.
Your client app ID is not secret, as it must be used with the client secret in order to obtain a token.
When you reverse apk files you find API keys/token somewhere in properties, manifest, strings etc. Sometimes some API keys/secrets are obvious and you can understand security impact and risk of exposing these keys. Please let me know what's the security risk involved in these keys:
Google Maps API Key
Fabric API key (probably can forge crash data)
Twitter/FB Consumer key and secret (no auth tokens)
Crashlytics SDK developer's token
Thanks
Google Maps Api Key are now subject of billing as per https://developers.google.com/maps/documentation/javascript/usage-and-billing, thus you will want to protect it very well and same goes for Twitter that started to charge for some features in their API as per https://www.theregister.co.uk/2018/08/16/has_your_twitter_app_stopped_working_heres_why.
So if they are not protected they can be hijacked from your application and used in your behalf and the usage charged to you.
Regarding the other keys I cannot comment on by now, once I don't have enough knowledge about them.
Firebase provides database back-end so that developers can focus on the client side code.
So if someone takes my firebase uri (for example, https://firebaseinstance.firebaseio.com) then develop on it locally.
Then, would they be able to create another app off my Firebase instance, signup and authenticate themselves to read all data of my Firebase app?
#Frank van Puffelen,
You mentioned the phishing attack. There actually is a way to secure for that.
If you login to your googleAPIs API Manager console, you have an option to lock down which HTTP referrer your app will accept request from.
visit https://console.developers.google.com/apis
Go to your firebase project
Go to credentials
Under API keys, select the Browser key associated with your firebase project (should have the same key as the API key you use to initialize your firebase app.)
Under "Accept requests from these HTTP referrers (web sites), simply add the URL of your app.
This should only allow the whitelisted domain to use your app.
This is also described here in the firebase launch-checklist here: https://firebase.google.com/support/guides/launch-checklist
Perhaps the firebase documentation could make this more visible or automatically lock down the domain by default and require users to allow access?
The fact that someone knows your URL is not a security risk.
For example: I have no problem telling you that my bank hosts its web site at bankofamerica.com and it speaks the HTTP protocol there. Unless you also know the credentials I use to access that site, knowing the URL doesn't do you any good.
To secure your data, your database should be protected with:
validation rules that ensure all data adheres to a structure that you want
authorization rules to ensure that each bit of data can only be read and modified by the authorized users
This is all covered in the Firebase documentation on Security & Rules, which I highly recommend.
With these security rules in place, the only way somebody else's app can access the data in your database is if they copy the functionality of your application, have the users sign in to their app instead of yours and sign in/read from/write to your database; essentially a phishing attack. In that case there is no security problem in the database, although it's probably time to get some authorities involved.
Update May 2021: Thanks to the new feature called Firebase App Check, it is now actually possible to limit access to your Realtime Database to only those coming from iOS, Android and Web apps that are registered in your Firebase project.
You'll typically want to combine this with the user authentication based security described above, so that you have another shield against abusive users that do use your app.
By combining App Check with security rules you have both broad protection against abuse, and fine gained control over what data each user can access.
Regarding the Auth white-listing for mobile apps, where the domain name is not applicable, Firebase has
SHA1 fingerprint for Android apps and
App Store ID and Bundle ID and Team ID (if necessary) for your iOS apps
which you will have to configure in the Firebase console.
With this protection, since validation is not just if someone has a valid API key, Auth domain, etc, but also, is it coming from our authorized apps and domain name/HTTP referrer in case of Web.
That said, we don't have to worry if these API keys and other connection params are exposed to others.
For more info, https://firebase.google.com/support/guides/launch-checklist