How to make secure dApps…(Psssst! Don’t share private keys)
Working with private keys and mnemonics might seem confusing. Let’s clear things up.
After helping tens of thousands of developers build blockchain apps on our platform, we at Tatum have noticed quite a bit of confusion around blockchain security and working with sensitive blockchain data.
We’d like to make it clear, that when building production dApps with Tatum or any other platform, your private keys and mnemonic phrases should NEVER be sent over the Internet to our API, or anyone else’s for that matter. NOT EVEN ONCE. Any time your sensitive data leaves your security perimeter, it is completely vulnerable to being stolen. NO ONE should hold your private keys and mnemonics except you, and they should ONLY be stored securely and on-premise.
So let’s dive into exactly what this all means and explain how to use Tatum to make sure that your most sensitive data never falls into the wrong hands.
What are private keys and mnemonics?
When you create a wallet on most blockchains, a mnemonic phrase is generated. This phrase is essentially a password to your wallet that can be used to generate both wallet addresses and private keys. Anyone who gets their hands on your wallet’s mnemonic can easily take everything it holds.
When you generate an address using a mnemonic phrase, you also need to generate a private key specific to the address in order to send funds from the address. As with mnemonics, if anyone gets hold of your private keys, they can easily steal everything held at the associated addresses.
NEVER send or share your mnemonics or private keys with ANYONE.
As we’ve mentioned, you should never send mnemonics or private keys to anyone. Tatum will NEVER ask you for these pieces of data, and if anyone else does, they’re probably either trying to scam you or are completely unaware of proper blockchain security practices.
What is confusing to some people, however, is that they MUST use mnemonics to generate private keys and addresses, and they NEED to use private keys to sign blockchain transactions.
And yes, in Tatum, many of our API endpoints have “fromPrivateKey” and “mnemonic” fields in them.
So why are there private key and mnemonic fields in Tatum’s API endpoints?
Good question. The answer is, for testing and demo purposes, using private keys and mnemonics can be fast and convenient. Once you’ve tested or demoed what you need to (preferably on a blockchain testnet), you should never use the blockchain wallets, addresses, or private keys you’ve exposed again. You can simply consider them compromised, and throw them away.
It’s also important to note, that any sensitive data we receive to our API is thrown away. WE DO NOT STORE ANY OF YOUR PRIVATE KEYS OR MNEMONICS… EVER. This would be a huge security risk for every developer using Tatum, and simply horrible security practice.
However, even so, we do not recommend you reuse the private keys or mnemonics that you have sent to us. Why? Because as they make their way across the Internet to our API, there are countless points at which they can be intercepted and stolen. Simply put, if your sensitive data ever leaves your security perimeter, it is highly vulnerable.
How to securely work with mnemonics and private keys.
So let’s get into how to do this the right way. In Tatum, you can easily work with private keys and mnemonics without ever sending them over the Internet.
Tatum Key Management System (KMS)
KMS is run locally on your server and provides unbreakable security for generating wallets, addresses, private keys, and signing transactions securely. When you generate a wallet with KMS, it creates something called a signature ID to be used in place of the wallet’s mnemonic. When you generate a private key to an address, it creates a signature ID to be used in place of the private key. Then, when you send API requests to Tatum you only have to remember to replace two fields:
mnemonic -> signatureId (of the wallet’s mnemonic phrase)
fromPrivateKey -> signatureId (of the private key)
For example, in this “mint NFT” endpoint, there is a fromPrivateKey field:
To use KMS instead, we simply replace the fromPrivateKey field with a signatureId field, and enter the signature ID of the private key generated by KMS:
That’s it.
KMS then periodically picks up pending transactions to be signed, signs them, and broadcasts them to the blockchain. All of your sensitive data is encrypted and stored within your security perimeter, so you never have to worry about what would happen if it were somehow intercepted.
To learn more about how to use KMS, please refer to our full guide, and download it for free from the Tatum GitHub.
Keep your sensitive data safe.
We hope this has cleared up some of the confusion about working with mnemonics and private keys, and we hope we have helped you understand how to properly work with your sensitive data. It’s a jungle out there, and if you’re building production-scale blockchain apps, you need to employ the absolute best security practices possible.
To start building secure dApps today, sign up for a free Tatum API key in our dashboard, and if you need any help getting started, hop onto our Discord and one of our devs will get back to you asap.
Happy coding!