Share article:
Introducing MessageMedia Enterprise Webhooks
“My application is immune to security risks.” said no one ever.
In an ever-growing world of web applications, security is an absolute necessity. As I’ve discussed in a previous article, Webhooks albeit being incredibly useful can create some dangerous security vulnerabilities in your application if not taken care of properly.
Webhook security tactics
The first step to securing communications is to force TLS connections or in other words, only accept SSL compliant (https) websites. Now, you can apply a number of different solutions to secure your connection. Let’s talk about what these methods are.
- Token-based authentication – Tokens can be added to the callback URL while configuring your webhook. The URL might look like https://www.myapplication?auth=TOKEN
- Basic authentication – Basic authentication is a simple authentication scheme where the client sends requests with the Authorisation header that contains the word Basic word followed by a space and a base64-encoded string containing your username and password.
These methods work great to prevent most attacks; however, they have some obvious drawbacks. Both methods send their auth tokens along with the request and the biggest flaw of the latter method is that the string is encoded NOT encrypted which means the Base64 string can easily be reversed. There is a third method which is not as widely used as it should be. This method relies on either symmetric (eg: HMAC) or asymmetric encryption (eg: RSA) to encrypt the data being sent between two parties.
Enterprise Webhooks
Github uses token-based authentication, Anymail uses Basic authentication, Elastic.io uses HMAC but here at MessageMedia we do things differently. Our Enterprise Webhooks system uses RSA to securely encrypt your data before transmission. But why RSA? Why not HMAC or any other cryptosystem?
The decision to use RSA was made with you in mind. Unlike other APIs, we support your needs for key rotation policies. This means you will have the power to create, delete or even replace their previous private key with a new one. Furthermore, we provide more flexibility as you can specify the digest type (SHA-224, SHA-256 or SHA-512 all of which are unbroken digest algorithms) and effectively use an RSA encryption on the digest.
A drawback of using RSA is that it is computationally slower than HMAC but this can be seen as a minor compromise for a major gain. What this means is that since we’re not holding onto your half of the key, even if MessageMedia’s Key Management datastore is compromised, you will not be affected.
