9

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.

3

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:

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

1

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...

1

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:

  • 3
    After reading the question I immediately thought about your thread and Gavin's project, but it only makes it possible to prove that both sides agreed on payment address before the transaction happened. Could you elaborate how this solution better then lets say SSL if the process gets hijacked right from the begging by MITM? – Serith Sep 28 '12 at 0:29
  • What's better than SSL? TLS 3.2 with TLSA (RFC6698) plus DNSSec ~or~ a ToR .onion address. Bitcoin would be supporting current best practices if it did this. – goodguys_activate Sep 28 '12 at 16:02
  • @Serith, not sure what you mean by "both sides fist agree". If the request includes a signed message, that's one side presenting an address and the sender choosing to verify or sending without verify. But at a later time, if the sender claims to have not received the funds, the sender has the signed message to confirm that funds were sent to the address requested. – Stephen Gornick Sep 28 '12 at 16:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.