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
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <marek@palatinus.cz>) id 1WW63D-0005k3-So
for bitcoin-development@lists.sourceforge.net;
Fri, 04 Apr 2014 15:29:03 +0000
X-ACL-Warn:
Received: from mail-ob0-f170.google.com ([209.85.214.170])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WW63C-0006YM-Qb
for bitcoin-development@lists.sourceforge.net;
Fri, 04 Apr 2014 15:29:03 +0000
Received: by mail-ob0-f170.google.com with SMTP id uz6so3658244obc.15
for <bitcoin-development@lists.sourceforge.net>;
Fri, 04 Apr 2014 08:28:57 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:sender:in-reply-to:references:from
:date:message-id:subject:to:cc:content-type;
bh=+s/X2dw2gQ6i4SAJWdXfxmYOe5i3k+NmtmiZ9gYXI1A=;
b=XZRZZx/4yRzM9Ste5ykq1s1f2m9N1gNw9c37Ee9S2vo5Vr7vSh6wa9J0Nhf68lDjiJ
pA3EibnSWH0vkTX1evG/Y9w+4YOFfuolpSnF34q/KtatSJklRIsZSXwmsvaSJgbYrQSB
I6IqcEJrGsgVC8Y9Naa74hgcNFKXZswbSuCPZf8jLBRkxBl43NIiyix35Ydjf5ENiAGS
0VTr7v/Q6rB5aVJHcutFvkyo34jK5Dw/fKbEmziDhGh0XVAITt7qPwUDOTC/Xlb9wqex
bu34e9HHaEQ8Zw+N0jZRpoBFcffwnfqKgFAeXoFve9iinJ4hQs+aTn4/zcw0h4F9Kmq5
yq+A==
X-Gm-Message-State: ALoCoQmiDIdfeQF7eWSk78Sv7HMsvz3DQtHzT5YMzrHuJL1PG0fGuord1nzlvq8JNuqmRAiRrcSe
X-Received: by 10.60.157.167 with SMTP id wn7mr20155041oeb.7.1396625337376;
Fri, 04 Apr 2014 08:28:57 -0700 (PDT)
MIME-Version: 1.0
Sender: marek@palatinus.cz
Received: by 10.60.102.9 with HTTP; Fri, 4 Apr 2014 08:28:27 -0700 (PDT)
In-Reply-To: <CA+WZAErh6M6BV1imAXZaHQjX+5RKtj7Ma7_-+5KW9BpLw354Sg@mail.gmail.com>
References: <CA+WZAEp3HsW5ESGUZ7YfR1MZXGC5jd+LucUt_MUP8K94Xwhuhg@mail.gmail.com>
<CANEZrP0KVyp2Va7Wyy=t0qYkLNK9BDUaSzBfuzQss+=weLJ1Fw@mail.gmail.com>
<CA+WZAEqYKv8T1OMCKhOJvf5FAy=WujJ=OhtsYP9aBf=4ZPNxmw@mail.gmail.com>
<CANEZrP0DTYqobECBbw6eZqdk+-TR_2jhBtOviN08r31EQGmZHQ@mail.gmail.com>
<CANEZrP2Z5x0_kOQ=8-BMzbmi9=D=ou=s3dgEksMA5F84BHSt9A@mail.gmail.com>
<CA+WZAEqREDkDvmhM7AY+Ju3fkm3uOGm39Ef9+SYoEr43ybbg2Q@mail.gmail.com>
<CAJna-Hhz+K0iw4b8DDp5tNpQg6nJABKmu__aDbgT9M26PJ9tAg@mail.gmail.com>
<CA+WZAErh6M6BV1imAXZaHQjX+5RKtj7Ma7_-+5KW9BpLw354Sg@mail.gmail.com>
From: slush <slush@centrum.cz>
Date: Fri, 4 Apr 2014 17:28:27 +0200
X-Google-Sender-Auth: yAIqSTQ0GQ9wIl3aTD6ZZ372BSc
Message-ID: <CAJna-HheqSrDGD5btZURb9ONWexCMM69SXqWEOuJ+bsW7pR4oA@mail.gmail.com>
To: =?ISO-8859-1?Q?Eric_Larchev=EAque?= <elarch@gmail.com>
Content-Type: multipart/alternative; boundary=047d7bd6b1f61f014e04f6392d56
X-Spam-Score: 1.0 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(slush[at]centrum.cz)
1.0 HTML_MESSAGE BODY: HTML included in message
X-Headers-End: 1WW63C-0006YM-Qb
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Draft BIP for seamless website
authentication using Bitcoin address
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: Fri, 04 Apr 2014 15:29:04 -0000
--047d7bd6b1f61f014e04f6392d56
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Fri, Apr 4, 2014 at 5:09 PM, Eric Larchev=EAque <elarch@gmail.com> wrote=
:
> On Fri, Apr 4, 2014 at 4:56 PM, slush <slush@centrum.cz> wrote:
>
>> I'm cracking my head for many months with the idea of using TREZOR for
>> web auth purposes. Unfortunately I'm far from any usable solution yet.
>>
>> My main comments to your BIP: Don't use bitcoin addresses directly and
>> don't encourage services to use this "login" for financial purposes. Mik=
e
>> is right, mixing authentication and financial services is wrong. Use som=
e
>> function to generate other private/public key from bitcoin's seed/privat=
e
>> key to not leak bitcoin-related data to website.
>>
>>
> I'm probably very naive, but the fact that the authentication key is your
> Bitcoin address was for me a great feature :)
> What are the risks associated of id yourself with a bitcoin address you
> plan to use on the website for transaction ?
>
>
Ideally you should not reuse the address, so the website will need more
addresses or bip32 xpub anyway.
By using wallet address and accidentally using such address in some
transaction, you may be leaking your identity with with other business -
think about Silkroad (sorry Mike :-).
By using derived key, you can be sure your identity won't be linked with
any other activity on the internet.
I mean, what is the difference between doing that, and id with a login/pass
> and add your bitcoin address in a settings field ? (knowing you could
> always find a mechanism to transfer the account to another bitcoin addres=
s
> if needed)
>
> *) You can change address in settings field. It's not so easy when addres=
s
=3D=3D your identity.
*) There's plenty of websites which do need authentication but don't need
to know your bank account / bitcoin address at all. Facebook, Gmail,
Twitter ...
Ideally, the user should not care about "what address do I use for this
service", because in the future user should not care about addresses at all
(handling of private keys is already eliminated by bip32, handling of raw
addresses may be eliminated soon by bip70 or similar solutions).
I can imagine that the private/public data will be derived automatically
from some secret master key (ideally derived from bip32 seed, which is
already secured well by the user) and the URL of the service.
Marek
--047d7bd6b1f61f014e04f6392d56
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Apr 4, 2014 at 5:09 PM, Eric Larchev=EAque <span dir=3D"ltr"><<a hre=
f=3D"mailto:elarch@gmail.com" target=3D"_blank">elarch@gmail.com</a>></s=
pan> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">=
<div class=3D"gmail_quote"><div class=3D"">On Fri, Apr 4, 2014 at 4:56 PM, =
slush <span dir=3D"ltr"><<a href=3D"mailto:slush@centrum.cz" target=3D"_=
blank">slush@centrum.cz</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">
<div dir=3D"ltr">I'm cracking my head for many months with the idea of =
using TREZOR for web auth purposes. Unfortunately I'm far from any usab=
le solution yet.<div><br></div><div>My main comments to your BIP: Don't=
use bitcoin addresses directly and don't encourage services to use thi=
s "login" for financial purposes. Mike is right, mixing authentic=
ation and financial services is wrong. Use some function to generate other =
private/public key from bitcoin's seed/private key to not leak bitcoin-=
related data to website.</div>
<div><br></div></div></blockquote><div><br></div></div><div>I'm probabl=
y very naive, but the fact that the authentication key is your Bitcoin addr=
ess was for me a great feature :)</div><div>What are the risks associated o=
f id yourself with a bitcoin address you plan to use on the website for tra=
nsaction ?</div>
<div><br></div></div></div></div></blockquote><div><br></div><div>Ideally y=
ou should not reuse the address, so the website will need more addresses or=
bip32 xpub anyway.</div><div><br></div><div>By using wallet address and ac=
cidentally using such address in some transaction, you may be leaking your =
identity with with other business - think about Silkroad (sorry Mike :-).</=
div>
<div><br></div><div>=A0By using derived key, you can be sure your identity =
won't be linked with any other activity on the internet.</div><div><br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
></div><div>I mean, what is the difference between doing that, and id with =
a login/pass and add your bitcoin address in a settings field ? (knowing yo=
u could always find a mechanism to transfer the account to another bitcoin =
address if needed)</div>
<span class=3D"HOEnZb"><font color=3D"#888888">
<div><br></div></font></span></div></div></div></blockquote><div>*) You can=
change address in settings field. It's not so easy when address =3D=3D=
your identity.</div><div>*) =A0There's plenty of websites which do nee=
d authentication but don't need to know your bank account / bitcoin add=
ress at all. Facebook, Gmail, Twitter ...</div>
<div><br></div><div>Ideally, the user should not care about "what addr=
ess do I use for this service", because in the future user should not =
care about addresses at all (handling of private keys is already eliminated=
by bip32, handling of raw addresses may be eliminated soon by bip70 or sim=
ilar solutions).</div>
<div><br></div><div>I can imagine that the private/public data will be deri=
ved automatically from some secret master key (ideally derived from bip32 s=
eed, which is already secured well by the user) and the URL of the service.=
=A0</div>
<div><br></div><div>Marek</div></div></div></div>
--047d7bd6b1f61f014e04f6392d56--
|
