<p>Gavin Andresen <a href="http://bitcointalk.org/index.php?topic=107180.msg1175847#msg1175847" rel="nofollow">wrote</a> "We need a payment protocol with non-repudiation built in."</p>

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

<p>Alternatively, a layer external to bitcoin could be built using GPG.</p>

<p>This thread addresses the question and potential solutions:</p>

<ul>
<li><a href="http://bitcointalk.org/index.php?topic=107180.0" rel="nofollow">http://bitcointalk.org/index.php?topic=107180.0</a></li>
</ul>

CC BY-SA 3.0
2012-09-28T00:29:00.663Z
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
CC BY-SA 3.0
2012-09-28T16:02:14.273Z
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.
makerofthings7
CC BY-SA 3.0
2012-09-28T16:58:33.103Z
@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
CC BY-SA 3.0
2012-09-27T22:58:25.450Z
2012-09-28T16:55:14.077Z
2012-09-28T16:55:14.077Z
Stephen Gornick
<p>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.</p>

<p>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?</p>

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

CC BY-SA 3.0
2012-09-27T19:01:52.870Z
2012-09-27T19:01:52.870Z
ThePiachu
<p>There is a lot of evidence that <a href="https://security.stackexchange.com/q/12041/396">man in the middle attacks are common</a>, and this is a good question for the Bitcoin community to review.</p>
<p>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.</p>
<p>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.</p>
<p>Here are some links to get you started with securing HTTP:</p>
<ul>
<li>Send <strong>all</strong> traffic over SSL, and set cookies to Secure and HTTP Only</li>
<li>Use a well known Public Key vendor and ask visitors to run <a href="https://security.stackexchange.com/search?q=convergence">Convergence.IO</a> to prevent a stolen/hacked key from being used.</li>
<li><a href="https://security.stackexchange.com/q/19911/396">Disable compression</a> on the webserver or load balancer and <a href="https://security.stackexchange.com/search?q=BEAST">configure SSL correctly</a></li>
<li><a href="https://stackoverflow.com/q/9418891/328397">Scan the client's machine for old plugins</a> and ask them to upgrade</li>
<li>Have a <a href="https://security.stackexchange.com/q/12412/396">dedicated domain for purchases</a> with only one &quot;dot&quot; in the name</li>
</ul>
<p>Ultra-modern DNS Security</p>
<ul>
<li>Use DNSSec with a trusted root domain that supports DNSSEC at the root (.com, .org, etc)</li>
<li>Use <a href="https://www.rfc-editor.org/rfc/rfc6698" rel="nofollow noreferrer">TLSA RFC6698</a> to self-publish SSL keys into DNS</li>
</ul>
<p>For ToR clients</p>
<ul>
<li>Have a <a href="https://bitcoin.stackexchange.com/q/4821/1878">.onion address</a>  (users at Exit nodes can modify your HTTP/S session)</li>
<li><a href="https://security.stackexchange.com/q/12395/396">Detect that the user is using ToR</a> and redirect them to your .onion address</li>
</ul>

CC BY-SA 3.0
2012-09-27T19:34:49.263Z
2012-09-28T14:27:54.987Z
2021-10-07T07:05:27.390Z
makerofthings7
<p>There are many network level attacks that give someone <a href="https://security.stackexchange.com/questions/tagged/mitm">Man in the Middle</a> ability to replace my Bitcoin address with their own.  </p>

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

<ul>
<li>How can I assure my consumers they are actually paying the correct person?</li>
</ul>

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

<p><a href="https://bitcoin.stackexchange.com/q/304/1878">A similar question is here,</a> but it doesn't focus on the safety and security of communicating the address from the (anonymous) merchant to the (anonymous) recipient.</p>

CC BY-SA 3.0
2012-12-17T23:29:18.667Z
Related: [How to prevent the Test Network from being misrepresented as production](http://bitcoin.stackexchange.com/q/5816/1878)
makerofthings7
<transactions><security><attack><fraud><merchants>
How can I assure my consumers they are actually paying the correct person? (prevent MITM attacks)
makerofthings7
# How can I assure my consumers they are actually paying the correct person? (prevent MITM attacks)

(Asked by: username_0 on 2012-09-27)

There are many network level attacks that give someone [Man in the Middle](https://security.stackexchange.com/questions/tagged/mitm) 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,](https://bitcoin.stackexchange.com/q/304/1878) but it doesn't focus on the safety and security of communicating the address from the (anonymous) merchant to the (anonymous) recipient.

**Tags:** transactions, security, attack, fraud, merchants

> **Comments:**
> **username_0**: Related: [How to prevent the Test Network from being misrepresented as production](http://bitcoin.stackexchange.com/q/5816/1878)  

---

## 3 answers

### Answer by username_0 on 2012-09-27. Score: 3 | Accepted answer

There is a lot of evidence that [man in the middle attacks are common](https://security.stackexchange.com/q/12041/396), 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](https://security.stackexchange.com/search?q=convergence) to prevent a stolen/hacked key from being used.
* [Disable compression](https://security.stackexchange.com/q/19911/396) on the webserver or load balancer and [configure SSL correctly](https://security.stackexchange.com/search?q=BEAST)
* [Scan the client's machine for old plugins](https://stackoverflow.com/q/9418891/328397) and ask them to upgrade
* Have a [dedicated domain for purchases](https://security.stackexchange.com/q/12412/396) 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](https://www.rfc-editor.org/rfc/rfc6698) to self-publish SSL keys into DNS

For ToR clients

* Have a [.onion address](https://bitcoin.stackexchange.com/q/4821/1878) (users at Exit nodes can modify your HTTP/S session)
* [Detect that the user is using ToR](https://security.stackexchange.com/q/12395/396) and redirect them to your .onion address


---

### Answer by username_1 on 2012-09-27. Score: 1

Gavin Andresen [wrote](http://bitcointalk.org/index.php?topic=107180.msg1175847#msg1175847) "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>

> **Comments:**
> **username_2**: 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?  
> **username_0**: 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.  
> **username_1**: @username_2, 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.  

---

### Answer by username_3 on 2012-09-27. Score: 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...


---

