-
Notifications
You must be signed in to change notification settings - Fork 5
Description
Supersedes #693, #908, #943 and #987
We currently have two uses for Vault:
- Encryption of private keys
- Vault Tokens associated with our JWTs
Private Key Encryption
Implemented in #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 #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:
- Ability to revoke tokens
- Authorization Level / Permissions
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.