The security on my consumer_key and secret has been compromised and I need replacement keys. Three days ago I filled out the form for a consumer_key and secret. It did it the same way I did it when I set up my sandbox account and then later moved to my production account.
Evernote says they send out consumer_key within two days of request, but I haven't received anything in three days. Am I going about this the right way?
Should be taken care of now, sorry about the delay.
For others, FYI: we do indeed keep an eye on questions tagged evernote on Stackoverflow.
Related
Although I fully understand the use of AppCheck, I still wonder how it can help against spamming request to an API endpoint.
In the scenario of a hacker using OpenBullet or whatever hacker tool to spam thousands of requests per minutes to a specific endpoint (for example, a Signup endpoints to create thousands of fake profiles in a social app):
once the hacker got their hand on the appcheck token from the device, can't they simply attach it to the request's header, and spam all they want the api endpoint that we secured from our backend by checking appcheck token?
I mean, as long as the TTL didn't expire, I guess all their requests will pass the check thus they could use their hacker tool and pretend to come from the untempered app? Or am I missing something?
I guess a solution would be to:
1- forceRefresh the appcheck token on each fetch request from the mobile app
2- expire the received appcheck token programmatically after successful verification from the backend, so that further request would need a new one that can only be generated from the app, thus making it harder for the hacker?
Any help is appreciated! :)
I'll put it in a different way. While AppCheck offers a level of protection to your resources, it does not guarantee 100% protection. The sample you gave is an instance on how it could be bypassed. But what can't be factored out is that AppCheck makes it harder for a malicious actor to roam around your services and consume them on your budget.
Take a look at this section from the documentation. Also take a look at this question as it was asked after your question and had a firebaser (Frank) corresponding to it.
I'm writing a web app that is very tied to a different app (Twitch), so my plan is to only offer logging in through them. I'm trying to come up with an auth scheme for my app, and am thinking about implementing it by just packaging up the OAuth2 creds I get from Twitch, and setting that as a JWT cookie. See diagram of auth design
I'm having a hard time finding another example of someone doing or suggesting this, so I get the feeling I'm missing some reason why this is a bad idea, but I can't figure out why. The cookie is a JWT so it's signed, and since the tokens are all from Twitch they can be revoked on their end if necessary. And since all the Twitch creds I need are in a cookie, I don't need to store any access tokens in my DB.
So am I missing something that makes this a bad idea, or is this a secure enough solution to use?
This is a really interesting question. Sadly the answer to this is "it depends", based on the risk / reward to your app and business. Let me try to clarify that to help.
Let's assume that in your system authentication is core to the service. So essentially if your users cannot authenticate then they are not able to access the system.
Using a third party to provide authentication has many pro's and con's. Obviously the pro's are around not having to manage credentials, password resets, attempted attacks on the credentials etc. Also, there are advantages to the customer of not having another set of credentials to manage.
The con's largely are around the dependancy on the third party, if Twitch goes down then no-one can use your system. (This might be true anyway, based on your description).
Essentially, what I recommend is that you weigh up the pro's and con's in your environment. Assuming that the pro's outweigh the con's then using OAuth2 is a great way of authenticating.
While I don't have an example to hand of a website using only 3rd party auth I do believe the industry is getting there. Many sites have 3rd party auth at the top of their sign in options showing a preference over creating a new set of credentials. You don't have to look much further than StackOverflow that has the following order:
Google
GitHub
Facebook
StackOverflow account
While testing the security of one of our product, a web application, using the REST API of Firebase we got surprised when we realised that refresh-tokens never expire in the V3 of the Firebase implementation, allowing any refresh-token to create new tokens forever.
While local-storage seem a reasonably safe solution today, we are concerned by the possibility that it could fail tomorrow, even for a short amount of time, and that we cannot stop someone from using any of these refresh-tokens.
Two factor authentication will help mitigate the issue, but the first step would become compromised nonetheless.
Is there a way to blacklist tokens, or similar behaviour, with Firebase, without handling all tokens exchange, such as minting, ourselves? We could not find such feature when going through the doc.
Any advice appreciated.
Authentication sessions don't expire with Firebase login. But the ID token will have to be refreshed hourly, to keep access to the services. If you disable an account, refreshing the token will fail and the account won't be able to access services anymore. There is no way to invalidate individual tokens.
Firebase recently implemented revokeRefreshTokens() inside the admin sdk. Although this will not let you kill an invalid JWT, it does allow you to prevent a refresh of the token (from my testing so far at least) and it allows cleaner control flow inside firebase database.
See Admin Manage Sessions For rough examples
I have a subscription Official Account and I'm trying to use the basic js sdk test.
I'm using the sample code at the bottom of this page.
It's supposed to work with very little manipulation, but I'm not sure what to do : for example I found in the code "YOUR-APPID-HERE", where I need to put my appID, but it's not specified anywhere. I could be missing other things like this, very basic setup I just don't know of. For example I don't know what to do with the .json files : access_token.json and jsapi_ticket.json.
Should I leave them blank of fill them with my info ? If so I know my OA token but I don't know how to find the ticket.
I'm getting {"errMsg":"config:invalid signature"} but I don't know how to apply most of those fixes.
What I've done so far:
Declared my domain in the official account settings
Uploaded the files on my server
In all.php, I've replaced the arguments in $jssdk = new JSSDK("YOUR-APP-ID", "YOUR-APP-SECRET"); with my appID and appSecret
I'm sorry my questions are a little fuzzy, I find it hard to go straight to the point and to give clear context at the same time.
TL;DR is I'd need someone who's made the demo work to tell me what the basics are, I'm sure a lot of people would benefit from it.
Thank you very much !
first let's try to clarify things out.
the access_token is provided by the wechatApi. It's the proof that you are logged in, with your official account. You can generate the access_token only with your appId and appSecret. Be aware that an access_token is valide only for 7200 secondes, so you need to have a function who renew this token before it expires.
access token doc
The jsapi_ticket gives you the access to Wechat JS API's endpoint.
You just need the access_token to generate it. It also need to be renewed quite often.
js ticket doc
The *.json provided in your exemple are used as a storage for access_token and js_ticket.
You can store the token and the expiring time so you can always renew them before it expires.
Note that the link you posted is not an official documentation. Very useful for an overview but you need to double check with this documentation
Also, wechat have now an official english doc
You can find more details for Oauth in here
Since the developer site update the other day, I have lost access to the sandbox.
I was literally using it an hour before the update.
I tried to retrieve my password, but my account is no longer found.
I tried to set up a new account, and it's telling me that I need to have a US registered business in order to sign up.
So, my question is, what does the rest of the world do when they need to test their site?
Am I missing something?
Thanks
Simon
Ok, Got it. PayPay support have said to create a dummy account. In other words, lie about having an American business. Once you've done that, go to applications, then sandbox accounts, and import the data using your old sandbox credentials!
I have the same problem. It appears to be even worse than stated. They appear to have 'integrated' the Sandbox login with PayPal account logins. So you have to have a live PayPal account. In other words developers must also be CFOs in their organizations, or else must be using PayPal as a means of exchange themselves, otherwise they don't exist.
Truly incredible.
Not to mention having cut off arbitrary numbers of existing developers in mid-stream.