Open ll4strw opened 1 month ago
Yes that's a fair request, although in current design we do allow user to view/copy their API key anytime after its creation, which means most secure scrambling mechanism based on hashes would not work in this case. We could encrypt/decrypt the keys based on a secret stored outside database, but that would only be a partial improvement.
We encourage users to revoke/regenerate their API keys on the schedule they believe is reasonable.
Fair enough. I do understand the motivations behind this design choice. My concerns are mainly the following
Privacy. sysadmins would have access to all API keys and impersonate users outside the impersonations scheme provided by the GUI app itself
Hmm, I've checked that and I believe you mean that 'operate as' functionality currently let sysadmin see the API key of the user? That's a bug/oversight, the API key shouldn't be displayed for sysadmin, I'll raise it as a separate issue.
I see that outside of 'operate as' scenario there is an API endpoint allowing sysadmin to retrieve API keys. The issue https://github.com/rspace-os/rspace-web/issues/73 will cover both cases.
Thanks for quickly completing #73. Could we open another issue just to do some brainstorming on how to avoid storing cleartext API keys in the db? Cheers, L.
Hi Leonardo, after internal discussion we've prioritized this ticket, and we're targeting the fix for 2.3/1.103 release (end of September 2024). We plan to go with solution where user see the API key only once, at the moment of creation, after which RSpace stores just a hashed value of the key.
UserApiKey.apiKey entries in db should be possibly scrambled.