[Bitcoin-development] Message Signing based authentication

[Bitcoin-development] Message Signing based authentication

[bitcoingrant]

[-- Attachment #1: Type: text/plain, Size: 1415 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 4824 bytes --]

Re: [Bitcoin-development] Message Signing based authentication

[Luke-Jr]

On Saturday, November 02, 2013 5:01:43 AM bitcoingrant@gmx.com wrote:
> 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.

Congratulations! You've reinvented what Eligius and Bitcoin-OTC have been 
doing for years! :)

There's no reason to ask the user to provide the address every time, though...

Luke

Re: [Bitcoin-development] Message Signing based authentication

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 435 bytes --]

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

> 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://pilif.github.io/2008/05/why-is-nobody-using-ssl-client-certificates/

[-- Attachment #2: Type: text/html, Size: 2017 bytes --]

Re: [Bitcoin-development] Message Signing based authentication

[Melvin Carvalho]

[-- Attachment #1: Type: text/plain, Size: 2035 bytes --]

On 2 November 2013 14:02, Mike Hearn <mike@plan99.net> wrote:

> On Sat, Nov 2, 2013 at 6:01 AM, <bitcoingrant@gmx.com> wrote:
>
>> 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://pilif.github.io/2008/05/why-is-nobody-using-ssl-client-certificates/
>

I actually use client certificates for almost all of my authentication.

It's true that the browser manufacturers have created an UX which is not
ideal, and very little effort is made to improve it.  But it is possible.
See this project from Mozilla labs.

http://www.azarask.in/blog/post/identity-in-the-browser-firefox/

Unfortunately this got killed :(

More popular is the trusted third party model like OAuth or Persona.
There's a conflict of interest as well, because browser manufacturers are
often identity providers too, so there is an incentive to push TTP
technology.

There's two elements here.  One is paswordless login (which I love).  The
other is who controls your identity.  I like to control my own identity (in
my browser) using PKI.  But facebook and the big webmail providers have a
lions share of the market.

The way to shift the balance is to offer the right incentives.


>
>
> ------------------------------------------------------------------------------
> 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
>
>

[-- Attachment #2: Type: text/html, Size: 4698 bytes --]

Re: [Bitcoin-development] Message Signing based authentication

[Hannu Kotipalo]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02.11.2013 15:02, Mike Hearn wrote:
> 
> http://pilif.github.io/2008/05/why-is-nobody-using-ssl-client-certificates/
>
> 
Maybe this is a bit off-topic, but the *real* answer to the question
"why-is-nobody-using-ssl-client-certificates" is that it would force
www pages to be encrypted and would make it a lot more difficult for
NSA to log www-trafic. So they have been made not-user-friendly by
default.

But what you think about this:
"White paper on passwordless secure login (based on bitcoin/bitmessage
technology)"
https://bitcointalk.org/index.php?topic=323360.0

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlJ0+/cACgkQvafo1Ths1Sw5FwCgxdJB/lazDzxRos1ogSfJQo0V
El4AnjyHxWjOXG6qjcTcWvccty+03xRa
=BikE
-----END PGP SIGNATURE-----

Re: [Bitcoin-development] Message Signing based authentication

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 748 bytes --]

Guys, identity systems for the web are off-topic for this list. Other than
the anonymous passports/SINs/fidelity bond ideas, Bitcoin doesn't have any
relevance to it.

On Sat, Nov 2, 2013 at 2:19 PM, Hannu Kotipalo <hannu.kotipalo@iki.fi>wrote:

> Maybe this is a bit off-topic, but the *real* answer to the question
> "why-is-nobody-using-ssl-client-certificates" is that it would force
> www pages to be encrypted and would make it a lot more difficult for
> NSA to log www-trafic.
>

No, it wouldn't. You can log a user in using SSL and then redirect the user
back to an encrypted page, using cookies for the rest of the session.
Please don't clutter up this list with conspiracy theories. The brutal
reality is that identity is a hard problem.

[-- Attachment #2: Type: text/html, Size: 1101 bytes --]

Re: [Bitcoin-development] Message Signing based authentication

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 147 bytes --]

> No, it wouldn't. You can log a user in using SSL and then redirect the
user back to an encrypted page

sorry, I meant unencrypted page of course

[-- Attachment #2: Type: text/html, Size: 199 bytes --]

Re: [Bitcoin-development] Message Signing based authentication

[Melvin Carvalho]

[-- Attachment #1: Type: text/plain, Size: 1988 bytes --]

On 2 November 2013 17:26, Mike Hearn <mike@plan99.net> wrote:

> Guys, identity systems for the web are off-topic for this list. Other than
> the anonymous passports/SINs/fidelity bond ideas, Bitcoin doesn't have any
> relevance to it.
>
> On Sat, Nov 2, 2013 at 2:19 PM, Hannu Kotipalo <hannu.kotipalo@iki.fi>wrote:
>
>> Maybe this is a bit off-topic, but the *real* answer to the question
>> "why-is-nobody-using-ssl-client-certificates" is that it would force
>> www pages to be encrypted and would make it a lot more difficult for
>> NSA to log www-trafic.
>>
>
> No, it wouldn't. You can log a user in using SSL and then redirect the
> user back to an encrypted page, using cookies for the rest of the session.
> Please don't clutter up this list with conspiracy theories. The brutal
> reality is that identity is a hard problem.
>

Identity need not be a hard problem.  In my view it is a solved problem.

You have a real world entity translated to a digital format.  Yes that can
be slightly ambiguous at time, naming is hard, and people do get this wrong
frequently.

The most common problem is to name something in a way that does not scale.
The solution to this problem is rather easy, and that is to use a URI to
name something, which makes it global and scalable.

In the case of bitcoin you could have use the bitcion URI scheme

bitcion:1fhdjkfhjksf...


>
>
> ------------------------------------------------------------------------------
> 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
>
>

[-- Attachment #2: Type: text/html, Size: 3232 bytes --]

Re: [Bitcoin-development] Message Signing based authentication

[Jeff Garzik]

On Sat, Nov 2, 2013 at 12:52 PM, Melvin Carvalho
<melvincarvalho@gmail.com> wrote:
> Identity need not be a hard problem.  In my view it is a solved problem.


Yes:  https://en.bitcoin.it/wiki/Identity_protocol_v1

Re: [Bitcoin-development] Message Signing based authentication

[Hannu Kotipalo]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02.11.2013 19:08, Jeff Garzik wrote:
> On Sat, Nov 2, 2013 at 12:52 PM, Melvin Carvalho 
> <melvincarvalho@gmail.com> wrote:
>> Identity need not be a hard problem.  In my view it is a solved
>> problem.
> 
> 
> Yes:  https://en.bitcoin.it/wiki/Identity_protocol_v1
> 

Well in the view of an average internet browser, it is not a solved
problem neither does this identity protocol solve it.

But Mike is correct, this is a wrong place to discuss about it.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlJ1M30ACgkQvafo1Ths1SxypQCgor9LQTyKnlr0gByMPPJRQF6U
LpIAnRMj/udBSDJOK+2JP0hhiG1Bk81d
=tcpx
-----END PGP SIGNATURE-----

Re: [Bitcoin-development] Message Signing based authentication

[Johnathan Corgan]

[-- Attachment #1.1: Type: text/plain, Size: 461 bytes --]

On 11/01/2013 10:01 PM, bitcoingrant@gmx.com wrote:

> Server provides a token for the client to sign.

Anyone else concerned about signing an arbitrary string?  Could be a
hash of $EVIL_DOCUMENT, no?  I'd want to XOR the string with my own
randomly generated nonce, sign that, then pass the nonce and the
signature back to the server for verification.

-- 
Johnathan Corgan, Corgan Labs
SDR Training and Development Services
http://corganlabs.com

[-- Attachment #1.2: johnathan.vcf --]
[-- Type: text/x-vcard, Size: 335 bytes --]

begin:vcard
fn:Johnathan Corgan
n:Corgan;Johnathan
org:Corgan Enterprises LLC dba Corgan Labs
adr:;;6081 Meridian Ave. Suite 70-111;San Jose;CA;95120;United States
email;internet:johnathan@corganlabs.com
title:Managing Partner
tel;work:+1 408 463 6614
x-mozilla-html:FALSE
url:http://corganlabs.com
version:2.1
end:vcard


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 230 bytes --]

Re: [Bitcoin-development] Message Signing based authentication

[Mark Friedenbach]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Or SIGHASH of a transaction spending those coins or updating the SIN...

On 11/2/13 2:14 PM, Johnathan Corgan wrote:> On 11/01/2013 10:01 PM,
bitcoingrant@gmx.com wrote:
> 
>> Server provides a token for the client to sign.
> 
> Anyone else concerned about signing an arbitrary string?  Could be
> a hash of $EVIL_DOCUMENT, no?  I'd want to XOR the string with my
> own randomly generated nonce, sign that, then pass the nonce and
> the signature back to the server for verification.
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSdXPaAAoJEAdzVfsmodw4+m8P/1Ce/PwZOYfiFuFJ8pmT2tb2
ro7tw7zSr12RSTvs+qRl7lDzJzQ6BDXOdXZCkcU0Vj3TDm8fdrrXN/iw3iQYU/5Y
3K7hj2mGqQUMovCLw0CbrMWrMvor7FhO6MZsRwe0+VxDV/dDrX5f5vSEhnkR26be
NrzOFU4hqGM3R4eLq8Bmw5rVD/VCrRzKoXXAvJb1EwM1+fQPjKi+bNMJu3reyfXU
5eMbbiM6tUMmPXy9M6vZrN+6ad53x3KUVP6+/hXxsrnfPp57WQzRZlvwTo/qdJ1C
Oxl71m6o2zkXbLTFmg1xmK/A4V1BPTLD6nLDIsw+wTBBfdn22pfDv6Q8d3VRctrd
6x+PMkwysoMjhemmkXCY/7G9GD6AGsrYSqIShSULd9QO5WxAFzRO01ewiRUCUFHi
Dn0LEjy8/R/CWK3jvj9uL3vQh9DLdOtqf/X7cEtjF3LThVP+stFTsmXObhTh/8Ai
YYjpnwOFG5ZtDzRZfP3OCwyhqlsaMlNgN4xnyR4GPaoJRP3a0zllblIbTWzg6nhY
jbON5Ec9N9txGhagYOoAvcQYqGyJdffkBzW82CRUsFYuYYmW2oLUQXPhAGDBIzzj
g/7RjMlM1OEp3qctxMZQlrTj7VJmhD768PRLh2XvEDmEC5Qb8Tcq28Nq5t85/O/6
i3+pzT5rMuiIZWLx7Msv
=tAUY
-----END PGP SIGNATURE-----

Re: [Bitcoin-development] Message Signing based authentication

[Allen Piscitello]

[-- Attachment #1: Type: text/plain, Size: 3050 bytes --]

This was one of my concerns when implementing a scheme where you sign a
refund transaction before the original transaction is broadcast.  I
originally tried to pass a hash and have the server sign it.  However, I
had no way to know that what I was signing wasn't a transaction that was
spending my coins!  So I changed the code to require sending the full
transaction, not just the hash.  The other way to mitigate this is through
not having any unspent outputs from this key.

For authentication, you could have both a user-generated and
server-generated portion, so that you signed something that clearly had
data from you, so even if the server-data was a hash of $EVIL_DOCUMENT, you
have clear plausible deniability in that your data that is also signed is
"ATTEMPTING LOGIN TO XYZ.COM Hash($EVIL_DOCUMENT)".


On Sat, Nov 2, 2013 at 4:51 PM, Mark Friedenbach <mark@monetize.io> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Or SIGHASH of a transaction spending those coins or updating the SIN...
>
> On 11/2/13 2:14 PM, Johnathan Corgan wrote:> On 11/01/2013 10:01 PM,
> bitcoingrant@gmx.com wrote:
> >
> >> Server provides a token for the client to sign.
> >
> > Anyone else concerned about signing an arbitrary string?  Could be
> > a hash of $EVIL_DOCUMENT, no?  I'd want to XOR the string with my
> > own randomly generated nonce, sign that, then pass the nonce and
> > the signature back to the server for verification.
> >
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBAgAGBQJSdXPaAAoJEAdzVfsmodw4+m8P/1Ce/PwZOYfiFuFJ8pmT2tb2
> ro7tw7zSr12RSTvs+qRl7lDzJzQ6BDXOdXZCkcU0Vj3TDm8fdrrXN/iw3iQYU/5Y
> 3K7hj2mGqQUMovCLw0CbrMWrMvor7FhO6MZsRwe0+VxDV/dDrX5f5vSEhnkR26be
> NrzOFU4hqGM3R4eLq8Bmw5rVD/VCrRzKoXXAvJb1EwM1+fQPjKi+bNMJu3reyfXU
> 5eMbbiM6tUMmPXy9M6vZrN+6ad53x3KUVP6+/hXxsrnfPp57WQzRZlvwTo/qdJ1C
> Oxl71m6o2zkXbLTFmg1xmK/A4V1BPTLD6nLDIsw+wTBBfdn22pfDv6Q8d3VRctrd
> 6x+PMkwysoMjhemmkXCY/7G9GD6AGsrYSqIShSULd9QO5WxAFzRO01ewiRUCUFHi
> Dn0LEjy8/R/CWK3jvj9uL3vQh9DLdOtqf/X7cEtjF3LThVP+stFTsmXObhTh/8Ai
> YYjpnwOFG5ZtDzRZfP3OCwyhqlsaMlNgN4xnyR4GPaoJRP3a0zllblIbTWzg6nhY
> jbON5Ec9N9txGhagYOoAvcQYqGyJdffkBzW82CRUsFYuYYmW2oLUQXPhAGDBIzzj
> g/7RjMlM1OEp3qctxMZQlrTj7VJmhD768PRLh2XvEDmEC5Qb8Tcq28Nq5t85/O/6
> i3+pzT5rMuiIZWLx7Msv
> =tAUY
> -----END PGP SIGNATURE-----
>
>
> ------------------------------------------------------------------------------
> 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
>

[-- Attachment #2: Type: text/html, Size: 4119 bytes --]

Re: [Bitcoin-development] Message Signing based authentication

[Luke-Jr]

On Sunday, November 03, 2013 12:29:28 AM Allen Piscitello wrote:
> This was one of my concerns when implementing a scheme where you sign a
> refund transaction before the original transaction is broadcast.  I
> originally tried to pass a hash and have the server sign it.  However, I
> had no way to know that what I was signing wasn't a transaction that was
> spending my coins!  So I changed the code to require sending the full
> transaction, not just the hash.  The other way to mitigate this is through
> not having any unspent outputs from this key.

Well, there's no use case to sign with an address that has already been sent 
coins. The main problem with enforcing this is that you can't exactly stop 
someone from sending to an "identity" address.

Luke

Re: [Bitcoin-development] Message Signing based authentication

[Allen Piscitello]

[-- Attachment #1: Type: text/plain, Size: 1210 bytes --]

I actually had a use case in my case where it was possible, and that was
the check I used to get around it, just configured it so that I always
generated a new key when I needed to set up a 2 of 2 Multisig Refund Tx.
 It was either that or making sure I had no unspent outputs.  The use case
of doing it was laziness in just creating a single key.


On Sat, Nov 2, 2013 at 7:33 PM, Luke-Jr <luke@dashjr.org> wrote:

> On Sunday, November 03, 2013 12:29:28 AM Allen Piscitello wrote:
> > This was one of my concerns when implementing a scheme where you sign a
> > refund transaction before the original transaction is broadcast.  I
> > originally tried to pass a hash and have the server sign it.  However, I
> > had no way to know that what I was signing wasn't a transaction that was
> > spending my coins!  So I changed the code to require sending the full
> > transaction, not just the hash.  The other way to mitigate this is
> through
> > not having any unspent outputs from this key.
>
> Well, there's no use case to sign with an address that has already been
> sent
> coins. The main problem with enforcing this is that you can't exactly stop
> someone from sending to an "identity" address.
>
> Luke
>

[-- Attachment #2: Type: text/html, Size: 1667 bytes --]

Re: [Bitcoin-development] Message Signing based authentication

[Luke-Jr]

On Sunday, November 03, 2013 1:19:51 AM Allen Piscitello wrote:
> I actually had a use case in my case where it was possible, and that was
> the check I used to get around it, just configured it so that I always
> generated a new key when I needed to set up a 2 of 2 Multisig Refund Tx.
>  It was either that or making sure I had no unspent outputs.  The use case
> of doing it was laziness in just creating a single key.

Use cases mean an actual use, not mere laziness. Bitcoin as a system has 
always required a unique EC key (and address) for each transaction.

Luke

Re: [Bitcoin-development] Message Signing based authentication

[Allen Piscitello]

[-- Attachment #1: Type: text/plain, Size: 941 bytes --]

Required vs. strongly recommended is an important distinction.  Satoshi
Dice reuses EC Keys for every single transaction.  Exchanges will have the
same address you deposit in over and over, which gets reused.  This is a
best practice argument rather than a protocol requirement.


On Sat, Nov 2, 2013 at 8:27 PM, Luke-Jr <luke@dashjr.org> wrote:

> On Sunday, November 03, 2013 1:19:51 AM Allen Piscitello wrote:
> > I actually had a use case in my case where it was possible, and that was
> > the check I used to get around it, just configured it so that I always
> > generated a new key when I needed to set up a 2 of 2 Multisig Refund Tx.
> >  It was either that or making sure I had no unspent outputs.  The use
> case
> > of doing it was laziness in just creating a single key.
>
> Use cases mean an actual use, not mere laziness. Bitcoin as a system has
> always required a unique EC key (and address) for each transaction.
>
> Luke
>

[-- Attachment #2: Type: text/html, Size: 1363 bytes --]

Re: [Bitcoin-development] Message Signing based authentication

[Timo Hanke]

On Sat, Nov 02, 2013 at 02:14:22PM -0700, Johnathan Corgan wrote:
> On 11/01/2013 10:01 PM, bitcoingrant@gmx.com wrote:
> 
> > Server provides a token for the client to sign.
> 
> Anyone else concerned about signing an arbitrary string?  Could be a
> hash of $EVIL_DOCUMENT, no?  I'd want to XOR the string with my own
> randomly generated nonce, sign that, then pass the nonce and the
> signature back to the server for verification.

There were several replies like this, suggesting the client should
modify or add something to the token, or should give the token some
structure. But signing a token is not what the client should do in the
first place. At least not if the client's key is (EC)DSA. The standard
way is a challenge-response protocol in the form of the Diffie-Hellman
key exchange, which avoids producing any unintentional signatures.

Say the clients wants to prove he owns private key p, belonging to
public key P. P=p*G and G is the "base" of the (EC)DSA signature system.
The server generates a new keypair (a,A), a is private, A is public, and
sends A to the client as a challenge. The client computes and sends p*A
back. The server verifies whether p*A = a*P.

Only "public keys" are exchanged here, there's nothing that can be
mistaken for a (EC)DSA signature.

Timo

> -- 
> Johnathan Corgan, Corgan Labs
> SDR Training and Development Services
> http://corganlabs.com

> begin:vcard
> fn:Johnathan Corgan
> n:Corgan;Johnathan
> org:Corgan Enterprises LLC dba Corgan Labs
> adr:;;6081 Meridian Ave. Suite 70-111;San Jose;CA;95120;United States
> email;internet:johnathan@corganlabs.com
> title:Managing Partner
> tel;work:+1 408 463 6614
> x-mozilla-html:FALSE
> url:http://corganlabs.com
> version:2.1
> end:vcard
> 




-- 
Timo Hanke
PGP 1EFF 69BC 6FB7 8744 14DB  631D 1BB5 D6E3 AB96 7DA8

Re: [Bitcoin-development] Message Signing based authentication

[Melvin Carvalho]

[-- Attachment #1: Type: text/plain, Size: 1907 bytes --]

On 2 November 2013 22:14, Johnathan Corgan <johnathan@corganlabs.com> wrote:

> On 11/01/2013 10:01 PM, bitcoingrant@gmx.com wrote:
>
> > Server provides a token for the client to sign.
>
> Anyone else concerned about signing an arbitrary string?  Could be a
> hash of $EVIL_DOCUMENT, no?  I'd want to XOR the string with my own
> randomly generated nonce, sign that, then pass the nonce and the
> signature back to the server for verification.
>

Good point.

There are actually times you may want to sign a transaction.

There's a little know HTTP code, 402, "Payment Required".  We should really
start using this at some point ...

http://en.wikipedia.org/wiki/List_of_HTTP_status_codes

Reserved for future use.[2] The original intention was that this code might
be used as part of some form of digital cash or micropayment scheme, but
that has not happened, and this code is not usually used. As an example of
its use, however, Apple's defunct MobileMe service generated a 402 error if
the MobileMe account was delinquent.[citation needed] In addition, YouTube
uses this status if a particular IP address has made excessive requests,
and requires the person to enter a CAPTCHA.


>
> --
> Johnathan Corgan, Corgan Labs
> SDR Training and Development Services
> http://corganlabs.com
>
>
> ------------------------------------------------------------------------------
> 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
>
>

[-- Attachment #2: Type: text/html, Size: 3064 bytes --]

Re: [Bitcoin-development] Message Signing based authentication

[slush]

[-- Attachment #1: Type: text/plain, Size: 3085 bytes --]

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.

Slush


On Sat, Nov 2, 2013 at 6:01 AM, <bitcoingrant@gmx.com> 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
>
>

[-- Attachment #2: Type: text/html, Size: 7484 bytes --]

Re: [Bitcoin-development] Message Signing based authentication

[Melvin Carvalho]

[-- Attachment #1: Type: text/plain, Size: 5121 bytes --]

On 2 November 2013 22:57, slush <slush@centrum.cz> 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, <bitcoingrant@gmx.com> 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
>
>

[-- Attachment #2: Type: text/html, Size: 10544 bytes --]

Re: [Bitcoin-development] Message Signing based authentication

[slush]

[-- Attachment #1: Type: text/plain, Size: 319 bytes --]

> 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.

Trezor, my friend.

Slush

Sent from mobile phone.

[-- Attachment #2: Type: text/html, Size: 362 bytes --]

Re: [Bitcoin-development] Message Signing based authentication

[Melvin Carvalho]

[-- Attachment #1: Type: text/plain, Size: 526 bytes --]

On 6 November 2013 07:41, slush <slush@centrum.cz> wrote:

> > 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.
>
> Trezor, my friend.
>

Looking forward to the trezor release, best of luck.

This may be an interesting read too:

https://www.grc.com/sqrl/sqrl.htm


> Slush
>
> Sent from mobile phone.
>

[-- Attachment #2: Type: text/html, Size: 1141 bytes --]