BitAuth for Decentralized Authentication
blog.bitpay.com
BitAuth for Decentralized Authentication
1–10 of 41 posts
Re: BitAuth for Decentralized Authentication
#2This 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.
Re: BitAuth for Decentralized Authentication
#3I 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
Re: BitAuth for Decentralized Authentication
#4Just use LaunchKey - https://launchkey.com or https://github.com/launchkey
Re: BitAuth for Decentralized Authentication
#5It'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...
Re: BitAuth for Decentralized Authentication
#6I 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…
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.
Re: BitAuth for Decentralized Authentication
#7OK, 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.
Re: BitAuth for Decentralized Authentication
#8I 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…
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.
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
Re: BitAuth for Decentralized Authentication
#9I 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 announcement.
Re: BitAuth for Decentralized Authentication
#10OK, 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 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.