How to prevent leakage of consumerKey, consumerSecret of Evernote API

Asked 2 years ago, Updated 2 years ago, 131 views

Using monaca, we are developing Evernote apps for smartphones based on HTML5+Javascript.

In order to communicate with Evernote's server, OAuth authentication is required using the key (consumerKey, consumerSecret).

We are developing based on Evernote's web page, but the sample code on this page lists consumerKey, consumerSecret as a "direct" source.

Getting Started with the Evernote API-Evernote Developers

In principle, you have to write consumerKey,consumerSecret directly on the source,especially JavaScript does not encrypt the source (although there may be some obfuscation), so if you publish the app, for example, you can easily get consumerKey,consumerSecret just by looking at the apk file.

Is there a way to write the source so that it doesn't leak easily?

Intuitively, I wish I could generate and interact with them, but Evernote's oauth authentication part is obfuscated and black boxed (for me) can't be helped.

In the first place, can these keys (consumerKey, consumerSecret) be leaked?

I think it would be good if Evernote managed the risk on the premise of leakage, but I think it would be good if I could impersonate the app.

If possible, could you lend me some advice?

Thank you for your cooperation.

javascript monaca html5 oauth evernote

2022-09-30 19:40

1 Answers

If you want to use the JavaScript SDK to hit the API directly from a web browser without relying on any server, I think the point of view is how likely the API's client application is to see the code.It is correct to point out that if the Client ID and Client Secret are found out, they can pretend to be clients.If you look at Evernote's Quick Start, it was an example of using Cordova, so you use Evernote API directly from the Android/iOS app without the presence of a server."In that case, as you said, ""the problem of how much code the app can see"" will arise."Also, it is impossible to hide it completely, so I think the common solution is to try not to read it as much as possible.

What I can do right now is...

  • Objective C, I will do my best to obfuscate Java code.I wrote Client ID, Secret there, but not JavaScript.
  • Write on the C, C++ side and make it more obfuscating.
  • It's highly likely that it's just a string literal, so it's well hidden as a code logic.

It comes to my mind thatHowever, it is important that these are not fundamental solutions.

In the OAuth2 world, Implicit Grant Flow is used for clients who can't hide secrets, but I personally think that Evernote is not very aware of security when using APIs in smartphone apps because it assumes that Client Secret is applied.

This story says, "You're going to pretend to be a client!It's dangerous!" Instead of thinking right away, you need to imagine what bad things will happen if Client ID, Client Secret is leaked.For example,

  • You can use the API for free.
  • You cannot use the API without user authorization.
  • Anyone is free to obtain Client ID, Client Secret.

In that case, I personally don't think I need to worry too much.Of course, if there is an API that can only be used for client authentication, that's a different story."Also, impersonating a client means ""the appearance of an app that tells your personal name and company name,"" but for example, it may be possible to warn users by providing another mechanism to determine if it is a fake app, saying ""this is the right app."""

Of course, it is necessary to try as hard as possible to keep the app from leaking, but if you don't hide it completely, please consider what the damage will be when the app is leaked.


2022-09-30 19:40

If you have any answers or tips


© 2024 OneMinuteCode. All rights reserved.