Hacker News Reader

Comment by pcj-github | Hacker News Reader

Worth mentioning: https://docs.nango.dev/nango-deploy/oss-limitations

To keep the setup of the Nango open source version simple we have made some choices that may not be ideal for production. Please take them into consideration before using it in production:

The database is bundled in the docker container with transient storage. This means that updating the Docker image causes configs/credentials loss. We recommend that you connect Nango to a production DB that lives outside the docker setup to mitigate this.

Credentials are not encrypted at rest and stored in plain text

No authentication by default

No SSL setup by default

The setup is not optimized for scaling

Updating the provider templates requires an update of the docker containers

View on HN

> Credentials are not encrypted at rest and stored in plain text

LOL. Advertising something as a security product and doing this is absolutely ridiculous.

Well, you _could_ encrypt the tokens but you can't hash them like a password so they have to be stored in some format in their entirety.

However, it seems reasonable to infer they are referring to storage in the DB itself. How would you suggest they encrypt it securely at rest for an out-of-the-box "setup and go" scenario?

I will note that a lot of the existing "plugin" OAuth type providers for popular web frameworks don't encrypt user tokens in the DB by default either.

You can likely encrypt the tokens symmetrically by a key on the server (can also have that key be stored in a secret manager and retrieved for the purposes of the encryption/decryption only); obv you have to make sure the key doesn't leak but it's significantly better than storing this type of data unencrypted in DB.

Interesting point on existing providers not encrypting user tokens in the DB by default tho - wouldn't expect that hmmm

What I'm doing is have a _separate_ encryption key for _each_ OAuth provider on the server, encrypt with that and save it in a HTTPOnly browser cookie. This way if the key gets stolen from the server, the attacker doesn't even have any user OAuth tokens. If the cookies are stolen from the user's browser, the attacker can't do anything with it. If one user's cookie is stolen AND the encryption key is stolen, only one user is affected. As the cookie is HTTPOnly, there is no XSS surface, the client need to communicate with the server to be able to API requests to the OAuth provider.

Reply on news.ycombinator.com