Open florian-obradovic opened 2 days ago
Setup keys should be set to expire, or limit the number of usage.
If you're using setup keys without any limits you should verify your rules are "very notrusty"
I generally agree, but there are use cases where you need keys with longer expiration dates (docker / kubernetes deployments, etc...).
On the other hand this discussing misses the point. Unencrypted credentials in the database, especially high privileged credentials without second factor).
There is no good reason, why we should keep storing them unencrypted. No matter what short expiration time you choose.
hi @florian-obradovic, thank you for opening this issue. Like previously discussed on Slack, we are currently working on the migration for these secrets, in the next few weeks, this should remove this security impact you mention here.
Thanks a lot!
Describe the problem
The setup keys are stored unencrypted in the database (at least for sqlite3) which is very bad. If the backend or storage (Cloud & Selfhosted) gets compromised, anyone can use the setup keys to provision new peers.
To Reproduce
sudo sqlite3 /var/lib/docker/volumes/artifacts_netbird-mgmt/_data/store.db
Adjust the path to your docker volumeselect * from setup_keys;
Expected behavior Store the setup keys encrypted by using at least salted hashes (More infos: https://www.vaadata.com/blog/how-to-securely-store-passwords-in-database/)
Are you using NetBird Cloud?
Selfhsoted
NetBird version 0.30.2