Choose direction for password manager #23

New Issue

eising · 2025-06-03T07:12:24Z

eising commented

2025-06-03 07:12:24 +00:00

Considering the changes required to implement the ssh based management ideas, the handling passwords/secrets can go in several directions:

Double-encryption

When a user submits a new secret via SSH, it should be encrypted with that users key.

However, a shared key can exist between the backend and the admin interface.

The backend can then provide both keys to the sshd server, so it can encrypt it with both.
The admin server can then poll for entries in a table, fetch it encrypted value, and store it decrypted in the password manager.

The admin server should make sure to empty the queue.

This could be implemented via mqtt to ensure that it lives as shortly as possible in this format.

The ability to disable the password storage completely.

This one feels mixed. The current use case feels quite streamlined, but maybe not necessarily obvious.

The password manager could be an optional module, making the admin interface an optional interface entirely.

The ability to set up the password manager in different ways.

Currently the password storage is a bit crude, and also a bit fragile. It is set up on initial startup of the admin interface, with a key that is stored encrypted in the database, using ssh rsa as encryption.

The whole thing re-uses the same secret key that is used elsewhere, and this may not be best practice.

I could leave this up to the user. Prompting the user for a password on setup, and re-implementing the old idea I had of unlocking it on demand.

I could also prompt the user for a one-time password that I store in the same way.

The choices could be made up to the user, either on demand via the frontend/api, or via a configuration format.

Considering the changes required to implement the ssh based management ideas, the handling passwords/secrets can go in several directions: ### Double-encryption When a user submits a new secret via SSH, it should be encrypted with that users key. However, a shared key can exist between the backend and the admin interface. The backend can then provide both keys to the sshd server, so it can encrypt it with both. The admin server can then poll for entries in a table, fetch it encrypted value, and store it decrypted in the password manager. The admin server should make sure to empty the queue. This could be implemented via mqtt to ensure that it lives as shortly as possible in this format. ### The ability to disable the password storage completely. This one feels mixed. The current use case feels quite streamlined, but maybe not necessarily obvious. The password manager could be an optional module, making the admin interface an optional interface entirely. ### The ability to set up the password manager in different ways. Currently the password storage is a bit crude, and also a bit fragile. It is set up on initial startup of the admin interface, with a key that is stored encrypted in the database, using ssh rsa as encryption. The whole thing re-uses the same secret key that is used elsewhere, and this may not be best practice. I could leave this up to the user. Prompting the user for a password on setup, and re-implementing the old idea I had of unlocking it on demand. I could also prompt the user for a one-time password that I store in the same way. The choices could be made up to the user, either on demand via the frontend/api, or via a configuration format.

eising added the

labels 2025-06-03 07:12:24 +00:00

eising added this to the Development and Testing project 2025-06-03 07:12:24 +00:00

Sign in to join this conversation.