BitAuth for Decentralized Authentication • Hacker News Board

Re: BitAuth for Decentralized Authentication

#11

Post by martindale » Tue, Jul 01, 2014, 11:16 PM UTC

tonyhb wrote: post #2

This seems like the HMAC authorisation in OAuth 1, moved to HTTP via JS and custom headers. If the comparison is right, it should be a generally secure and easy to implement auth protocol. It would be great for something like this to be commonplace, but the UI definitely needs to be solid. A few questions looking at it initially: - How does the browser know your private keys? - How does the browser know how to send t…

Multiple SINs (read: identities) are an intended benefit of this mechanism. In fact, nonces are verified per SIN, so this provides sequence enforcement per client as we intend for each device to have its own SIN.

We have a reference implementation for key management in [our example client](https://github.com/bitpay/node-bitpay-client)[1], and will be publishing a more formal document as soon as it is complete.

[1]: I am fully aware that HN does not support proper Markdown.

Re: BitAuth for Decentralized Authentication

#12

Post by justysebitcoin » Tue, Jul 01, 2014, 11:37 PM UTC

geoffsanders wrote: post #4

Just use LaunchKey - https://launchkey.com or https://github.com/launchkey

looks great, very professional... but it appears not to be free.

Re: BitAuth for Decentralized Authentication

#13

Post by jchysk » Tue, Jul 01, 2014, 11:48 PM UTC

justysebitcoin wrote: post #12

geoffsanders wrote: post #4

Just use LaunchKey - https://launchkey.com or https://github.com/launchkey

looks great, very professional... but it appears not to be free.

If an application wants to offer their users multi-factor authentication with LaunchKey it's free. If the application wants to use it internally for their employees with some of the Pro features or requires forced factors then it starts costing money. Non-profits it's free.

Re: BitAuth for Decentralized Authentication

#14

Post by evv » Tue, Jul 01, 2014, 11:52 PM UTC

al2o3cr wrote: post #5

It's Tuesday, so I guess it's time for another "assume a public-key infrastructure" post - this time with OMG BITCOINZ sauce on top. It still handwaves away the biggest problem: getting users to store a private key securely. If that was straightforward, we'd all be using GPG already...

For decent security, both problems need to be addressed- trusting the identity of public keys, as well as securing your private key.

Unfortunately, I can't think of a decent key-protection solution that doesn't involve custom hardware.

Re: BitAuth for Decentralized Authentication

#15

Post by voltagex_ » Wed, Jul 02, 2014, 12:04 AM UTC

tveita wrote: post #9

lifeisstillgood wrote: post #3

I mean this stuff is just catnip for me. Unexpected new uses of technology from one domain to another, just serves to reinforce how seminal bitcoin was/is. Having looked at it with my very layperson eyes, I struggle to see how it is significantly better than say client side certificates. Same idea - sign a request with local private key, only difference is using the SIN mechanism to let the server know I am to be tru…

Digital signatures were not invented with Bitcoin. TLS supports client certificates perfectly well, and your browser probably supports them. This scheme also has a lot of beginner-level oversights, IMO. It doesn't delimit the URI from the body, and it doesn't protect the HTTP method itself nor any potentially important headers. This makes me suspect that no cryptographers laid their eyes on this before the announceme…

I really really really want to do a redesign of the client certificates UI for Firefox, but alas I'm not a UI person.

Client certificates certainly work, but most people wouldn't see them in their browser, let alone seek them out.

Re: BitAuth for Decentralized Authentication

#16

Post by teacup50 » Wed, Jul 02, 2014, 12:35 AM UTC

geoffsanders wrote: post #4

Just use LaunchKey - https://launchkey.com or https://github.com/launchkey

Why on earth would you outsource two factor auth to a cloud service?

Talk about putting all your eggs in the same shared basket.

Re: BitAuth for Decentralized Authentication

#17

Post by jeremyw » Wed, Jul 02, 2014, 1:12 AM UTC

martindale wrote: post #10

teraflop wrote: post #7

OK, I'll be the obligatory critic: I don't see how this solves any problems that TLS client certificates don't. The introduction says BitPay considered client certificates, but doesn't say why they rejected them. And "easy to implement wherever TLS is implemented" sounds like more of a selling point than "easy to implement wherever the Bitcoin protocol is implemented." Also, it seems a little questionable to claim "p…

Author here. Thanks for the healthy criticism! This is still a work in progress, and we're looking for this kind of feedback. We had the objective of minimizing the surface area for attack, so we did not want to expand the scope to include non-ECDSA algorithms. Utilizing the same curve as Bitcoin (secp256k1) has a number of advantages, not the least of which is incentivizing the verification of its security (not to m…

Can you unpack on why begin a new protocol with an algorithm in doubt? I understand implementations are well understood, but the "incentivizing the verification of its security" period will seem small comfort when the break comes, no?

For other readers, here is some discussion of secp256k1 security. (You mention r1 above, but BitAuth references k1?)

http://blog.cr.yp.to/20140323-ecdsa.html https://bitcointalk.org/index.php?topic=380482.0 http://lists.randombit.net/pipermail/cryptography/2014-Janua...

Re: BitAuth for Decentralized Authentication

#18

Post by Buge » Wed, Jul 02, 2014, 1:34 AM UTC

teraflop wrote: post #7

OK, I'll be the obligatory critic: I don't see how this solves any problems that TLS client certificates don't. The introduction says BitPay considered client certificates, but doesn't say why they rejected them. And "easy to implement wherever TLS is implemented" sounds like more of a selling point than "easy to implement wherever the Bitcoin protocol is implemented." Also, it seems a little questionable to claim "p…

If you register for a site where the connection is safe, then go to a dangerous place, this method has an advantage over a password even during MITM attack.

The attacker can't imitate you because the site has your public key already.

Re: BitAuth for Decentralized Authentication

#19

Post by scrollaway » Wed, Jul 02, 2014, 1:35 AM UTC

As usual in decentralized authentication posts, I'd like to mention Mozilla Persona[1] which is a decentralized third party authentication service over the open source BrowserID protocol.

I don't mean to diminish the author's work in any way; but if you're interested in these things and don't know about Persona, please look into it!

[1]: https://www.mozilla.org/en-US/persona/

Re: BitAuth for Decentralized Authentication

#20

Post by dypsilon » Wed, Jul 02, 2014, 1:44 AM UTC

scrollaway wrote: post #19

As usual in decentralized authentication posts, I'd like to mention Mozilla Persona[1] which is a decentralized third party authentication service over the open source BrowserID protocol. I don't mean to diminish the author's work in any way; but if you're interested in these things and don't know about Persona, please look into it! [1]: https://www.mozilla.org/en-US/persona/

Which, by the way, was discontinued: http://techcrunch.com/2014/03/08/mozilla-stops-developing-it...