BitAuth for Decentralized Authentication • Hacker News Board

Re: BitAuth for Decentralized Authentication

#21

Post by teraflop » Wed, Jul 02, 2014, 1:55 AM UTC

Buge wrote: post #18

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.

But the protocol doesn't do mutual authentication, so without using HTTPS, you have no way of ensuring that you're contacting the correct server. So during the authentication process, the attacker can control your view of the site and get you to sign whatever login requests they want.

Re: BitAuth for Decentralized Authentication

#22

Post by yeukhon » Wed, Jul 02, 2014, 1:57 AM UTC

dypsilon wrote: post #20

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

The right intrepation is that Mozilla is not funding the project, but the protocl (browser id) and Persona source code are still out there.

The downside is Mozilla MIGHT sunset their Persona infrastructure one day. But that's not a real concern because Mozilla is never interested in being people's Persona verifier. They were hoping Persona would take off and people would host their own bridge, instead of relying on Mozillia's.

Re: BitAuth for Decentralized Authentication

#23

Post by siralonso » Wed, Jul 02, 2014, 2:03 AM UTC

martindale wrote: post #11

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

Not only does HN not support markdown, but it breaks links you write using markdown :)

Really nice work. Question - if you generate the private keys client-side and use a password only to decrypt them for use (still client-side), wouldn't this make associating accounts across devices kinda difficult? As insecure as email/password auth is, it's pretty portable.

Looking forward to playing with bitauth!

Re: BitAuth for Decentralized Authentication

#24

Post by yeukhon » Wed, Jul 02, 2014, 2:06 AM UTC

So the workflow is generate asymmetric key pairs, generate SIN, sign the request with your private key to verify?

How exactly does it work for multiple devices? Each device has its own key pair and an unique SIN? How do we connect multiple SINs as one user?

Re: BitAuth for Decentralized Authentication

#25

Post by desufnoc » Wed, Jul 02, 2014, 3:19 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/

I lost interest in Persona/BrowserID when it became apparent that hosts like Fastmail[1] were unable to act as identity providers.

[1]: https://github.com/mozilla/persona/issues/1523

Re: BitAuth for Decentralized Authentication

#26

Post by scrollaway » Wed, Jul 02, 2014, 3:38 AM UTC

dypsilon wrote: post #20

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

Persona was not discontinued. Persona lost active development and marketing. A wrong decision, but not one that affects the protocol itself.

Re: BitAuth for Decentralized Authentication

#27

Post by martindale » Wed, Jul 02, 2014, 3:47 AM UTC

siralonso wrote: post #23

martindale wrote: post #11

Earlier quoted context omitted.

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

Not only does HN not support markdown, but it breaks links you write using markdown :) Really nice work. Question - if you generate the private keys client-side and use a password only to decrypt them for use (still client-side), wouldn't this make associating accounts across devices kinda difficult? As insecure as email/password auth is, it's pretty portable. Looking forward to playing with bitauth!

Not particularly. The pattern for resolving this is already increasingly commonplace; login with your username and password, then confirm the login from one of your already authorized devices.

In fact, this even lends itself to expansion into n-factor authorization methods.

Re: BitAuth for Decentralized Authentication

#28

Post by M4v3R » Wed, Jul 02, 2014, 7:44 AM UTC

So, they've basically just reinvented SRP [1] using EC crypto. I'm a big fan of SRP and use it in production, but it has already years of refinements which makes it very secure. Designing auth mechanisms is hard, there are many subtle ways you can get it wrong. If you're looking for this kind of auth mechanism, I recommend to take a look at SRP first.

Still, kudos for their efforts. If they continue to improve this, it could take a fair amount of auth "market" some day.

[1] http://srp.stanford.edu

Re: BitAuth for Decentralized Authentication

#29

Post by pencilcode » Wed, Jul 02, 2014, 9:11 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…

That's right. But it does reduce the cost of a compromised server. Since no passwords are stored in the server itself, if it's compromised, the user's passwords won't be exposed (even if they're encrypted, they're often weakly encrypted, especially as time goes by).

Re: BitAuth for Decentralized Authentication

#30

Post by markkum » Wed, Jul 02, 2014, 9:34 AM UTC

teacup50 wrote: post #16

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.

Funnily; the reason to outsource is exactly about not putting all your eggs in the same shared basket. You outsource the 2nd factor and keep the first factor (passwords) in-house. Implementing everything in-house is a "same shared basket".