diff options
| author | Brian Erdelyi <brian.erdelyi@gmail.com> | 2015-02-01 08:49:05 -0400 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-02-01 12:49:15 +0000 |
| commit | 05345807cface54e17b48b92b78ab9c8093f6ac5 (patch) | |
| tree | 9e81617ed2be874d7e5ef7f9436fe47d1e1c41ae | |
| parent | 14b9283309c218ccc3691753483c8c9028b21eeb (diff) | |
| download | pi-bitcoindev-05345807cface54e17b48b92b78ab9c8093f6ac5.tar.gz pi-bitcoindev-05345807cface54e17b48b92b78ab9c8093f6ac5.zip | |
Re: [Bitcoin-development] Proposal to address Bitcoin malware
| -rw-r--r-- | 11/861962c5b6d43a8d7ff8cf53614a824b53a7fd | 144 |
1 files changed, 144 insertions, 0 deletions
diff --git a/11/861962c5b6d43a8d7ff8cf53614a824b53a7fd b/11/861962c5b6d43a8d7ff8cf53614a824b53a7fd new file mode 100644 index 000000000..328d14287 --- /dev/null +++ b/11/861962c5b6d43a8d7ff8cf53614a824b53a7fd @@ -0,0 +1,144 @@ +Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] + helo=mx.sourceforge.net) + by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <brian.erdelyi@gmail.com>) id 1YHtxj-0003nb-9s + for bitcoin-development@lists.sourceforge.net; + Sun, 01 Feb 2015 12:49:15 +0000 +Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com + designates 209.85.192.45 as permitted sender) + client-ip=209.85.192.45; envelope-from=brian.erdelyi@gmail.com; + helo=mail-qg0-f45.google.com; +Received: from mail-qg0-f45.google.com ([209.85.192.45]) + by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) + (Exim 4.76) id 1YHtxh-000149-J4 + for bitcoin-development@lists.sourceforge.net; + Sun, 01 Feb 2015 12:49:15 +0000 +Received: by mail-qg0-f45.google.com with SMTP id q107so44152053qgd.4 + for <bitcoin-development@lists.sourceforge.net>; + Sun, 01 Feb 2015 04:49:08 -0800 (PST) +X-Received: by 10.229.174.70 with SMTP id s6mr31330482qcz.7.1422794948175; + Sun, 01 Feb 2015 04:49:08 -0800 (PST) +Received: from [192.168.1.58] ([64.147.83.112]) + by mx.google.com with ESMTPSA id 78sm15383899qgi.38.2015.02.01.04.49.06 + (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); + Sun, 01 Feb 2015 04:49:07 -0800 (PST) +Content-Type: multipart/alternative; + boundary="Apple-Mail=_9DC5231B-226F-4B81-9007-F1D7B91A1D6C" +Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) +From: Brian Erdelyi <brian.erdelyi@gmail.com> +In-Reply-To: <CAAt2M1-b7ByF0yVSmwD_nj3uUSo5GFOmH860n1k6oKX_sqvEkw@mail.gmail.com> +Date: Sun, 1 Feb 2015 08:49:05 -0400 +Message-Id: <88211D58-DE9D-4B4A-B3A5-2EEFDFC5E02B@gmail.com> +References: <27395C55-CF59-4E65-83CA-73F903272C5F@gmail.com> + <CAAt2M18kRgJeNGu9GeKabRpTKPX9rVeoYiKoanz99bmV2jaf4w@mail.gmail.com> + <1348028F-26F8-42CB-9859-C9CB751BF0C9@gmail.com> + <CAAt2M1_3BdKQTVxsN7Hc-W=q0_NWyhBg1UAuSwxRQ8BePDa-8g@mail.gmail.com> + <CAAt2M1-b7ByF0yVSmwD_nj3uUSo5GFOmH860n1k6oKX_sqvEkw@mail.gmail.com> +To: Natanael <natanael.l@gmail.com> +X-Mailer: Apple Mail (2.2070.6) +X-Spam-Score: -0.6 (/) +X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. + See http://spamassassin.org/tag/ for more details. + -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for + sender-domain + 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider + (brian.erdelyi[at]gmail.com) + -0.0 SPF_PASS SPF: sender matches SPF record + 1.0 HTML_MESSAGE BODY: HTML included in message + -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from + author's domain + 0.1 DKIM_SIGNED Message has a DKIM or DK signature, + not necessarily valid + -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature +X-Headers-End: 1YHtxh-000149-J4 +Cc: bitcoin-development@lists.sourceforge.net +Subject: Re: [Bitcoin-development] Proposal to address Bitcoin malware +X-BeenThere: bitcoin-development@lists.sourceforge.net +X-Mailman-Version: 2.1.9 +Precedence: list +List-Id: <bitcoin-development.lists.sourceforge.net> +List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> +List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> +List-Post: <mailto:bitcoin-development@lists.sourceforge.net> +List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> +List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe> +X-List-Received-Date: Sun, 01 Feb 2015 12:49:15 -0000 + + +--Apple-Mail=_9DC5231B-226F-4B81-9007-F1D7B91A1D6C +Content-Transfer-Encoding: quoted-printable +Content-Type: text/plain; + charset=utf-8 + + +In online banking, the banks generate account numbers. An attacker = +cannot generate their own account number and the likelihood of an = +attacker having the same account number that I am trying to transfer = +funds to is low and this is why OCRA is effective with online banking. + +With Bitcoin, the Bitcoin address is comparable to the recipient=E2=80=99s= + bank account number. I now see how an an attacker can brute force the = +bitcoin address with vanitygen. Is there any way to generate an 8 digit = +number from the bitcoin address that can be used to verify transactions = +in such a way (possibly with hashing?) that brute forcing a bitcoin = +address would take longer than a reasonable period of time (say 60 = +seconds) so a system could time out if a transaction was not completed = +in that time? + +I=E2=80=99ve also looked into BIP70 (Payment Protocol) that claims = +protection against man-in-the-middle/man-in-the-browser (MitB) based = +attacks. A common way to protect against this is with out-of-band = +transaction verification = +(http://en.wikipedia.org/wiki/Man-in-the-browser#Out-of-band_transaction_v= +erification = +<http://en.wikipedia.org/wiki/Man-in-the-browser#Out-of-band_transaction_v= +erification>). I see how BIP 70 verifies the payment request, however, = +is there any way to verify that the transaction signed by the wallet = +matches the request before it is sent to the blockchain (and how can = +this support out of band verification)? Perhaps this is something that = +can only be supported when sending money with web based wallets. + +Brian Erdelyi= + +--Apple-Mail=_9DC5231B-226F-4B81-9007-F1D7B91A1D6C +Content-Transfer-Encoding: quoted-printable +Content-Type: text/html; + charset=utf-8 + +<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html = +charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; = +-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" = +class=3D""><div class=3D""><br class=3D""></div><div class=3D"">In = +online banking, the banks generate account numbers. An attacker = +cannot generate their own account number and the likelihood of an = +attacker having the same account number that I am trying to transfer = +funds to is low and this is why OCRA is effective with online = +banking.</div><div class=3D""><br class=3D""></div><div class=3D"">With = +Bitcoin, the Bitcoin address is comparable to the recipient=E2=80=99s = +bank account number. I now see how an an attacker can brute force = +the bitcoin address with vanitygen. Is there any way to generate = +an 8 digit number from the bitcoin address that can be used to verify = +transactions in such a way (possibly with hashing?) that brute forcing a = +bitcoin address would take longer than a reasonable period of time (say = +60 seconds) so a system could time out if a transaction was not = +completed in that time?</div><div class=3D""><br class=3D""></div><div = +class=3D"">I=E2=80=99ve also looked into BIP70 (Payment Protocol) that = +claims protection against man-in-the-middle/man-in-the-browser (MitB) = +based attacks. A common way to protect against this is with = +out-of-band transaction verification (<a = +href=3D"http://en.wikipedia.org/wiki/Man-in-the-browser#Out-of-band_transa= +ction_verification" = +class=3D"">http://en.wikipedia.org/wiki/Man-in-the-browser#Out-of-band_tra= +nsaction_verification</a>). I see how BIP 70 verifies the payment = +request, however, is there any way to verify that the transaction signed = +by the wallet matches the request before it is sent to the blockchain = +(and how can this support out of band verification)? Perhaps this = +is something that can only be supported when sending money with web = +based wallets.</div><div class=3D""><br class=3D""></div><div = +class=3D"">Brian Erdelyi</div></body></html>= + +--Apple-Mail=_9DC5231B-226F-4B81-9007-F1D7B91A1D6C-- + + |