Crypto Wallets Two Factor Authentication

Cryptocurrency systems and applications are not under central regulation, and the openness of this world implies a large number of attacks against the various digital currencies. When your user authentication is enhanced by means of two or multi-factor authentication (2FA or MFA) in addition to your username and password, you may feel that access to your wallet is secure. Is this necessarily true?

*TL;DR In this blog post I will guide you through several attack scenarios and then suggest approaches to mitigate against credential theft. *

Learning from history

In 2018, there was an incident where user credentials for the MyEtherWallet website were stolen. The attacker used DNS spoofing to convince users to enter their credentials into a malicious duplicate of the actual site.

DNSSEC provides some mitigation of these sorts of attack and will likely play a more prominent role in the future, but for the time being the added security is opt-in via web browser configuration which we will not discuss in more detail here.

Obviously the aim of the following scenarios is not to encourage malicious activity, rather to show the vulnerabilities of crypto wallet sites where authentication and credential modification are based upon a particular set of approaches.

Simple user/password authentication

First, let’s take an example whereby an unauthorized user steals another user’s wallet by misrepresenting a server which they control as the login page of the legitimate crypto wallet website. Alice enters the wallet site address in the browser and is redirected to a phishing site which looks exactly like the official one. She may not even see the difference in the browser address bar if the corresponding DNS records were replaced.

(Another very common trick is to register a domain name which is very similar to the existing site (typosquatting) but which differs by a single character, for example, elang-solutions.com rather than erlang-solutions.com).

Bob, who is operating the phishing site, captures Alice’s username and password and uses them to authenticate to the actual crypto wallet site, as shown in Figure 1. Alice may notice some inconsistency after logging in, but it’s too late. Bob has been granted access to Alice’s wallet already.

Please accept marketing-cookies to watch this image.

Adding two-factor authentication

Let’s extend the last example with the addition of two-factor authentication (2FA).

The system sends a one-time password via SMS to a phone number associated with Alice’s account. The one-time password needs to be supplied by Alice as well as providing her username and password. Two-factor authentication enhances security by ensuring that you not only need to supply a credential but you also (typically) need to be in possession of something, in this case a mobile phone but it could also be a cryptographic token generator, one-time-pad, or a particular email address .

As before, Alice is redirected to the phishing site and enters the username and password. Bob forwards Alice’s credentials to the real wallet site. Bob changes the phishing site to ask for the secondary credential.

Meanwhile, the official site sends an SMS to Alice containing the one-time password. Alice doesn’t know that she has been redirected, so she enters the code received in SMS on Bob’s site. In common with the example of basic username/password theft, Bob captures this data too, and enters it into the official site, as shown in Figure 2. For the official site, the real identity of the user is transparent, it doesn’t know that Bob has logged in instead of Alice. In fact, the SMS-based two-factor authentication doesn’t add more security in this case. Why is this so?

Please accept marketing-cookies to watch this image.

Here we see a typical man-in-the-middle (MITM) attack. From the system’s point of view, the communication channel for authentication is blocked by the attacker. When entering the required username, password and secondary credential, the attacker can emulate all of these activities.

Even though the system uses several channels for sending data to the client (web browser, mobile phone), the authentication data from the client is supplied to the system via a single channel.

All the credentials supplied by Alice in order for the system to perform authentication traverses the same path: Alice -> phishing site -> Bob -> wallet.

How can we overcome this attack, better still, how can we detect, and mitigate against such attacks?

A possible solution: using multiple channels

Use separate paths for user -> system communication, preferably via encrypted channels. A typical example of this is registration activation via email. The wallet server stores a piece of information internally that should be matched with the information in the email, by clicking on the link in the email for example.

When Alice clicks the link, and Bob catches the communication, the attack can still be successful, but if this communication goes through another site, the information will be sent from Alice directly to the wallet which enables Alice (and not Bob) to complete the authentication, as shown in Figure 3.

The Elixir-based Phoenix Framework offers several ways to secure your communication channels. You can configure your site to support email sending via SMTP with relatively simple configuration. For security reasons, it is important to store confidential information separately from the source code, and be aware that the security of email sending heavily depends on the settings of the particular SMTP solution.

It goes without saying but at the very minimum you should enable TLS transport using certificates, and force all incoming requests to use TLS. This can also be configured for Phoenix.

How can we be safer?

Even if the login authentication has been hacked, and the hacker can access parts of our private account data, it is generally useful to prevent creating transactions without additional confirmation and authentication from the user.

Although creating a phishing site to steal login information seems relatively simple by replicating the design of the official web pages, emulating the account management interface is much more complex, and the hack can easily be detected by the client.

It is also possible to restrict the usage of personal data, namely account information and private keys. The client should only retrieve private information connected to the account when needed, without caching it in the server state or cookies.

This applies more strictly to the private key: only fetch the key when initiating a transaction. It is also preferred not to store the key in its unencrypted form in memory. If this level of security is insufficient, there is an option to use cold storage, which means that your cryptocurrency wallet is stored offline.

Conclusion

When providing a service on a public network, you need to prepare for a wide range of different attacks against the weak points in your system. Even in the case of a simple authentication process, there are various candidates for improvement. In order to protect data in cryptocurrency wallets, the user interface must meet the highest possible security requirements. Based on our growing presence and experience in fintech services, we are happy to help you with analyzing and improving the level of security of your existing system, or building a system that complies with the up-to-date security standards.

Find out more about what we do in the FinTech and blockchain space.

For more high-quality FinTech content you can join our FinTech mailing list.