How can I assure my consumers they are actually paying the correct person? (prevent MITM attacks)

Question

There are many network level attacks that give someone Man in the Middle ability to replace my Bitcoin address with their own.

Since there is no way to cancel a transaction, and the best practice is to generate a unique address per sender...

• How can I assure my consumers they are actually paying the correct person?

I want to avoid the situation where a sender actually sent payment to a spoofer (which can't be canceled), and still have a dynamic address that people can send money to based on the sender.

A similar question is here, but it doesn't focus on the safety and security of communicating the address from the (anonymous) merchant to the (anonymous) recipient.

Answer 1

There is a lot of evidence that man in the middle attacks are common, and this is a good question for the Bitcoin community to review.

When publishing the Bitcoin address on a web page, either you will be using a static address (one address for many senders) or generating a new address for that particular user.

Regardless of the frequency of generating a new address, the bottom line is if you send your Bitcoin address over HTTP you need to secure the DNS infrastructure, SSL, and make sure your site is protected from HTTP based XSS, CSRF attacks.

Here are some links to get you started with securing HTTP:

• Send all traffic over SSL, and set cookies to Secure and HTTP Only
• Use a well known Public Key vendor and ask visitors to run Convergence.IO to prevent a stolen/hacked key from being used.
• Disable compression on the webserver or load balancer and configure SSL correctly
• Scan the client's machine for old plugins and ask them to upgrade
• Have a dedicated domain for purchases with only one "dot" in the name

Ultra-modern DNS Security

• Use DNSSec with a trusted root domain that supports DNSSEC at the root (.com, .org, etc)
• Use TLSA RFC6698 to self-publish SSL keys into DNS

For ToR clients

• Have a .onion address (users at Exit nodes can modify your HTTP/S session)
• Detect that the user is using ToR and redirect them to your .onion address

Answer 2

Well, if you are worried about a man in the middle attacks, that means there is someone that can capture the communication between two people and change it on the fly. If the threat is constant, you can't really do much. However, usually an attacker will not get access to all of your channels of communication. You could, for example, put your Bitcoin address on some secure website, embed it in a forum signature, or at least provide your customers with your PGP public key to prevent any tempering with your messages.

Generally the attack is not Bitcoin-specific. It's just a matter of getting any data securely between two parties. It becomes more and more complicated based on the restrictions you are applying - whether the attacker can alter both sides of communication, is there any secure channel, some secret shared between the parties or do they know anything about one another?

Generally, secure your computer, secure the way you communicate with your client, and this will take care of most of the attacks. If your computer isn't secure enough, your Bitcoins might be lost anyway...

Answer 3

Gavin Andresen wrote "We need a payment protocol with non-repudiation built in."

He proposes a method where the private key for an address becomes the authority to sign payment requests for an entity.

Alternatively, a layer external to bitcoin could be built using GPG.

This thread addresses the question and potential solutions:

• http://bitcointalk.org/index.php?topic=107180.0