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 accessible at any time in the future from the server from any authenticated client.
As such, the current plans for authentication are:
On first use, a private and public key keypair is generated on the client.
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.
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.)
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 for the REST and WebSocket APIs will use JWT with publickey authentication.
If the client doesn’t have a copy of the private key, it requests it from the server.
The client decrypts the private key using the symmetric key generated from the owner’s strong password.
It uses the decrypted private key to authenticate using public key authentication (see below).
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
An older article (2013) by Alex Maccaw on end-to-end encryption in web apps.
Note: we should keep in mind how Mastodon uses public-key authentication for message verification (see https://web-payments.org/vocabs/security#publicKey)
For a general guide on application of cryptography for developers, see the book Serious Cryptography: A Practical Introduction to Modern Encryption
passport-publickey: “Passport strategy for authenticating using a public/private key pair to sign a nonce challenge.”
passport-keyverify: “Passport strategy for authenticating using a public/private key pair to sign a nonce challenge.”
PiPo: “A secure chat client with client side encryption written in NodeJS”
TripleSec: “TripleSec is a simple, triple-paranoid, symmetric encryption library for a whole bunch of languages. It encrypts data with Salsa 20, AES, and Twofish, so that a someday compromise of one or two of the ciphers will not expose the secret.”