Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
Why are you encrypting the key again to match in dB? Have the user sent the encrypted one and you can just match for same value...
If you encrypt it, it means the raw key is sent in the request, which is never a good idea
You never store the plaintext version, just the resulting hash and the salt... That way you can send salt to user, in theory client, they do the encryption using their salt and send encrypted key to you... -
@joykill sounds somehow reasonable and simple, thanks for the input! I will overthink if that might be a solution in our use case, or at least give a good pointer to the engineers working on that. only one downside: Client must know salt, key in cleartext and the hashing algorithm. means we cannot change easily the algo in the future (B2B scenario).
and yes storing cleartext token in backend is never a good idea, thats what we try to avoid really badly!
How should I store API keys in the backend database in a secure manner? I can't fucking getting my head around and internet is somehow not really a help to find a secure and fast way to store API keys.
It is a requirement that the key identifies the corresponding user in way. We tried to do it with bcrypt and different salts, but that means very poor performance when we have to encrypt each incoming request to check what user corresponds to the cleartext key. My best guess was to use sha512 and a configurable salt on application server side (one for all users to at least have an unknown part in database).
rant
secure api key storage