search

poetapp / frost-api

Po.et's API Layer
https://api.poetnetwork.net
MIT License
24 stars 5 forks source link

Remove Vault #988

Open lautarodragan opened 5 years ago

lautarodragan commented 5 years ago

Supersedes https://github.com/poetapp/frost-api/issues/693, https://github.com/poetapp/frost-api/issues/908, https://github.com/poetapp/frost-api/issues/943 and https://github.com/poetapp/frost-api/issues/987

We currently have two uses for Vault:

Private Key Encryption

Implemented in https://github.com/poetapp/frost-api/pull/990

We can replace this with either NodeJS' crypto or a library, such as openpgpjs.

Currently

With Vault, we are using the Transit Secrets Engine, which supports these key types.

We are probably currently using aes256-gcm96. (TBC cc @WesleyCharlesBlake).

Migration

Implemented in https://github.com/poetapp/frost-api/pull/1001

We'll need to migrate the current private keys decrypting all private keys with Vault and re-encrypting with [crypto library].

NodeJS Crypto Module

NodeJS' crypto module is just a wrapper for OpenSSL. What encryption/decryption algorithms are available depends on the version of openssl.

The list of algorithms supported by openssl can be obtained with openssl list -cipher-algorithms.

Alpine Linux comes without openssl but it can be added:

/usr/src/app # apk add openssl
fetch http://dl-cdn.alpinelinux.org/alpine/v3.8/main/x86_64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/v3.8/community/x86_64/APKINDEX.tar.gz
(1/3) Installing libcrypto1.0 (1.0.2r-r0)
(2/3) Installing libssl1.0 (1.0.2r-r0)
(3/3) Installing openssl (1.0.2r-r0)
Executing busybox-1.28.4-r2.trigger
OK: 9 MiB in 18 packages
/usr/src/app # openssl version
OpenSSL 1.0.2r  26 Feb 2019

OpenPGPJS

This is a pure JavaScript implementation of OpenPGP, maintained by ProtonMail.

See example.

It uses NodeJS Crypto Module under the hood, but falls back to using asm.js implementations of AES, SHA-1, and SHA-256 if unavailable.

JWTs

We currenly have two different uses for the Vault Tokens we associate with JWTs:

The former can be achieved with any database as easily. Storing the client_token in Vault is really no different to a uuid in MongoDB.

The latter can be done with pure JWT: store the purpose inside it, and that's it. That's the whole purpose of JWTs to begin with. One less request to a database / external system.

Migration

JWTs associated with a Vault token will become invalid after the removal of Vault. We'll need to support both Vault and non-Vault authentication in parallel for a while and let users know they will need to re-generate their API Keys.

JWTs will still need to have some value associated with an entry in the database so they can be revoked. (Either black or white listing, the latter should scale better for our use case).

Note

The switch to using uuids over email for user identification was never completed for this same reason, enforcing it requires users to manually create new API Keys. This would be a good opportunity to release both changes and only ask users once.

JWT Secret

We're currently using HMAC to sign the JWTs. We should also take this opportunity to switch to a public/private key pair, which has some benefits over HMAC; namely, allowing anyone to verify that a JWT was really signed by Frost API with the public key.

WesleyCharlesBlake commented 5 years ago

JWT Secret We're currently using HMAC to sign the JWTs. We should also take this opportunity to switch to a public/private key pair, which has some benefits over HMAC; namely, allowing anyone to verify that a JWT was really signed by Frost API with the public key.

We can do this. How would you want to go about creating PKI? Manual self signed certs? AWS KMS?