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-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VdtNU-0005QJ-VB for bitcoin-development@lists.sourceforge.net; Wed, 06 Nov 2013 03:01:57 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.215.50 as permitted sender) client-ip=209.85.215.50; envelope-from=melvincarvalho@gmail.com; helo=mail-la0-f50.google.com; Received: from mail-la0-f50.google.com ([209.85.215.50]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1VdtNT-0001hz-A9 for bitcoin-development@lists.sourceforge.net; Wed, 06 Nov 2013 03:01:56 +0000 Received: by mail-la0-f50.google.com with SMTP id eo20so3914918lab.9 for ; Tue, 05 Nov 2013 19:01:48 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.112.130.138 with SMTP id oe10mr943032lbb.1.1383706908527; Tue, 05 Nov 2013 19:01:48 -0800 (PST) Received: by 10.112.159.233 with HTTP; Tue, 5 Nov 2013 19:01:48 -0800 (PST) In-Reply-To: References: <20131102050144.5850@gmx.com> Date: Wed, 6 Nov 2013 04:01:48 +0100 Message-ID: From: Melvin Carvalho To: slush Content-Type: multipart/alternative; boundary=047d7b3a88dac1906804ea795e2c X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: doubleclick.net] -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 (melvincarvalho[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: 1VdtNT-0001hz-A9 Cc: bitcoingrant@gmx.com, "bitcoin-development@lists.sourceforge.net" Subject: Re: [Bitcoin-development] Message Signing based authentication 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: Wed, 06 Nov 2013 03:01:57 -0000 --047d7b3a88dac1906804ea795e2c Content-Type: text/plain; charset=ISO-8859-1 On 2 November 2013 22:57, slush wrote: > Glad to see that there are more and more people wanting to replace > passwords with digital signatures. > > Although such method has been already used on other websites like Eligius > or bitcoin-otc, I dont think theres any standard way to doing so yet. > > Two comments to your proposal: > > A) message-to-be-signed need to be carefully composed to be both > structured and human readable. It should contain at least: > Desired username/identity handler > Server identifier (url) > Timestamp to prevent replay attack > Server challenge > > Then the user can see what he's signing, instead of signing some binary > blob which can contain some evil data. > > B) > Same structured data should be a part of html page in some header tag, > ideally signed by server certificate to confirm that the request is valid. > Then the login request can be processed by machine automatically, without a > need of copy&paste by a user. > But where are the private keys stored? Crypto in the browser with help, but although they will expose ECC via the NSS, I dont think bitcoin's particular curve will be supported, because it's not NIST approved. If the use case was presented though, they may add it. This can actually be done today using client side certificates. Two methods. Method 1: In your client side certificate, put in your bitcoin address in the subjectAlternativeName field. This is a field that lets you tell the server "I have another identity" >From the bitcoin address look up via a ".well-known" key server some items previously uploaded. This would normally be a signed value of the key used, or a signed value of the the certificate. The server checks this and logs you in. Method 2: In your client side certificate, put in an HTTP address. That HTTP address contains your bitcoin address and a signed copy of your cert public key or the cert itself. The advantage here is that you dont need a key server. Both methods work, I've been doing this kind of thing for 5 years+, and I'd never go back to passwords on anything I build. I'm all for recreating this UI in javascript too, but I just wonder how to protect the private keys ... > Slush > > > On Sat, Nov 2, 2013 at 6:01 AM, wrote: > >> Passwords are inefficient by design: frequently we hear news from Sony, >> Square Enix, Adobe, and various others about passwords being compromised, >> databases being copied and stolen. This story remains true in the Bitcoin >> space. In light of the recent Bitcointalk forum breach echoes an increasing >> need for passwords to become a thing of the past. >> >> >> >> In celebration of the 5 year anniversary of the Bitcoin whitepaper, we >> are delighted to introduce the Message Signing based authentication method. >> >> >> >> In brief, the authentication work as follows: >> >> >> >> Server provides a token for the client to sign. >> >> client passes the signed message and the bitcoin address back to the >> server. >> >> server validates the message and honors the alias (optional) and bitcoin >> address as identification. >> >> >> >> http://forums.bitcoingrant.org/ >> >> >> >> Above is a proof of concept forum that utilize this authentication >> method. Following Kerckhoffs's principle, this forum only stores the signed >> message and bitcoin address the users provide the first time they use the >> site, both are public information. In addition, there is no database, >> everything is simply an RSS feed. For the sake of usability we have >> included a redis for the sessions, at the cost of additional exposure to >> potential risks: users no longer need to sign a token every time they wish >> to post. >> >> >> >> All source code will be available on github in the next few days. >> >> >> >> We welcome any feedback or suggestions. >> >> >> >> >> >> ------------------------------------------------------------------------------ >> Android is increasing in popularity, but the open development platform >> that >> developers love is also attractive to malware creators. Download this >> white >> paper to learn more about secure code signing practices that can help keep >> Android apps secure. >> >> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk >> _______________________________________________ >> Bitcoin-development mailing list >> Bitcoin-development@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> >> > > > ------------------------------------------------------------------------------ > Android is increasing in popularity, but the open development platform that > developers love is also attractive to malware creators. Download this white > paper to learn more about secure code signing practices that can help keep > Android apps secure. > http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > --047d7b3a88dac1906804ea795e2c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On 2 November 2013 22:57, slush <slush@centrum.cz> wr= ote:

Glad to see that there are more and more people wanting to r= eplace passwords with digital signatures.

Although such method has been already used on other websites like Eligius o= r bitcoin-otc, I dont think theres any standard way to doing so yet.

Two c= omments to your proposal:

A)= message-to-be-signed need to be carefully composed to be both structured a= nd human readable. It should contain at least:
Desired username/identity= handler
Server identifier (url)
Timestamp to prevent replay attack
Server cha= llenge

Then the user can see what he's signing, instead of signing som= e binary blob which can contain some evil data.

B)=
Same structured data should be a part of html page in some header tag, = ideally signed by server certificate to confirm that the request is valid. = Then the login request can be processed by machine automatically, without a= need of copy&paste by a user.

But where are the private keys stored?=A0 Crypto in= the browser with help, but although they will expose ECC via the NSS, I do= nt think bitcoin's particular curve will be supported, because it's= not NIST approved.=A0 If the use case was presented though, they may add i= t.

This can actually be done today using client side certificat= es.=A0 Two methods.

Method 1:

In your c= lient side certificate, put in your bitcoin address in the subjectAlternati= veName field.=A0 This is a field that lets you tell the server "I have= another identity"

From the bitcoin address look up via a ".well-known&quo= t; key server some items previously uploaded.=A0 This would normally be a s= igned value of the key used, or a signed value of the the certificate.=A0 T= he server checks this and logs you in.

Method 2:

In your client side certificate,= put in an HTTP address.=A0 That HTTP address contains your bitcoin address= and a signed copy of your cert public key or the cert itself.

The advantage here is that you dont need a key server.


Both methods work, I've been doing this kind of thing for 5 year= s+, and I'd never go back to passwords on anything I build.

I'm all for recreating this UI in javascript too, but I just wonder how= to protect the private keys ...
=A0

Sl= ush



On Sat, Nov 2, 2013 at 6:01 AM, <b= itcoingrant@gmx.com> wrote:

Passwords are ineffici= ent by design: frequently we hear news from Sony, Square Enix, Adobe, and v= arious others about passwords being compromised, databases being copied and= stolen. This story remains true in the Bitcoin space. In light of the rece= nt Bitcointalk forum breach echoes an increasing need for passwords to beco= me a thing of the past.

=A0

In celebration of the 5 year anniversary of the Bitcoi= n whitepaper, we are delighted to introduce the Message Signing based authe= ntication method.

=A0

In brief, the authentication work as follows:

=A0

Server provides a token for the client to sign.=

= client passes the sign= ed message and the bitcoin address back to the server.

= server validates the m= essage and honors the alias (optional) and bitcoin address as identificatio= n.

=A0

http://forums.bitcoingrant.org/

=A0

Above is a proof of concept forum that utilize this au= thentication method. Following Kerckhoffs's principle, this forum only = stores the signed message and bitcoin address the users provide the first t= ime they use the site, both are public information. In addition, there is n= o database, everything is simply an RSS feed. For the sake of usability we = have included a redis for the sessions, at the cost of additional exposure = to potential risks: users no longer need to sign a token every time they wi= sh to post.

=A0

All source code will be available on github in the nex= t few days.

=A0

We welcome any feedback or suggestions.


=A0
-----------------------------------------= -------------------------------------
Android is increasing in popularity, but the open development platform that=
developers love is also attractive to malware creators. Download this white=
paper to learn more about secure code signing practices that can help keep<= br> Android apps secure.
http://pubads.g.doubleclick.net/gam= pad/clk?id=3D65839951&iu=3D/4140/ostg.clktrk
___________________= ____________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment



-----------------------------------------------------------------------= -------
Android is increasing in popularity, but the open development platform that=
developers love is also attractive to malware creators. Download this white=
paper to learn more about secure code signing practices that can help keep<= br> Android apps secure.
http://pubads.g.doubleclick.net/gam= pad/clk?id=3D65839951&iu=3D/4140/ostg.clktrk
___________________= ____________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment


--047d7b3a88dac1906804ea795e2c--