API Security Issues and Decentralized Trading Permissions
Overview
While centralized exchange hacks are now commonplace in the cryptocurrency ecosystem, the recent Binance API hack highlights a more subtle security issue that centralized exchange API users face: custodianship of trading permissions.
Background — Custodianship of assets
Typically, centralized exchange hacks expose the risks associated with the required custodianship of user assets on centralized exchanges (despite these recurring exchange hacks and subsequent losses of hundreds of millions of dollars worth of cryptocurrency assets, traders continue to trust centralized entities to be perfect custodians of their assets. Liquidity comes with a risk!).
Traders are now realizing that decentralized exchanges eliminate the need for a centralized custodian of their assets: traders no longer need to deposit currency into one place that can be hacked or compromised.
This is all pretty familiar news at this point. But there is more depth to the security issues on centralized exchanges than is typically discussed. API is used by traders to perform automated trades on exchanges and requires more than simply allowing a centralized entity to be a custodian of users’ assets.
Custodianship of trading permissions
In addition to retaining custodianship of users’ assets, centralized exchanges also hold full custodianship of permissions on their exchanges. API users trust exchanges not only to securely hold their assets, but with their permissions to execute trades on the exchange! The recent API hack on Binance is an outstanding example of this needless custodianship of permissions and the potential security compromises it can yield.
What happened exactly with Binance’s API Hack?
On March 7, 2018 Binance users began to flood reddit with complaints about unauthorized sell orders.
While the specific details of the hack are a somewhat vague, Binance posted a support article summarizing the incident from their perspective. According to the Binance summary, hackers allegedly gained access to API keys (used for trading bots) for some users through phishing attempts. Traders with compromised accounts witnessed their funds drain quickly into large purchases of a coin called “Viacoin”. The hackers reportedly used these compromised accounts to place massive buy orders on the VIA-BTC trading pair, driving the price drastically up, while they had personal accounts place sell orders with extremely high VIA prices.
Withdraw capability from Binance was completely suspended for all users while Binance investigated the issue. From their summary article:
The issue was eventually resolved when Binance artificially reversed all trades made against the hacker(s) accounts, simultaneously demonstrating both the power and fragility of centralized exchanges. However, this only reversed some of the trades that occurred: all of the trades executed directly against the hacker(s) accounts were reversed, but other trades from the phished accounts were unable to be reversed. Binance stated:
All other high-priced sell orders of Viacoin on Binance that were not directly linked to the attackers accounts were still processed, and the victims of the API hack paid these prices. Not to mention the secondary effect this may have had on other exchanges through seeing a rapid increase in the price of Viacoin.
What can we learn from Binance’s API Hack?
This is different than a typical centralized exchange hack. No assets were lost by the exchange, yet damage was incurred by the victims of the API hack (not all trades were reversed, so the victims still incurred significant losses from buying Viacoin at extremely high prices). The root cause of this hack lies in the “API Keys” that are required for performing automated trades on centralized exchanges. API users on Binance must trust the exchange to hold and validate API keys, which represent the users’ permission to execute trades. In hindsight, hacks like these are almost an inevitable result of storing these all important API keys in a centralized SQL database.
Fortunately, as decentralized exchanges continue to accrue liquidity, this additional layer of risk for automated trading could become a forgotten problem. Decentralized exchanges can offer both non-custodial trading of users’ assets and non-custodial trade permissions for API.
DDEX just launched our beta API — with non-custodial trade permissions
DDEX just released our closed beta API to allow for automated trades on the exchange. The API setup should be similar to what is seen in typical exchanges, but with one key exception: there is no API key. Each order is authenticated by the same cryptographic signature scheme used to authenticate any other Ethereum transaction. The trading permissions for DDEX’s API are entirely contained within the private key of the user.
If you’re interested in checking out DDEX’s Closed Beta API, please send us an email at bowen@ddex.io. If you have any questions or feedback on the API, we offer 24-hour a day support on ddex.io.
Summary
The recent Binance API hack demonstrates the security liability associated with 3rd party custodianship of trading permissions. In the wake of these recurring centralized exchange hacks, the added security and convenience benefits that decentralized exchanges provide are becoming increasingly hard to ignore. While most discuss the non-custodial trading benefit (not requiring users to deposit their assets into DEX’s to trade is great), perhaps equally noteworthy for API users is the fact that DEX’s hold no custody over users’ trading permissions.
Happy Trading,
-DDEX
