From: Melvin Carvalho <melvincarvalho@gmail•com>
To: slush <slush@centrum•cz>
Cc: bitcoingrant@gmx•com,
"bitcoin-development@lists•sourceforge.net"
<bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Message Signing based authentication
Date: Wed, 6 Nov 2013 04:01:48 +0100 [thread overview]
Message-ID: <CAKaEYh+bAVcK0tUrE75HvSf0PJ5Ps1j_yUheBeOM5Q1EHADdCw@mail.gmail.com> (raw)
In-Reply-To: <CAJna-HgUT2u+nhdz3e8mT99R+TR6o1FFQ4c8KBz_vpc_oSOzSQ@mail.gmail.com>
[-- 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 --]
next prev parent reply other threads:[~2013-11-06 3:01 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-02 5:01 bitcoingrant
2013-11-02 5:54 ` Luke-Jr
2013-11-02 13:02 ` Mike Hearn
2013-11-02 13:16 ` Melvin Carvalho
2013-11-02 13:19 ` Hannu Kotipalo
2013-11-02 16:26 ` Mike Hearn
2013-11-02 16:26 ` Mike Hearn
2013-11-02 16:52 ` Melvin Carvalho
2013-11-02 17:08 ` Jeff Garzik
2013-11-02 17:16 ` Hannu Kotipalo
2013-11-02 21:14 ` Johnathan Corgan
2013-11-02 21:51 ` Mark Friedenbach
2013-11-03 0:29 ` Allen Piscitello
2013-11-03 0:33 ` Luke-Jr
2013-11-03 1:19 ` Allen Piscitello
2013-11-03 1:27 ` Luke-Jr
2013-11-03 1:36 ` Allen Piscitello
2013-11-03 6:23 ` Timo Hanke
2013-11-06 3:38 ` Melvin Carvalho
2013-11-02 21:57 ` slush
2013-11-06 3:01 ` Melvin Carvalho [this message]
2013-11-06 6:41 ` slush
2013-12-06 10:44 ` Melvin Carvalho
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAKaEYh+bAVcK0tUrE75HvSf0PJ5Ps1j_yUheBeOM5Q1EHADdCw@mail.gmail.com \
--to=melvincarvalho@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=bitcoingrant@gmx$(echo .)com \
--cc=slush@centrum$(echo .)cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox