
BitAuth for Decentralized Authentication - richardburton
http://blog.bitpay.com/2014/07/01/bitauth-for-decentralized-authentication.html
======
teraflop
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
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
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-Janua...](http://lists.randombit.net/pipermail/cryptography/2014-January/thread.html#6176)

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

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

------
M4v3R
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)

------
scrollaway
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
Which, by the way, was discontinued:
[http://techcrunch.com/2014/03/08/mozilla-stops-developing-
it...](http://techcrunch.com/2014/03/08/mozilla-stops-developing-its-persona-
sign-in-system-because-of-low-adoption/)

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

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

~~~
tveita
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_
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.

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

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

------
erpellan
How is this different/better than SSH?

------
geoffsanders
Just use LaunchKey - [https://launchkey.com](https://launchkey.com) or
[https://github.com/launchkey](https://github.com/launchkey)

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

