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."<p>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 <i>passive</i> adversary, but that both are equally vulnerable to MITM attacks.
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.<p>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...
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.<p>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:<p>- How does the browser know your private keys?<p>- How does the browser know how to send the signed header?<p>- How are nonces managed (especially over multiple devices, if the new nonce always needs to be higher than a previously used one)?<p>- Can you have more than one SIN?<p>- If so, what's the benefit of having multiple SINs vs multiple passwords?<p>On a sidenote, bitpay make some seriously kick ass tools and I love how creative they are.
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.<p>Still, kudos for their efforts. If they continue to improve this, it could take a fair amount of auth "market" some day.<p>[1] <a href="http://srp.stanford.edu" rel="nofollow">http://srp.stanford.edu</a>
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.<p>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!<p>[1]: <a href="https://www.mozilla.org/en-US/persona/" rel="nofollow">https://www.mozilla.org/en-US/persona/</a>
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.<p>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.<p>But it's fascinating to see the evolution of these things in real time
The most important piece that needs to be handled is described in the github repo:<p>'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.'<p>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.<p>Great work, I'm looking forward to see where this goes.
So the workflow is generate asymmetric key pairs, generate SIN, sign the request with your private key to verify?<p>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?
Just use LaunchKey - <a href="https://launchkey.com" rel="nofollow">https://launchkey.com</a> or <a href="https://github.com/launchkey" rel="nofollow">https://github.com/launchkey</a>