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.

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 https://bitcointalk.org/index.php?topic=380482.0 http://lists.randombit.net/pipermail/cryptography/2014-Janua...

If you register for a site where the connection is safe, then go to a dangerous place, this method has an advantage over a password even during MITM attack.

The attacker can't imitate you because the site has your public key already.

But the protocol doesn't do mutual authentication, so without using HTTPS, you have no way of ensuring that you're contacting the correct server. So during the authentication process, the attacker can control your view of the site and get you to sign whatever login requests they want.

Yeah I think you're right.

And if all authentication is done client-side with javascript, the attacker could steal your private key and use it to attack other sites.

You can still use SSL, why that argument? BitAuth makes you sign-up and log-in with a public key, SSL plays along to verify the server. Win-win?

Sure, and any sane implementation of BitAuth should use SSL.

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.

That's right. But it does reduce the cost of a compromised server. Since no passwords are stored in the server itself, if it's compromised, the user's passwords won't be exposed (even if they're encrypted, they're often weakly encrypted, especially as time goes by).

Passwords should usually not be encrypted. Saying a password is encrypted implies that there is a decryption function that can produce the original password in plaintext. This should not be the case. Instead, typically, a key derivation function like bcrypt, scrypt, etc. is applied. The output of these are sometimes referred to as "password hashes" because like hashes they are not reversible.

Yes, my mistake. I meant hashed.

If someone could make the UI work in a browser, client certificates will come back with a vengeance. Until then...