I'd recommend switching away from Rocket if you can. It is not very actively maintained and Axum has become the better choice.
Thanks for the update, I wrote using rocket a few years ago so I figured everyone was still using that!
This is more of a cryptography question than a Rust question, but typically you'll use a so-called key diversification function (KDF) for this. See: https://en.wikipedia.org/wiki/Key_derivation_function (another term for the same thing, with slightly different connotations).
For an API key, you might have a user ID sent in the clear, and a secret key SK on the server. The KDF you would use would be something like HMAC-SHA256 truncated to 128 bits. Then the API key would be KDF(SK, ID). You will want a way to invalidate ID's and issue new ones so the person can cycle or change their API key. You could add a parameter P to the UID for this purpose, but again you have to be able to invalidate it.
You want to be very careful with SK on the server side. In financial apps (where the key can steal real money) you'd encapsulate it in a hardware security module (HSM). For less high-value apps you could still wrap it in its own HSM-like interface in its own process, that the rest of the app queries through a local socket. The idea is that the KDF process has a smaller attack surface than the big complicated web app. It can also implement throttling (limit the number of queries per second) in case a compromise app starts trying to spew API keys, and so on.
Added: your idea of just generating keys randomly and storing them in the database is also ok, but again you have to pay some attention to security, dealing with the possibility of the key table spilling, etc.
Sweet, thanks for the link! I didn't realize it was that complicated.
Do you know if there's a crate or library that already implements this functionality that I can pull from?
I didn't mean to make it sound complicated! What is the application if you don't mind my asking? Basically the paranoia level you need increases with the threat level ;). I'm afraid I don't know anything about the crate world. I'm sure there is an HMAC function in some Rust library though.
Why is the secret key on the server side? Is this for the server to trust the client, or the client to trust the server?
It's so the server can generate any of the API keys as needed, instead of having to store them all. This matters more when you want to do the authentication on a low resource device like an HSM, or otherwise keep the authentication process away from the main server app, to lower the attack surface. Again, depending on the application, it might not be worth it.
If you are looking to do something like Github's Personal Access Tokens (PAT) then it is easiest to just think about it like a password:
Storing the hash of the token, like you do with passwords, is a good practice in case your db is ever compromised as it wont leave the tokens accessible and reusable without a lot of effort.
Don't forget to add some salt to that hash.
why would you need to salt long random strings?
also if you salt them you have to have an id too so you can look up who's api key it is. otherwise you can just look up the key hash to get everything
why would you need to salt long random strings?
also if you salt them you have to have an id too so you can look up who's api key it is. otherwise you can just look up the key hash to get everything
That depends on scale. For our IOT device, we just had a private key on the device and gave the customer an encrypted packet that had their privileges spelled out, and set a field on their user account appropriately. That wouldn't be secure at scale, but it worked really well for our B2B app.
If I were doing something at scale, I'd follow suggestions from others here.
I mean, that sounds sorta like JWTs which are used commonly enough for this type of thing
I guess. Our use case was a bit different in that it carried which features they had access to, not just that they had some access. You could probably do that with a JWT as well, but we just issued them an encrypted upgrade file that matched the serial of their device and granted all usersln that device access to the feature.
That was simple enough for us.
Welcome to the Rust community! This is a place to discuss about the Rust programming language.
Credits