Authentication

The requirements for authentication are affected by the following requirements and aspects of the Indienet:

  • Indie sites/apps are federated personal web sites/apps, there is only a single owner that uses each site/app. (We do not have the concept of users and we do not need usernames.)

  • Private messages must be end-to-end encrypted (see /site/engine/security and /other/spikes/security)

  • Private messages must be accessible at any time in the future from the server from any authenticated client.

As such, the current plans for authentication are:

Key Generation And Storage

  1. On first use, a private and public key keypair is generated on the client.

  2. The private key is symmetrically encrypted via a key generated using a strong password (we will recommend the use of a password manager). The encrypted private key is then sent to the server, along with the public key.

  3. An unencrypted copy of the private key is kept on the client – e.g., as an unextractable key via the WebCrypto API – (so the site owner doesn’t have to keep entering their password) but the encrypted private key can also be re-requested from the server at any time and from any client. (The private key is useless unless it is decrypted with the strong password set in Step 2.)

  4. The public key is also served at a well-known location on the server and is used by other clients to encrypt private messages for the owner of the instance.

(We are currently spiking this out. See /other/spikes/security)

Client authentication

Client authentication for the REST and WebSocket APIs will use JWT with publickey authentication.

Private Key Retrieval

  1. If the client doesn’t have a copy of the private key, it requests it from the server.

  2. The client decrypts the private key using the symmetric key generated from the owner’s strong password.

  3. It uses the decrypted private key to authenticate using public key authentication (see below).

Future thoughts:

  • Would using a Service Worker to handle cryptographic functions in the browser have security advantages? (Keep an eye on browser compatibility – once all evergreen browsers support this, let’s take a look.)

  • ssb-horcrux: An interesting apporach to key recovery with a Harry Potter twist (“Split your key into some number of parts, give those to trusted friends, and if your computer ever dies, you can re-create your private key.”) Also see: Shamir’s Secret Sharing

General resources

Public Key Authentication

Note: we should keep in mind how Mastodon uses public-key authentication for message verification (see https://web-payments.org/vocabs/security#publicKey)

Resources

JWT

Author: Aral Balkan Last modified: 16/02/2018 Words: ~700 Reading time: 4 min