BitAuth for Decentralized Authentication(blog.bitpay.com) |
BitAuth for Decentralized Authentication(blog.bitpay.com) |
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.
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.
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 https://bitcointalk.org/index.php?topic=380482.0 http://lists.randombit.net/pipermail/cryptography/2014-Janua...
The attacker can't imitate you because the site has your public key already.
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...
Unfortunately, I can't think of a decent key-protection solution that doesn't involve custom hardware.
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.
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]: I am fully aware that HN does not support proper 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!
Still, kudos for their efforts. If they continue to improve this, it could take a fair amount of auth "market" some day.
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!
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.
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
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.
Client certificates certainly work, but most people wouldn't see them in their browser, let alone seek them out.
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 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
'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.
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?
Talk about putting all your eggs in the same shared basket.
In fact, this even lends itself to expansion into n-factor authorization methods.
And if all authentication is done client-side with javascript, the attacker could steal your private key and use it to attack other sites.
The point I'm trying to make is that if you can trust SSL to protect a BitAuth signature, you can also trust it to protect a password. So claiming "passwords may travel over plaintext" as a relative advantage of this scheme is disingenuous; in both cases, you need to provide that protection at a lower protocol level.