SyncBackPro contains the OAuth client secrets it uses to connect to some cloud storage services. Scanners and CVE entries usually list this as CWE-798, "use of hard-coded credentials". This article explains what these secrets are, why they don't put your files or accounts at risk, and what we have changed.
Who is affected
Only SyncBackPro, because only SyncBackPro connects to cloud storage. SyncBackSE and SyncBackFree are not affected. You don't need to do anything, and your existing profiles keep working.
What a client secret is
When SyncBackPro connects to a service such as Dropbox, you sign in on that service's own web page and agree to let SyncBackPro use your account. The service then gives SyncBackPro a token for your account only.
The client ID and client secret identify the application, SyncBackPro, to the service. They are not a password and they don't open any account.
Why it is not serious
- It gives no access to your files. To get a token for an account, someone must sign in to that account with its own password (and any two-step verification) and approve the access. The secret cannot get round that.
- The sign-in code only goes to the address registered with the service. For Dropbox and Google, SyncBackPro now also uses PKCE. This ties each sign-in to the copy of SyncBackPro that started it, so an intercepted code is useless.
- Every desktop application is in the same position. A program installed on people's computers cannot keep a secret, because anything inside it can be read. The OAuth standard for desktop and mobile applications (RFC 8252, section 8.5) says secrets built into a distributed application should not be treated as confidential, and Google's guidance for installed applications says the same. Cloud services design their security on that basis.
- What someone could do with it is limited. They could identify themselves to a service as "SyncBackPro", or use up our application's request allowance. Neither gives access to anyone's data. The worst case is that a service restricts our application, which would interrupt cloud profiles until we fixed it, but would not expose your files.
What we have changed
Dropbox: From V12.1.38.0, new sign-ins use PKCE and do not send the secret. We will remove the secret in a later version, once older sign-ins have been renewed.
Google Drive and Gmail: Google requires you to create your own client ID and secret in your own Google Cloud account, and SyncBackPro signs in with those. From V12.1.38.0, SyncBackPro no longer contains a built-in Google client. PKCE added from V12.1.38.0.
OneDrive (personal accounts): Moving to PKCE in a later update.
OneDrive for Business and SharePoint: Do not use a secret.
hubiC: The service has closed. The unused secret was removed in V12.1.38.0.
Some cloud services require a client secret and don't support PKCE, so no desktop application can avoid sending one. For these we rely on the protections described above, and we will switch to PKCE when the service adds it.
Why not just change the secrets?
A new secret would be in the next version and could be read in exactly the same way. Changing it would also stop every installed copy of SyncBackPro from connecting until it was updated. Removing the need for a secret, with PKCE, is the real fix.
Why not keep the secrets on a 2BrightSparks server?
Anyone could send requests to that server in the same way SyncBackPro does, so it would protect nothing. It would also put our server between you and your cloud storage every time a profile runs.