7 ms·

BitAuth for Decentralized Authentication

105 points by richardburton 12y ago

tonyhb 12y ago
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 the signed header? - How are nonces managed (especially over multiple devices, if the new nonce always needs to be higher than a previously used one)? - Can you have more than one SIN? - If so, what's the benefit of having multiple SINs vs multiple passwords? On a sidenote, bitpay make some seriously kick ass tools and I love how creative they are.
- martindale 12y ago
  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] 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.
  - siralonso 12y ago
    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!
    - martindale 12y ago
      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.
lifeisstillgood 12y ago
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 trusted. But it's fascinating to see the evolution of these things in real time
- doragcoder 12y ago
  I agree. I don't see where this is significantly better. You can add data to signed certs as well, so you can get the SIN functionality that way if I'm not mistaken. I also didn't see if this touched the blockchain at all. They made note about the SIN being public (then again, so is a Public Key), so I'm looking for the SIN to be in a blockchain somewhere.
  - lifeisstillgood 12y ago
    I do need to dig into SIN for that same reason - it makes sense - I think a lot of government identity and records schemes would get vastly simpler if I put my public key online and encrypted my own records I discussed it with a govt architect who wanted to get rid of the "bloody database at centre of every application that thinks it needs to store citizens data" It's a powerful idea
- tveita 12y ago
  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 announcement.
  - voltagex_ 12y ago
    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.
geoffsanders 12y ago
Just use LaunchKey - https://launchkey.com https://launchkey.com or https://github.com/launchkey https://github.com/launchkey
- justysebitcoin 12y ago
  looks great, very professional... but it appears not to be free.
  - jchysk 12y ago
    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.
- teacup50 12y ago
  Why on earth would you outsource two factor auth to a cloud service? Talk about putting all your eggs in the same shared basket.
  - markkum 12y ago
    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".
    - teacup50 12y ago
      So you're dependent on a cloud startup for basic auth and you've got no more security than any other isolated two factor auth system.
al2o3cr 12y ago
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...
- evv 12y ago
  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.
teraflop 12y ago
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 "passwords may travel over plaintext" as a benefit of BitAuth over password authentication. My initial impression is that when not using HTTPS, BitAuth is more secure than password authentication against a passive adversary, but that both are equally vulnerable to MITM attacks.
- martindale 12y ago
  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 mention, the integrity of the secp256r1 curve is in doubt). Furthermore, the path to building a clean user experience around a clean Javascript library that runs [and performs] well in all browsers is much less tenuous than getting browser support for a new algorithm — lending to faster innovation.
  - jeremyw 12y ago
    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 http://blog.cr.yp.to/20140323-ecdsa.html https://bitcointalk.org/index.php?topic=380482.0 https://bitcointalk.org/index.php?topic=380482.0 http://lists.randombit.net/pipermail/cryptography/2014-January/thread.html#6176 http://lists.randombit.net/pipermail/cryptography/2014-Janua...
- Buge 12y ago
scrollaway 12y ago
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/ https://www.mozilla.org/en-US/persona/
- dypsilon 12y ago
  Which, by the way, was discontinued: http://techcrunch.com/2014/03/08/mozilla-stops-developing-its-persona-sign-in-system-because-of-low-adoption/ http://techcrunch.com/2014/03/08/mozilla-stops-developing-it...
  - yeukhon 12y ago
    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.
  - scrollaway 12y ago
    Persona was not discontinued. Persona lost active development and marketing. A wrong decision, but not one that affects the protocol itself.
- desufnoc 12y ago
  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 https://github.com/mozilla/persona/issues/1523
yeukhon 12y ago
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?
- markkum 12y ago
  Supporting multiple devices is a hard problem. We worked for a long time to enable it. Not Bitcoin protocol specific, but some words about our asymmetric key based multi-device solution here; https://www.mepin.com/lost-device/ https://www.mepin.com/lost-device/
  - yeukhon 12y ago
    The solution ^ still require a traditional account registration, or at least connection to the device that was used to create the account (if we go with passwordless registration). Otherwise, "must link their MePIN app to an actual user account in the target service" wouldn't be true.
M4v3R 12y ago
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 http://srp.stanford.edu
erpellan 12y ago
How is this different/better than SSH?
omgitstom 12y ago
The most important piece that needs to be handled is described in the github repo: 'There also needs to be a public place to store SIN's, preferably in a decentralized blockchain or datastore like namecoin. Key revocations could be stored here as well as reviews/feedback to build a reputation around an identity.' Otherwise, apps that integrate will need to store SINs in their user tables. I see that this would add an unnecessary amount of work around management of SINs. Great work, I'm looking forward to see where this goes.

105 points by richardburton 12y ago

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 the signed header? - How are nonces managed (especially over multiple devices, if the new nonce always needs to be higher than a previously used one)? - Can you have more than one SIN? - If so, what's the benefit of having multiple SINs vs multiple passwords? On a sidenote, bitpay make some seriously kick ass tools and I love how creative they are.

martindale 12y ago
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] 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.
- siralonso 12y ago
  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!
  - martindale 12y ago
    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.

lifeisstillgood 12y ago

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 trusted. But it's fascinating to see the evolution of these things in real time

doragcoder 12y ago
I agree. I don't see where this is significantly better. You can add data to signed certs as well, so you can get the SIN functionality that way if I'm not mistaken. I also didn't see if this touched the blockchain at all. They made note about the SIN being public (then again, so is a Public Key), so I'm looking for the SIN to be in a blockchain somewhere.
- lifeisstillgood 12y ago
  I do need to dig into SIN for that same reason - it makes sense - I think a lot of government identity and records schemes would get vastly simpler if I put my public key online and encrypted my own records I discussed it with a govt architect who wanted to get rid of the "bloody database at centre of every application that thinks it needs to store citizens data" It's a powerful idea
tveita 12y ago
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 announcement.
- voltagex_ 12y ago
  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.

geoffsanders 12y ago

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

justysebitcoin 12y ago
looks great, very professional... but it appears not to be free.
- jchysk 12y ago
  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.
teacup50 12y ago
Why on earth would you outsource two factor auth to a cloud service? Talk about putting all your eggs in the same shared basket.
- markkum 12y ago
  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".
  - teacup50 12y ago
    So you're dependent on a cloud startup for basic auth and you've got no more security than any other isolated two factor auth system.

al2o3cr 12y ago

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

evv 12y ago
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.

teraflop 12y ago

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 "passwords may travel over plaintext" as a benefit of BitAuth over password authentication. My initial impression is that when not using HTTPS, BitAuth is more secure than password authentication against a passive adversary, but that both are equally vulnerable to MITM attacks.

martindale 12y ago
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 mention, the integrity of the secp256r1 curve is in doubt). Furthermore, the path to building a clean user experience around a clean Javascript library that runs [and performs] well in all browsers is much less tenuous than getting browser support for a new algorithm — lending to faster innovation.
- jeremyw 12y ago
  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 http://blog.cr.yp.to/20140323-ecdsa.html https://bitcointalk.org/index.php?topic=380482.0 https://bitcointalk.org/index.php?topic=380482.0 http://lists.randombit.net/pipermail/cryptography/2014-January/thread.html#6176 http://lists.randombit.net/pipermail/cryptography/2014-Janua...
Buge 12y ago

scrollaway 12y ago

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/ https://www.mozilla.org/en-US/persona/

dypsilon 12y ago
Which, by the way, was discontinued: http://techcrunch.com/2014/03/08/mozilla-stops-developing-its-persona-sign-in-system-because-of-low-adoption/ http://techcrunch.com/2014/03/08/mozilla-stops-developing-it...
- yeukhon 12y ago
  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.
- scrollaway 12y ago
  Persona was not discontinued. Persona lost active development and marketing. A wrong decision, but not one that affects the protocol itself.
desufnoc 12y ago
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 https://github.com/mozilla/persona/issues/1523

yeukhon 12y ago

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?

markkum 12y ago
Supporting multiple devices is a hard problem. We worked for a long time to enable it. Not Bitcoin protocol specific, but some words about our asymmetric key based multi-device solution here; https://www.mepin.com/lost-device/ https://www.mepin.com/lost-device/
- yeukhon 12y ago
  The solution ^ still require a traditional account registration, or at least connection to the device that was used to create the account (if we go with passwordless registration). Otherwise, "must link their MePIN app to an actual user account in the target service" wouldn't be true.

M4v3R 12y ago

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 http://srp.stanford.edu

erpellan 12y ago

How is this different/better than SSH?

omgitstom 12y ago

The most important piece that needs to be handled is described in the github repo: 'There also needs to be a public place to store SIN's, preferably in a decentralized blockchain or datastore like namecoin. Key revocations could be stored here as well as reviews/feedback to build a reputation around an identity.' Otherwise, apps that integrate will need to store SINs in their user tables. I see that this would add an unnecessary amount of work around management of SINs. Great work, I'm looking forward to see where this goes.