Wladimir [ARCHIVE] on Nostr: 📅 Original date posted:2014-09-13 📝 Original message:On Fri, Sep 12, 2014 at ...
📅 Original date posted:2014-09-13
📝 Original message:On Fri, Sep 12, 2014 at 10:59 PM, Mark van Cuijk <mark at coinqy.com> wrote:
> If you do so, please make sure the length of the hash is included in the PaymentDetails/PaymentRequest. If someone parses the URI and doesn’t have an authenticated way of knowing the expected length of the hash, a MITM attacker can just truncate the hash to lower security.
But if they can truncate they can just as well pass a completely
different hash that matches their payment request. If an attacker can
change the bitcoin: URI, this scheme is broken.
The point of the proposal is to make sure that the payment request
matches the URI. So *if* you communicate the URI by secure means, this
authenticates the associated payment request as well, even if fetched
by insecure means (such as http:...) itself.
Wladimir
📝 Original message:On Fri, Sep 12, 2014 at 10:59 PM, Mark van Cuijk <mark at coinqy.com> wrote:
> If you do so, please make sure the length of the hash is included in the PaymentDetails/PaymentRequest. If someone parses the URI and doesn’t have an authenticated way of knowing the expected length of the hash, a MITM attacker can just truncate the hash to lower security.
But if they can truncate they can just as well pass a completely
different hash that matches their payment request. If an attacker can
change the bitcoin: URI, this scheme is broken.
The point of the proposal is to make sure that the payment request
matches the URI. So *if* you communicate the URI by secure means, this
authenticates the associated payment request as well, even if fetched
by insecure means (such as http:...) itself.
Wladimir