Security

Most of the companies take at least some security measures, like SSL encryption or password hashing. Most won’t go deep into details. We’ll try to tell you about everything we do to keep your data safe.

A friendly reminder: all our code is available on GitHub, so you don’t need to believe our words, you can check the source code for yourself. We’ll add links where it is applicable.

3rd party scripts

Our basic requirement is that no external code should run in the context of the app. No visit trackers, no behavior analytics, no heatmap analyzers, or even error trackers. We guarantee this.

Web App security

Some people find web apps unsafe to use. Due to the Web’s dynamic nature, there are a few big security issues that can happen: malicious code can inject 3rd party untrusted code, track you and send the data somewhere.

But we adhere to the strictest security protocols. Thanks to Content Security Policy we make it impossible to inject untrusted code and to send requests to any servers except ours.

Account access

The first question that pops up: can anyone get access to my account?

Usually, when someone tries to hack into your account, they do so using random passwords. We will not allow this. We limit the number of unsuccessful signings to your account to 10 tries per day per account per IP and 100 tries per day per account. It’s more than enough for you to try to remember the right password, but for a hacker, it won’t be enough to even warm up.

If we were to be hacked, you should know that we also hash passwords, but we use the algorithm called Argon2, which was selected as the winner of the Password Hashing Competition in July 2015.

Your account is safe with us.

Data encryption

Our data encryption safety is is based on two great algorithms: PBKDF2 and AES.

PBKDF2 is the algorithm that creates a secure master key from your master password. It is the same algorithm that password managers like 1Password, KeePass, and Bitwarden use. If you use a strong enough master password, it may take trillions of years to brute force your master key.

It gets a little complicated from here:

  • when you’re busy creating a wallet, your device generates a secret key. Under the hood, we use it to encrypt this wallet’s data. This key never leaves the device in plaintext — hence “secret”.
  • we then use your master key to encrypt the secret key into a thing we call a chest, which we upload to the server. Only you will be able to get the secret key out of the chest on, say, another device because nobody but you know the master password.
  • by the way, the said secret key is an AES with a key length of 256 bit. It is used by many governments in the world for transmitting top-secret information and is practically impossible to crack.

So all and all your data is safe — even from us.

How invites work

Here’s where we use some more algorithms: RSA-PSS and ECDH.

RSA-PSS is an asymmetric encryption algorithm. It means, it has two keys: one to encrypt or sign stuff (private key) and the other — to decrypt or verify the signature (public key). When you signed up, your device generated a random key pair. The private key is encrypted using your master key, the public key is uploaded as-is. It allows us to verify that the invite was in fact generated by this person, and also make sure nobody can generate those invite except you.

The invite is validated by both the backend and your device at each step of the invitation process, so we cannot do any shady business in the middle of the process.

Let’s say Alice invited Bob to her wallet.

The main problem with invites is that we need to securely transfer the secret key for the wallet from Alice to Bob without compromising their master keys — as you remember, chests are encrypted with it.

This is where ECDH shines. ECDH is an algorithm that helps two parties to agree about the encryption key they should use while transmitting the data through an untrusted intermediary — this should be our servers in this case.

The process is even more complicated, but we’ll try to explain it:

  1. Bob generates an ECDH key pair. Yes, it also goes in pairs with the same rules: the public one can be viewed by anybody and the private one should be kept secret.
  2. Bob sends the public key and the invite. At the same time the device displays a hash representation of the public key — we show both a SHA-512 and a set of emojis to make the thing beautiful.
  3. Alice checks if the invite was in fact created by her. If so, the app asks if she wants Bob to join the wallet, while showing the hash representation of Bob's public key. It's a very important part: Alice and Bob should make sure the hashes are the same, because if they are not, the server could have changed the public key, making the whole transmission unsafe!
  4. once Alice allows Bob to join, her device also generates an ECDH keypair. Here’s where the magic math ✨ happens: if you know your private key and other person’s public key, you can safely derive a new encryption key, that will be the same for the second person! At the same time if you only know two public keys — the stuff that the server sees while transmitting the data — you cannot do anything at all.
  5. so Alice generates a key from Bob’s public key and her private key — we’ll call it the invite key. She then and encrypts the secret key using it and passes it to Bob along with her public key.
  6. Bob receives the message. He, in turn, derives the invite key using his private key and Alice's public key and decrypt the secret key.

Boy, that’s a lot of text and highlights. Most of the action happens in this file.

So even we cannot trick you into sharing your keys with us.