In this post, I will explain how to set up secure communication between your client (this can be an app or web application) and backend for earning Kin. The keyword secure is key here, it is very simple to create earn requests, but it would be horrible to find out a day later your wallet has been emptied. If you expose your earns insecurely it’s not even a “hack”, it’s like leaving the house with your front door open. That someone walks in and takes your stuff is just bound to happen.

This post is about how you app interacts with other components like your backend and the Kin blockchain. This is a very important part of app development, and requires a bit of logical thinking instead of coding. The annoying thing is that creating a secure system takes more time to build, however it cannot be neglected. In this post, I will highlight the most important ones.

Cold and hot wallet

There’s always a risk that something, somewhere in your application is not secure. To assume the communication with the backend is 100% safe is probably wrong. To minimise the risk of losing all your Kin, it is wise to work with two wallets: a so-called cold and hot wallet.

Say you have 100 million Kin in your wallet available for giving out earns. Then don’t use that wallet to give out earns, but create another wallet and send 1 million Kin to that wallet. The wallet with 99 million Kin is now your cold wallet and the one with 1 million Kin is your hot wallet. The backend will give out earns from your hot wallet.

This way, the maximum amount of Kin you can lose in the absolute worst case scenario is only 1 million Kin. When that happens, identify the problem, fix the security bug and create a new hot wallet (assume that the old hot wallet is compromised forever). Send 1 million Kin from your cold to your hot wallet and everything is good again. Simple! Just keep a check on the amount of Kin in your hot wallet and top it up once the balance is becoming a bit low.

This is the easiest thing you can do and will greatly reduce the amount of Kin you can lose in the event of hack. Even if you do nothing to secure your application, at least have a cold and hot wallet.

Secure earns

The absolute worst way to handle earns is the following. It is also the quickest way, but analogous to not wanting to close the door of your house when you leave because that is too much of a hassle. No one would and should do it.

Don’t set up your earns like this!

In this example, your app communicates directly with the Kin blockchain, without any backend logic of your own. It is also the easiest, because you don’t have to build any backend logic. Even if you just want to build a minimum viable product (MVP) and want something shipped as soon as possible, don’t cut corners on secure communication. The flaw in this architecture is as follows:

The app does a request to send 100 Kin to address X to the Kin blockchain (where X is the user’s address). Of course you cannot directly issue a request to a blockchain. You do a request to a service that accepts payment requests, which could be the Kin Python bootstrap server. The request will look something like this:

This means that you will be doing a POST request with the above body. The request will be fulfilled, 100 Kin will be sent to X and the earn is complete. You now have a working earn in your app! However, it is super easy to sniff out network requests. Just follow these instructions. When you do an earn while watching the request, copy the request and do the above request again and again, until your wallet is empty. You can even increase the amount to do an earn request of 1 million Kin, or more.

Suddenly you get errors that the earn requests fail because there is not enough balance on the wallet where the earns come from! Not good. There needs to be a way to check that your earn is valid. However, this logic cannot be on the app itself, because you can still read the earn request when it leaves the app.

The earn verification logic needs to take place between the request to earn and the actual earn. In a place where the user cannot read out requests or control the behaviour.

That place is the backend. It’s the only place where you have control over everything and can make sure that earns are valid before doing the actual earn request. Always assume that everything coming from a user’s device is 100% insecure, no matter what you are building.

Better way to set up earns

As an example, let’s assume you can only make one earn per day. The following diagram could be a way to set this up:

Better way to handle earns in your app

This is what happens:

The app sends a request to send 100 Kin to address X to your backend

The backend checks (in a database) if that address already has earned something today. If yes: send a failed response, because the user already has earned Kin today

If not: the backend sends a request to the Kin blockchain to send 100 Kin to address X. Then updates the database that this address has earned Kin today. The response is successful and the app is notified

If you now try to sniff out the request and play it out again and again, you will only be able to earn it once a day.

However, it is still possible to circumvent this check quite easily. Just create a new wallet every time before you do the request to your backend. It is very cheap to create a new Kin wallet, so it’s totally possible to send an earn request with address X1, X2, X3, etc, or just create one new wallet Y and as an amount put the amount of Kin you have in your wallet for earns. In one transaction you would lose all Kin that you have.

A good way to prevent all your Kin being stolen in one transaction is to hardcode a limit of the maximum amount of Kin you can earn. If the maximum earn is 100 Kin in your app, every request to earn over 100 Kin is actually invalid. You can add this check to your backend as well, giving you the following diagram:

Earn flow with maximum amount of Kin check

This is already a lot better than the first try, but we still have the issue of multiple addresses. It is possible to create thousands of Kin addresses and call your backend for 100 Kin for each of those addresses.

Good way to set up earns

To solve the issue of multiple addresses, we can attach an address to a specific device ID. Every phone has a unique ID that does not change. When you first open the app and create the wallet, we can save the combination of device ID and wallet in a database. When you do an earn request, don’t send the address to the backend, but that unique ID. The backend looks up the address belonging to that device ID and does the other checks already in place. The diagram looks like this:

Earn flow where you send device ID instead of Kin address

Now you can still create many Kin addresses, but it’s not possible to send those Kin addresses to the backend for earns. In addition, every device ID can only have one address. If you uninstall and reinstall the app, you don’t get a new device ID. The earn flow is now safe.

However, there is another point that makes the whole flow insecure: the device ID and address are stored together in a database when you first visit the app. So one can try to sniff out that request and register many Kin addresses with bogus device IDs, then use the flow above to send out many earns to those bogus device IDs.

While it becomes more and more difficult to circumvent your security, we can also close this security flaw by implementing SMS verification. This way you can mark device IDs as “verified” once SMS verification is complete. The backend then checks if the device ID in the request is “verified” and will fail if it is not. Both Android and iOS have excellent documentation for SMS verification. For web, you could also implement email verification.

Note that it now still is possible to generate make fake emails or phone numbers and try to automate the verification process. But if you do that on the same computer, you can implement a limit not only per device but also per IP address. However, then the attacker can make the verification on different IP addresses.

This is a bit of a cat and mouse game. It is nearly impossible to create a 100% secure system, but every step you implement extra makes it that much more difficult to steal your Kin. You only have to build it secure enough that the attacker just moves on and tries to attack someone else (“lock your door better than your neighbours”), and as Kin becomes more valuable or you get more users, you should adopt more secure systems. If it takes the attacker 100 hours to steal 1000 Kin, the hourly “wage” for the attacker is only 10 Kin, which currently is way too small. But if 1 Kin would be worth $10, it would be a whole different story.

I hope you get the point of the last paragraph. In this section, I outlined why you need to build a secure system, how you can create simple security and what you can do to secure it even further. Let’s move on to spends.

Secure spends

Like earning Kin, it takes a bit of effort to create secure spending. It’s simple to make the transaction and give the reward, but like with earning Kin, everything can be faked and you need to make sure you’re not giving away stuff to people who are smart enough to fake the API calls. The way to handle spends securely is to treat spends the same way you would treat fiat money and a traditional payment gateway like Stripe or Adyen. The nice though about secure spends is that they can be made 100% secure, unlike earns. So why not do that?

Unsafe spending

Suppose the user wants to buy a mug for 1000 Kin. You create a button that sends 1000 Kin from the user’s wallet to yours. When complete, you make a backend request to send the mug to the user’s address.

While this works fine, it is very easy to get free mugs. Someone can just read off the API call to the backend and start sending requests to the backend to get mugs. Without verifying that the payment actually happened, you for sure will be paying for a lot of free mugs! That’s why you need to build a secure way to handle spends. Unfortunately, this means the setup is also a bit more complex, just like with the earns. However, if you want to build an app, you don’t really have a choice, someone will eventually find the loophole and exploit it.

These kind of design flaws are actually way more common than you might think. Here’s an example of Domino’s pizza that had exactly this unsafe handling of payments, leading to anyone being able to order pizza for free.

Safe spending

Just as with earns, the only place where you have full control and can trust what goes on is your backend. So while the spend transaction happens on the device, verification that the spend is valid should be done on the backend. Here is the flow of a secure spend:

Step 1: Request a spend

If the user wants to buy something, an API call should be done to the app backend with a request to buy something. The app backend accepts this request and sends back a random token that is also saved in the backend for later.

Step 2: User spends Kin

The app follows by spending the Kin. The user will send the an amount of Kin to the app’s address with the token in the memo field (the token will be stored in the blockchain transaction). The transaction ID of the spend is saved. The amount of Kin to be sent is the price of the thing the user wants to buy, which should be saved in the backend along with the token.

Step 3: Request the thing you bought

Next, the app will make an API call to the backend again with the transaction ID of the spend. The backend will confirm that that transaction ID is a spend to the app’s wallet with the correct amount of Kin and the correct token. If something is wrong, deny the spend. If it was correct, proceed with giving the user what he bought and mark the token as paid so that the token cannot be reused to prevent double spending.

All these steps are necessary. If you don’t check for the correct amount of Kin, one can simply just send a very small amount of Kin and still get the spend. If you don’t check the receiving address, one can just send Kin to himself and supply that transaction ID as a spend. If you don’t check on the token, one can make one real spend and then re-use that transaction ID multiple times to get multiple spends for the price of one.

Conclusion

This concludes the article on how to create secure earns and spends. This is a general guide that is valid for any kind of app or web app that you are building and any kind of currency your app deals with (Kin, Bitcoin, $, €, etc). I hope you learned something about building secure infrastructures! If you have any questions, let me know in the comments.