How to protect client credentials in a desktop app?

user_12958532 0
Viewed 175

I have written an uploader (desktop) app for YouTube to ease the upload process by use of templates. It's verfified and I've requested additional quota from time to time. And now my app has attracted the interest of spammers. In the Google Cloud platform console I can see that my credentials uses API requests I don't do with my app, like rating videos, adding subscriptions and updating channels and not a low amount of these kind of requests.

I tried already changing the password regularly (which also means deployment of a new app version), obfuscating the binary and modifiy the credential strings in the binary so that they cannot be found directly. But to be honest, it's not worth it, with the usage of fiddler e.g. you can see the password in the authentication requests within no time (I used this code as basis: https://github.com/googlesamples/oauth-apps-for-windows/blob/master/OAuthDesktopApp/OAuthDesktopApp/MainWindow.xaml.cs). And on the next day the spammers are back again.

I wonder why this double authentication is needed at all for a desktop app, it is even stated here, that on desktop apps it cannot be kept secret: https://developers.google.com/youtube/v3/guides/auth/installed-apps and all requests are OAuth authenticated (a mechanism for granting access without disclosure and transmitting of passwords, but you need to do this with the API credentials ). The YouTube accounts should be limited in quota and banned on abuse and not the app, but that is another story...

I also looked for a possibility to restrict the requests, so that no subscription requests are possible e.g. or restrict the amount of uploads per day, but the only possibility I found was limit the quota per user per minute, which I need to set to 1600 so that uploading works at all, which is not helpfull, because it is still enought the to spam over the day.

So what can I do? Request more quota every week?

Thank you in advance for your help!

youtube-data-api google-oauth
2 Answers

This is a known issue with desktop applications. You need to ensure first of all that your client id and client secrete are built into your application, That being compiled into it. Yes your application could be decompiled to get the client id and client secrete but that would require a bit more work on the half of the hacker. You could also hash it or encrypt it some how even when it is compiled into the app.

Basically you should never include it as clear text in your app when its installed.

You could alternately store this client id and client secrete on your server. And then have some method in your app that would request the client id and client secrete from the server. Then you could lock it down by the applications license key. You could also limit the number of requests for the client id per license key to ensure that one user isn't taking all your quota.

I have done both of those for clients in the past. Your going to have to be creative really.

user_18418390

Handling OAuth2/OIDC in a native app is indeed a difficult issue.

The relevant specifications are:

Notably, the spec requires the provider (i.e., Google) to not treat client secret as confidential when working with a native app. There also other vectors of attack, such as intercepting OAuth2 responses in the OS.

Last time I checked, support was pretty thin among providers, but Google was in fact the one I could find that claimed to offer a native app OAuth2 implementation that follows the RFCs. I recommend double-checking to what degree that is true and which libraries and code samples actually use this flow.

  • Generally, for an open-source hobby project, I would strongly investigate just asking every user to request an appropriately-scoped developer API key with the provider and supply that key in your app, meaning there would be no shared secret to be stolen. (Not sure how easy it is for a user to obtain a developer key with Google, it’s easy with GitHub though.)
  • Other things you could try (rotating credentials frequently, varying credentials across distributions, etc.) would probably not be something you could see yourself bothering with.
  • I hope you’ll contribute to reducing YouTube spam and revoke any credentials that you suspect as being leaked ASAP! :)
user_2474410
Related