Add new content: authentication, security, radar

parent 6a0e525b
+++
title = "Security"
weight = "20"
+++
Indienet apps based on Indienet Engine are hosted on a server and accessed through clients. The default client is a web client that is, itself, served by the server.
Depending on how the app is installed and hosted, different security threats will exist.
In order to be entirely sure of the security of the end-to-end encryption of private messages, you would have to:
1. Install the app from source yourself (to verify that it was not tampered with)
2. Host the server on hardware that you have physical control over (to verify that it is not tempered with by the third-party host)
In such a scenario, you can be reasonably certain that the client that is being served is the one that you intend to be served.
This, however, is a negligible use case for Indienet apps, which will mostly be installed, hosted, and updated by third-party hosts.
Just like any web app, this means that we must trust the host not to:
1. Add a back door to the source and serve a malicious client (with which they could, for example, capture your password, etc.)
2. Not to update to a malicious version sometime in the future (a web server could serve you a different client on each connection)
While these issues are blatantly apparent for web clients, they are also faced by native apps today in a world of App Stores and automatic updates.
## Resources
* [End-To-End Web Crypto: A Broken Security Model](https://www.indolering.com/e2e-web-crypto/)
* [What’s wrong with in-browser cryptography?](https://tonyarcieri.com/whats-wrong-with-webcrypto)
* [A Few Thoughts on Cryptographic Engineering](https://blog.cryptographyengineering.com/2013/06/17/how-to-backdoor-encryption-app/)
......@@ -3,6 +3,50 @@ title = "Authentication"
weight = "30"
+++
## Publickey authentication
The requirements for authentication are affected by the following requirements and aspects of the Indienet:
* Indienet sites/apps are personal sites, 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 [security](/engine/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 (e.g., via [Triplesec]( https://keybase.io/triplesec/)) using a strong password (we will recommend the use of a password manager) and sent to the server, along with the public key.
3. A copy of the private key is kept on the client but can 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 and is used by other clients to encrypt private messages for the owner of the instance.
## 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 owner’s strong password.
3. It uses the decrypted private key to authenticate using public key authentication (see below).
## Public Key Authentication
### Resources
* [feathers-authentication-publickey](https://github.com/amaurymartiny/feathers-authentication-publickey): “Public Key authentication strategy for feathers-authentication using Passport” ([Example.](https://github.com/amaurymartiny/feathers-authentication-publickey/tree/master/example))
* [passport-publickey](https://github.com/timfpark/passport-publickey): “Passport strategy for authenticating using a public/private key pair to sign a nonce challenge.”
* [passport-keyverify](https://github.com/phutchins/passport-keyverify): “Passport strategy for authenticating using a public/private key pair to sign a nonce challenge.”
* [PiPo](https://github.com/phutchins/pipo): “A secure chat client with client side encryption written in NodeJS”
* [Asymmetric Public / Private Key Encryption (RSA) in Node.js](https://coolaj86.com/articles/asymmetric-public--private-key-encryption-in-node-js/) “” ([Code.](https://git.daplie.com/coolaj86/examples-rsa-keypairs))
* [TripleSec](https://keybase.io/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.”
* [JWT using RSA public/private key pairs (video)](https://www.youtube.com/watch?v=F0HLIe3kNvM)
## JWT
+++
title = "Radar"
weight = "30"
+++
Related materials, conversations, etc., from across the web. Stuff that we’re aware of, thinking about, keeping an eye on, or possibly considering.
## Matrix integration
Discussion on the Mastodon issue tracker about integrating [Matrix](https://matrix.org).
https://github.com/tootsuite/mastodon/issues/311
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment