Today, we are excited to announce our proposal for a new passwordless authentication protocol, based on the same cryptography used in the Bitcoin protocol. By eliminating server-side storage of passwords, we can drastically reduce the impact of a compromised server.

We've given long and careful thought to how best to protect the security of our customers' data, of especially critical importance when dealing with financial information. Existing authentication schemes that you might be familiar with include username and password, client-side SSL certificates, or even shared secrets — in the end of our review, we found each of these to be lacking in various ways, so we made the decision to build BitAuth.

View BitAuth on GitHub »
install via npm: `npm install bitauth`

BitAuth is a way to do secure, passwordless authentication using the same elliptic-curve cryptography as Bitcoin. Instead of using a shared secret, the client signs each request using a private key and the server checks to make sure the signature is valid and matches the public key. A nonce is used to prevent replay attacks and provide sequence enforcement.

Introducing the SIN

The System Identification Number, or SIN, is a new form of identity based on a crypographic keypair. SINs were originally proposed by Bitcoin Core Developer Jeff Garzik, and are an integral component of BitAuth. The SIN is analogous to a Bitcoin address, as it takes the following form:

base58check( 0x0F + 0x02 + ripemd160( sha256( k1 ) )

Where k1 is your public key from an ECDSA secp256k1 keypair. 0x0F is the special byte for SINs, and 0x02 is the type of SIN; in this case, a standalone identity. You can read more information about SINs in the official specification.

This SIN can be shared openly with the world, as the corresponding private key is kept on the clientside and never transmitted over the wire.

How BitAuth Works

The general flow of using BitAuth to authenticate a request is as follows.

  • Key generation: generate a keypair using ECDSA, on the secp256k1 curve.
  • SIN construction: with public key k1, concatenate the SIN version byte and hashed public key, then encode this in the base58check format.
  • SIN sharing: register your SIN with the remote service using a mechanism of your choosing—generally, this takes place with client registration.
  • Submitting Requests: requests are made over HTTP, with the x-signature header:
    • generate a unique, higher-than-previous nonce
    • include nonce in the body of your request
    • concatenate and sign URI + BODY with your private key, and provide it in x-signature

The server will now verify the signature against the public key you've provided and the SIN you've shared previously, confirm that the signed nonce is greater than this SIN's previous nonces (preventing replay attacks), and subsequently authenticate the request.

Replacing Usernames and Passwords

The BitAuth authentication scheme is directly compatible with the familiar username (or email) and password mechanic. In fact, when storing private keys, we recommend encrypting them with a passphrase, so even these are resilient to attack or compromise. The primary difference with BitAuth's method is that the password is never sent over the wire, in any format.

Using this mechanism, you can still provide the user with the experience of entering a username and a password, but locally use that password to decrypt the private key and subsequently use it to sign the request.

Advantages over other authentication mechanisms

Gone are the days when a single hack can compromise an entire customerbase's credentials—with BitAuth, passwords are only used locally, to encrypt the private key.

  • Only a compromise of the client machine can endanger the system's security.
  • Because the private key is never revealed to the server, it does not need to be exchanged between the server and client over a side channel like in HMAC.
  • Easy to implement wherever the Bitcoin protocol is implemented.
  • Decoupled from Bitcoin addresses, allowing for a more explicit separation from financial transactions and allowing for greater privacy.
  • Identity becomes portable — the same identity can be used on multiple services, letting you take your identity with you.

We believe that widespread adoption of BitAuth (or a similar scheme) will enhance the security of the web, and look forward to seeing further services adopting this mechanism.

Drop-In Libraries

Since BitAuth is built using the same cryptography as Bitcoin, it should be easy to implement in any system that already has Bitcoin support as the algorithms we use are the same. But to make it even easier, we're making BitAuth tools available in some common forms:

Open Source, Fully Auditable, and Free (as in Freedom)

We're releasing BitAuth on GitHub, because we believe that the only way software can be secure is if it is open source. If you find a security problem, please reach out to us at, but otherwise please report issues in our issue tracker. Pull requests, of course, are also welcome.

We'd like to collaborate with anyone implementing BitAuth in their services, so feel free to stop by the BitAuth chat.