Scramble user apiKey in database

[ll4strw]

UserApiKey.apiKey entries in db should be possibly scrambled.

[mKowalski256]

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.

[ll4strw]

Fair enough. I do understand the motivations behind this design choice. My concerns are mainly the following

• Should the db get compromised, the platform would be compromised. API keys let a bearer perform operations, on behalf of a user, that normally would have required MFA - at least in our case.
• Privacy. sysadmins would have access to all API keys and impersonate users outside the impersonations scheme provided by the GUI app itself.

[mKowalski256]

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.

[mKowalski256]

I see that outside of 'operate as' scenario there is an API endpoint allowing sysadmin to retrieve API keys. The issue #73 will cover both cases.

[ll4strw]

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.

[mKowalski256]

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.

[rs-nicof]

I can confirm this has been handled by the JIRA ticket https://researchspace.atlassian.net/browse/RSDEV-310 and will be released in the RSpace version 1.103.

@mKowalski256 not sure if this github issue needs to be closed now

[mKowalski256]

This change is merged and part of 2.3.0 open-source release (and in 1.103.0 supported release) - API keys are now stored hashed with SHA256, and only visible to the user immediately after creation.