From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YHvuG-0006LC-Je for bitcoin-development@lists.sourceforge.net; Sun, 01 Feb 2015 14:53:48 +0000 Received: from dd32718.kasserver.com ([85.13.150.64]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1YHvuE-0004x4-IO for bitcoin-development@lists.sourceforge.net; Sun, 01 Feb 2015 14:53:48 +0000 Received: from [192.168.1.100] (ip-88-152-247-108.hsi03.unitymediagroup.de [88.152.247.108]) by dd32718.kasserver.com (Postfix) with ESMTPSA id 2849549023EB for ; Sun, 1 Feb 2015 15:28:36 +0100 (CET) Message-ID: <54CE3816.6020505@bitwatch.co> Date: Sun, 01 Feb 2015 15:28:38 +0100 From: "mbde@bitwatch.co" User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: bitcoin-development@lists.sourceforge.net References: <27395C55-CF59-4E65-83CA-73F903272C5F@gmail.com> In-Reply-To: <27395C55-CF59-4E65-83CA-73F903272C5F@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. X-Headers-End: 1YHvuE-0004x4-IO 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2015 14:53:48 -0000 > This video demonstrates how HSBC uses a security token to verify transactions online. https://www.youtube.com/watch?v=3DSh2Iha88agE. Since it's not very widely used outside of Austria and Germany, this may be interesting for some: there is a second factor scheme called "cardTAN" or "chipTAN" where authentication codes are generated on a device which is not specifically linked to an accout. When authenticating an online banking transaction the process is as follows: http://i.imgur.com/eWsffsp.jpg 1. Insert bank card into TAN generator 2. Scan flickering code on screen with the device's photodetector 3. Confirm amount to transfer and recipient on the generator 4. Finalize online banking transaction by entering a challenge-response generated by the device https://www.youtube.com/watch?v=3D5gyBC9irTsM&t=3D22s http://en.wikipedia.org/wiki/Transaction_authentication_number#chipTAN_.2= F_cardTAN -------- Original Message -------- *Subject: *[Bitcoin-development] Proposal to address Bitcoin malware *From: *Brian Erdelyi *To: *bitcoin-development@lists.sourceforge.net *Date: *Sat, 31 Jan 2015 18:15:53 -0400 > Hello all, > > The number of incidents involving malware targeting bitcoin users > continues to rise. One category of virus I find particularly nasty is > when the bitcoin address you are trying to send money to is modified > before the transaction is signed and recorded in the block chain. > This behaviour allows the malware to evade two-factor authentication > by becoming active only when the bitcoin address is entered. This is > very similar to how man-in-the-browser malware attack online banking > websites. > > Out of band transaction verification/signing is one method used with > online banking to help protect against this. This can be done in a > variety of ways with SMS, voice, mobile app or even security tokens. > This video demonstrates how HSBC uses a security token to verify > transactions online. https://www.youtube.com/watch?v=3DSh2Iha88agE. > > Many Bitcoin wallets and services already use Open Authentication > (OATH) based one-time passwords (OTP). Is there any interest (or > existing work) in in the Bitcoin community adopting the OATH > Challenge-Response Algorithm (OCRA) for verifying transactions? > > I know there are other forms of malware, however, I want to get > thoughts on this approach as it would involve the use of a decimal > representation of the bitcoin address (depending on particular > application). In the HSBC example (see YouTube video above), this was > the last 8 digits of the recipient=92s account number. Would it make > sense to convert a bitcoin address to decimal and then truncate to 8 > digits for this purpose? I understand that truncating the number in > some way only increases the likelihood for collisions=85 however, would > this still be practical or could the malware generate a rogue bitcoin > address that would produce the same 8 digits of the legitimate bitcoin > address? > > Brian Erdelyi > > > -----------------------------------------------------------------------= ------- > Dive into the World of Parallel Programming. The Go Parallel Website, > sponsored by Intel and developed in partnership with Slashdot Media, is= your > hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials and more. Tak= e a > look and join the conversation now. http://goparallel.sourceforge.net/ > > > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development