I recently released my open source library CryptoCurrency.Net. It has several clients for communicating with Cryptocurrency Exchanges. Nearly all Cryptocurrency exchanges use an API Key/Secret pair pattern for authentication. While this pattern has some security advantages, I will talk here about why this is inadequate for the future of Cryptocurrency integration, and why the industry needs to move toward a permissions based Auth Token approach (like OAuth) to security instead of API Key/Secrets.

Take a look at a typical call to an exchange API (GetBalances):

API Key

This pattern uses the API Secret to sign a message to the server. This pattern guarantees that only a person who has access to the secret can sign a message to the server. This makes sense. However, in reality, the API Key and Secret are both extremely long, auto generated strings like crypto addresses that the user cannot remember without copying and pasting somewhere. Because of this, users are more or less forced to put the values in places that makes it vulnerable to theft. As Coinbase notes:

You should take great care to store your credentials securely. If someone obtains your api_secret with the wallet:transactions:send permission, they will be able to send all the digital currency out of your account.

Which brings us to another issue. In order for a user to get an API Key / Secret pair, they must log in to their account and create one or more. This is Bittrex’s interface. You will notice that Bittrex allows the user to create multiple keys with different permissions. This is a good thing, but many exchanges don’t have this functionality and only allow for one API Key/Secret.

API Keys

In cases where there are multiple Key/Secrete pairs, the user is forced to manage this. How would one even begin to manage these values? How would one remember which has which permission?

It’s important to take a step back here and think about the bigger picture. Imagine you hit a website that wanted to use one of your Facebook permissions. Lets say it wanted access your email address. Now, imagine that it asked you to create an API Key/Secret in Facebook, and then copy and paste that in to the web page. Firstly, this is dangerous because and copying and pasting, or saving creates vulnerabilities where malware could pick those values up. Secondly, as a non-technical person, you’d have no idea what the website is talking about. Users don’t know anything about API Key/ Secrets. What they expect to see is something like this:

16327993_368994666813684_5547592923035467776_n

From here.

The above kind of dialog has become common with social media integration. It clearly shows the user what permissions the app is asking for. Users who may want to use things like automatic trading bots, or portfolio aggregators will expect to be seeing the same kind of thing. This can be achieved with technologies like oAuth. However, for some unknown reason, most exchanges have opted for the API Key/Secret approach. My reading tends to make me think that the developers of the exchanges believe this to be more secure. But, as I’ve mentioned, expecting users to securely store an API Key/Secret is definitely not secure!

Coinbase is the outlier here. Coinbase implements both authentication patterns, but more importantly, they clearly explain when to use either. As they say:

API Key authentication should only be used to access your own account. If your application requires access to other Coinbase users’ accounts, do not use API Key. To securely access other Coinbase users’ accounts, use Coinbase Connect (OAuth2)

Coinbase has an oAuth2 based authentication option called Coinbase Connect that would allow users to confirm/deny permissions via a dialog like this:oauth-pongbot

To sum up, exchanges need to start implementing a similar kind of authentication pattern so that users are able to safely pass permissions over to a given app, and clearly manage those permissions without copying API Key/Secrets all over the place. API Key/Secret simply do not provide an adequate UX experience ,and are inherently unsafe because of the hoops the user needs to jump through to keep them on hand.

Please contact me through this website if you require assistance in this area.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s