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
|
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 <mh.in.england@gmail.com>) id 1WW6Ba-0004Tl-4k
for bitcoin-development@lists.sourceforge.net;
Fri, 04 Apr 2014 15:37:42 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.219.47 as permitted sender)
client-ip=209.85.219.47; envelope-from=mh.in.england@gmail.com;
helo=mail-oa0-f47.google.com;
Received: from mail-oa0-f47.google.com ([209.85.219.47])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WW6BY-0007FB-Vu
for bitcoin-development@lists.sourceforge.net;
Fri, 04 Apr 2014 15:37:42 +0000
Received: by mail-oa0-f47.google.com with SMTP id i11so3680455oag.20
for <bitcoin-development@lists.sourceforge.net>;
Fri, 04 Apr 2014 08:37:35 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.60.132.236 with SMTP id ox12mr271597oeb.81.1396625855551;
Fri, 04 Apr 2014 08:37:35 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.96.180 with HTTP; Fri, 4 Apr 2014 08:37:35 -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>
Date: Fri, 4 Apr 2014 17:37:35 +0200
X-Google-Sender-Auth: 4ZcKaGmernhuIYQELYo79Al91L4
Message-ID: <CANEZrP3exbwE0AuZCXQNEC-UoZ0BmTHTpSG6rZsjbwmpKahtCQ@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: =?UTF-8?Q?Eric_Larchev=C3=AAque?= <elarch@gmail.com>
Content-Type: multipart/alternative; boundary=047d7b41cd280120bc04f6394c83
X-Spam-Score: -0.5 (/)
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
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
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: 1WW6BY-0007FB-Vu
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:37:42 -0000
--047d7b41cd280120bc04f6394c83
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Hmmm, well TREZOR requires a web plugin. So if nobody installs plugins then
we have a problem :) But regardless, actually like I said, you don't need a
plugin. Browsers do it all already. With the <keygen> tag they even create
a private key and upload the public part to be signed for you, it's
seamless for the user. I wanted to give you a link to a demo site, but I
can't find it anymore :(
So there's not even a need for people to upgrade anything! It's all there,
already, for everyone.
If you were to make some upgrades, then you'd want to focus on key
management, which indeed is something the Bitcoin world is trying hard to
solve. But that's a small subcomponent. Making a modified version of
Chrome or Firefox that can take their key from a BIP32 hierarchy or
12-words scheme is certainly possible, but then you could still reuse all
the rest of it.
Something I'd really like to see is TREZOR supporting a simple
request/response protocol that a server can trigger, via the USB plugin,
that would allow a server to display some arbitrary text and get a
confirmation. Slush and I talked about it before. There are a LOT of places
that don't care about Bitcoin but do need some kind of safe second factor
auth where users know what they are confirming (e.g. at Google!). If TREZOR
could be used for these things too, that'd increase demand and help push
down prices for Bitcoin users.
On Fri, Apr 4, 2014 at 5:09 PM, Eric Larchev=C3=AAque <elarch@gmail.com> wr=
ote:
> 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 ?
>
> 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)
>
> Eric
>
>
--047d7b41cd280120bc04f6394c83
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hmmm, well TREZOR requires a web plugin. So if nobody inst=
alls plugins then we have a problem :) But regardless, actually like I said=
, you don't need a plugin. Browsers do it all already. With the <key=
gen> tag they even create a private key and upload the public part to be=
signed for you, it's seamless for the user. I wanted to give you a lin=
k to a demo site, but I can't find it anymore :(<div>
<br></div><div>So there's not even a need for people to upgrade anythin=
g! It's all there, already, for everyone.</div><div><br></div><div>If y=
ou were to make some upgrades, then you'd want to focus on key manageme=
nt, which indeed is something the Bitcoin world is trying hard to solve. =
=C2=A0But that's a small subcomponent. =C2=A0Making a modified version =
of Chrome or Firefox that can take their key from a BIP32 hierarchy or 12-w=
ords scheme is certainly possible, but then you could still reuse all the r=
est of it.<br>
<div><div><br></div><div><div>Something I'd really like to see is TREZO=
R supporting a simple request/response protocol that a server can trigger, =
via the USB plugin, that would allow a server to display some arbitrary tex=
t and get a confirmation. Slush and I talked about it before. There are a L=
OT of places that don't care about Bitcoin but do need some kind of saf=
e second factor auth where users know what they are confirming (e.g. at Goo=
gle!). If TREZOR could be used for these things too, that'd increase de=
mand and help push down prices for Bitcoin users.</div>
<div><br></div></div></div></div></div><div class=3D"gmail_extra"><br><br><=
div class=3D"gmail_quote">On Fri, Apr 4, 2014 at 5:09 PM, Eric Larchev=C3=
=AAque <span dir=3D"ltr"><<a href=3D"mailto:elarch@gmail.com" target=3D"=
_blank">elarch@gmail.com</a>></span> 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>I mean, what is the difference between doing that, and =
id with a login/pass and add your bitcoin address in a settings field ? (kn=
owing you 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><div>Eric</div><div><br></div></font></span></div></div></di=
v>
</blockquote></div><br></div>
--047d7b41cd280120bc04f6394c83--
|
