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