1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
|
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 <natanael.l@gmail.com>) id 1YHggw-0005MB-RC
for bitcoin-development@lists.sourceforge.net;
Sat, 31 Jan 2015 22:39:02 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.169 as permitted sender)
client-ip=74.125.82.169; envelope-from=natanael.l@gmail.com;
helo=mail-we0-f169.google.com;
Received: from mail-we0-f169.google.com ([74.125.82.169])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YHggv-0004zK-GS
for bitcoin-development@lists.sourceforge.net;
Sat, 31 Jan 2015 22:39:02 +0000
Received: by mail-we0-f169.google.com with SMTP id u56so32925123wes.0
for <bitcoin-development@lists.sourceforge.net>;
Sat, 31 Jan 2015 14:38:55 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.194.61.145 with SMTP id p17mr27221834wjr.35.1422743935372;
Sat, 31 Jan 2015 14:38:55 -0800 (PST)
Received: by 10.194.92.208 with HTTP; Sat, 31 Jan 2015 14:38:55 -0800 (PST)
Received: by 10.194.92.208 with HTTP; Sat, 31 Jan 2015 14:38:55 -0800 (PST)
In-Reply-To: <27395C55-CF59-4E65-83CA-73F903272C5F@gmail.com>
References: <27395C55-CF59-4E65-83CA-73F903272C5F@gmail.com>
Date: Sat, 31 Jan 2015 23:38:55 +0100
Message-ID: <CAAt2M18kRgJeNGu9GeKabRpTKPX9rVeoYiKoanz99bmV2jaf4w@mail.gmail.com>
From: Natanael <natanael.l@gmail.com>
To: Brian Erdelyi <brian.erdelyi@gmail.com>
Content-Type: multipart/alternative; boundary=047d7bacc0f2dfd705050dfa620b
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
(natanael.l[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: 1YHggv-0004zK-GS
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: Sat, 31 Jan 2015 22:39:02 -0000
--047d7bacc0f2dfd705050dfa620b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Den 31 jan 2015 23:17 skrev "Brian Erdelyi" <brian.erdelyi@gmail.com>:
>
> 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=E2=80=99s account number. Would it make sense to convert a bitco=
in
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=E2=80=A6 however, would this still be practical o=
r could
the malware generate a rogue bitcoin address that would produce the same 8
digits of the legitimate bitcoin address?
See vanitygen. Yes, 8 characters can be bruteforced.
You need about 100 bits of security for strong security, and at the very
least NOT less than ~64 (see distributed bruteforce projects attacking 64
bit keys for reference, you can find plenty via Google).
You shouldn't rely on mechanisms intended to be used for one-shot auth
where the secret is supposed to be unguessable for another system where the
attacker knows what the target string is and have a fair amount of time to
attempt bruteforce.
Use something more like HMAC instead.
--047d7bacc0f2dfd705050dfa620b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr"><br>
Den 31 jan 2015 23:17 skrev "Brian Erdelyi" <<a href=3D"mailto=
:brian.erdelyi@gmail.com">brian.erdelyi@gmail.com</a>>:<br>
><br>
> Hello all,<br>
><br>
> The number of incidents involving malware targeting bitcoin users cont=
inues to rise.=C2=A0 One category of virus I find particularly nasty is whe=
n the bitcoin address you are trying to send money to is modified before th=
e transaction is signed and recorded in the block chain.=C2=A0 This behavio=
ur allows the malware to evade two-factor authentication by becoming active=
only when the bitcoin address is entered.=C2=A0 This is very similar to ho=
w man-in-the-browser malware attack online banking websites.<br>
><br>
> Out of band transaction verification/signing is one method used with o=
nline banking to help protect against this.=C2=A0 This can be done in a var=
iety of ways with SMS, voice, mobile app or even security tokens.=C2=A0 Thi=
s video demonstrates how HSBC uses a security token to verify transactions =
online. =C2=A0<a href=3D"https://www.youtube.com/watch?v=3DSh2Iha88agE">htt=
ps://www.youtube.com/watch?v=3DSh2Iha88agE</a>.<br>
><br>
> Many Bitcoin wallets and services already use Open Authentication (OAT=
H) based one-time passwords (OTP).=C2=A0 Is there any interest (or existing=
work) in in the Bitcoin community adopting the OATH Challenge-Response Alg=
orithm (OCRA) for verifying transactions?<br>
><br>
> I know there are other forms of malware, however, I want to get though=
ts on this approach as it would involve the use of a decimal representation=
of the bitcoin address (depending on particular application).=C2=A0 In the=
HSBC example (see YouTube video above), this was the last 8 digits of the =
recipient=E2=80=99s account number.=C2=A0 Would it make sense to convert a =
bitcoin address to decimal and then truncate to 8 digits for this purpose?=
=C2=A0 I understand that truncating the number in some way only increases t=
he likelihood for collisions=E2=80=A6 however, would this still be practica=
l or could the malware generate a rogue bitcoin address that would produce =
the same 8 digits of the legitimate bitcoin address?</p>
<p dir=3D"ltr">See vanitygen. Yes, 8 characters can be bruteforced.</p>
<p dir=3D"ltr">You need about 100 bits of security for strong security, and=
at the very least NOT less than ~64 (see distributed bruteforce projects a=
ttacking 64 bit keys for reference, you can find plenty via Google). </p>
<p dir=3D"ltr">You shouldn't rely on mechanisms intended to be used for=
one-shot auth where the secret is supposed to be unguessable for another s=
ystem where the attacker knows what the target string is and have a fair am=
ount of time to attempt bruteforce. </p>
<p dir=3D"ltr">Use something more like HMAC instead. </p>
--047d7bacc0f2dfd705050dfa620b--
|
