Dragonchain Releases a Decentralized Authentication System with More Speed, Security, and Scalability

In the past, communicating with a Dragonchain required hitting RESTful endpoints with a static API key in the authentication header to a centralized API gateway. This, in turn, would authenticate and route requests accordingly.

There are many reasons why we decided to move away from this model

1. We wanted to improve scalability. Because we were using a centralized gateway to route/authenticate requests, there was both a central point of failure and a load for everyone using our hosted/managed Dragonchains.
2. We wanted to separate authentication from any centralized management. Our past model made it necessary for our centralized system to take responsibility for tracking authentication and proxying actions to the chain. Our new system eliminates this need.
3. We wanted to speed up requests to Dragonchain. The model we moved away from was slow because it involved an extra step to route requests. After authorization, the centralized system would have to translate and relay a request accordingly, adding an extra hop.

The new system that we’ve developed to communicate with a Dragonchain allows for more direct access to the node running the chain itself, and also allows for the Dragonchain to handle its own authentication system completely independently of any centralized service which is much better for permissioning. This will allow us to more easily manage API keys, and in the future, add fine-grain permissioning on an API key basis.

Because this move required us to reimplement parts of our authentication system, we took the opportunity to completely re-haul the way our authentication system works in order to make the system much more robust and secure. All requests to a Dragonchain must be authenticated with signed HMAC requests in the authentication header, rather than providing a static API key. Previously, with a static API key, if anyone was ever able to see/man-in-the-middle any of your HTTP requests, they could easily get your API key, which would give an attacker full access to your Dragonchain. While this model makes it easy for developers to make authenticated API calls, it is not very secure. This is why we’ve decided to switch over to signing all HTTP requests with a shared key via an HMAC, rather than providing the key directly itself.

This means that upon the creation of a Dragonchain, a shared (secret) API key is provided to both the user and the Dragonchain itself. Then, when a user wants to make any requests to the Dragonchain, they simply have to generate the HTTP request that they wish to send, then ‘sign’ that request with the the shared key via a cryptographic HMAC algorithm, and include this special signature in the authentication header.

This has a couple of important security implications which are worth noting:

1. The secret API key itself is NEVER sent over the wire except when it is initially created. This means that even if a malicious attacker were able to man-in-the-middle or have control over your connection to a Dragonchain, they still can’t gain access, modify, or spoof any requests
2. We don’t have to rely on SSL/TLS (HTTPS) itself for protection of authentication data. Although we do rely on HTTPS for general encryption, so that no one can spy on the communications between an end user and their Dragonchain, the authentication system is completely independent. This means that even if TLS were to be broken tomorrow, the authentication for requests to a Dragonchain would remain completely unaffected. This also means that even if you were theoretically able to broadcast requests to a Dragonchain over a completely insecure/unencrypted HTTP connection (which is worth noting that you can’t do anyways), no one would be able to modify or replay any requests you send.
3. API keys can now be both revoked and created on-demand, which will be able to be used to differentiate various users accessing a single Dragonchain in the future with a permissioning system.

With this new authentication system, we have also implemented a replay protection system. As a quick summary: a theoretical replay attack is where an attacker is able to somehow man-in-the-middle or sniff a connection between two targets (in this case a user and a Dragonchain). If they could break HTTPS and your requests that you send to a Dragonchain, they could theoretically ‘replay’ them by sending the same request to the Dragonchain. For example, imagine you created an HTTP request which transfers 100 tokens from a source to a destination address of a currency contract on a Dragonchain. You then sign this request and send it to your Dragonchain. If a hostile adversary were somehow able to intercept this request, they might be able to simply keep sending this HTTP request to the chain, causing an additional 100 tokens to be sent out of the source address every time an attacker ‘replays’ the valid signed request.

Other blockchains such as Ethereum or Bitcoin implement replay protection by requiring the user to keep track of a ‘nonce’ for each address, simply incrementing the nonce for every transaction. The problem with this is that the end user either needs to keep track of the nonce, or make a network call to receive it every time they generate a transaction. Our implementation of replay protection simply requires that the user is able to generate an ISO 8601 UTC timestamp and include it with their request, so they don’t have to keep track any extra data other than the current time. If the timestamp in the request is too far off, or the request signature has been seen recently, the Dragonchain will reject the authentication even if it was signed correctly which mitigates any sort of replay attack.

With all of these changes, we recognize that the heightened security requirements make it a bit more difficult to interact with a Dragonchain, which is why we have created and are releasing a couple open source SDKs to interact with the new Dragonchain system. Initially, we have SDKs for both Python3 and Javascript (available on npm and pypi as complete packages respectively). You can also view the source for these here:

https://github.com/dragonchain-inc/dragonchain-sdk-python

https://github.com/dragonchain-inc/dragonchain-sdk-node

We have always wanted to release SDKs to make it easier for developers to interact with a Dragonchain, and this new authentication system gave us a perfect excuse to create and release some. These SDKs will handle all of the RESTful endpoints with the new authentication system in place, integrating easily with the language they are written in. Because we only currently have SDKs for these 2 languages, we will be releasing documentation on the technical implementation details for how the HMAC authentication system works. This will allow other developers to implement this authentication system in other languages if they need to programmatically interact with a Dragonchain before we can release an SDK for other desired languages.

Overall, this new Dragonchain release signifies a huge step towards greater performance, reliability, security, and scalability of the Dragonchain eco-system. We will be maintaining support for our legacy authentication system with the old static API keys for a while in order to allow transition time for anyone that needs to adopt the new authentication system.

It’s worth noting that anyone using the new authentication system should also see a significant increase in responsiveness as well. There should be a significantly reduced ‘warm-up’ time on all requests, as well as a faster round-trip-time in general for all requests using the new system.

If you’re interested in learning more about Dragonchain and our blockchain-based solutions, try it out for free of visit our contact page.

If you have any questions about our new authentication system, or experience any issues while generating new API keys for your existing Dragonchain, please email support(@)dragonchain(DOT)com.