CODEWITHSUNDEEP
iosdropbox
Colen
Colen

Reputation: 13918

Should I encrypt my dropbox app key/secret?

We're adding Dropbox support to our app, and we now have an "app key" and "app secret" for it. I could just keep those as plain text in the code, as listed in the sync API tutorial:

   DBAccountManager* accountMgr =
    [[DBAccountManager alloc] initWithAppKey:@"hf2hf892hf9y29h" secret:@"n29fh82h4f"];

(Note: that is a made up key and secret, not our real one.)

But then it'd be super easy for someone to extract them from the app if they wanted to. To prevent that, we could add some sort of basic encryption to make the keys harder to find, but obviously the keys are still going to be used in a call to the DropBox account manager at some point, so there's no way to keep them perfectly secure.

Is this something anybody worries about, or is it just a fact of life that someone who really wants to can go in and find out the keys?

Upvotes: 2

Views: 883

Answers (3)

Alex
Alex

Reputation: 664

A more up-to-date answer in case someone else stumbles upon this question.

Dropbox API OAuth 2.0 now features PKCE which does not require client secret to generate access token. They have even specifically outlined this use case in their oauth guide:

if your app is it should
A client-side Desktop app or mobile app that requires background access Use the OAuth code flow with PKCE, with refresh tokens.

If you will look at the /oauth2/token API doc example, you will see that PKCE method does not use client secret.

This additional guide - PKCE: What and Why? - provides some basic info for implementing it.

Edit:

When PKCE is not appropriate?

In case of Dropbox implementation, PKCE is not appropriate when you need to access Dropbox API in the background i.e. without user's interaction. This is due to the fact that, oauth/token does not grant you a refresh token. (Refresh token is used to generate a new access token without user interaction)

To get a refresh token while using PKCE, you need to supply token_access_type=offline to oauth2/authorize (similar to their code flow). At this point, I don't know why their guide recommends code flow with refresh tokens if PKCE can achieve the same without storing or using client secret.

Upvotes: 0

Yusuf X
Yusuf X

Reputation: 14633

First of all, your concern is valid. You should put it in the keychain.

However, nothing is perfectly secure, not even the keychain, as Carbonic Acid said already. Sometimes one makes the mistake of focusing on one security threat and disregarding another, larger problem. It's a lot like optimization, (except it's harder to profile security than performance).

You don't need to make your secrets impossible to steal, just more expensive to steal than to acquire elsewhere. And Dropbox API keys aren't exactly hens' teeth.

Upvotes: 0

user529758
user529758

Reputation:

Is this something anybody worries about

Any sane developer worries about it. Do use some form of encryption.

Hint: my attitude - when I download an app from the AppStore which requires some form of login to [insert arbitrary webservice here], I usually decrypt the binary and run otool or at least strings on it. If it has plaintext passwords/OAuth keys/SSL keypairs etc. in it, I usually trash it immediately.

is it just a fact of life that someone who really wants to can go in and find out the keys?

Practically, yes, even the keychain isn't secure ;-). This is, however, not an excuse for not trying to do your best if the subject is the security of your data and/or that of your users.

Upvotes: 2

Related Questions