Rocket
Rocket copied to clipboard
Expose functionality underlying private cookies.
Feature Requests
Expose new API: encrypt_private(&str) -> String
and decrypt_private(&str) -> Result<String>
or something like it, that would use the same scheme as private cookies do.
Why you believe this feature is necessary.
It's not necessary, but it would be useful to be able to use the same encryption that private cookies use on arbitrary data/strings. This way encrypted values can be embedded eg. in rendered forms to pass authenticated, unforgeable data.
A convincing use-case for this feature.
I'd like to embed an URL and some control data in one of my forms, to control some flow after form submission, and not have to worry about all the possible attack vectors. It would greatly simplify everything if I could trust that data was not tampered with. I can't put it in cookies since it's page, and not session, related.
Why this feature can't or shouldn't exist outside of Rocket.
Obviously, it can be done manually / through another library, but since Rocket already takes care of managing the encryption key, it would be much easier to just reuse it.
This feature would be great to have. I'm implementing some OAuth API, and the access token should contain some information without requiring to re-check the database. This information should be encrypted in the token with a secret key, so this feature would be really useful. It can be as simple as passing a &[u8]
and returning a &[u8]
with the encrypted data.
I would like to use such a feature to embed a link into a confirmation email I send to the user, so that when the user clicks that link, I can verify that the payload has not been tampered with. Right now, I have to ask admins to generate and configure two secret keys (one for Rocket and one specifically for my app for the email links), which seems rather unnecessary.
Feature request: Expose the secret key so that we can use argon2 password hashing in a more secure mode.
I would also like this feature added, as it would allow me to decrypt private cookies I recieved in a LocalResponse while testing, to check, if it contains the right value.
@morbatex You can already do that today by asking the Cookies
jar to decrypt the cookie for you.
I don't think that's currently true of LocalResponse
-- https://github.com/SergioBenitez/Rocket/issues/948#issuecomment-472614363
I don't think that's currently true of
LocalResponse
-- #948 (comment)
As of https://github.com/SergioBenitez/Rocket/commit/52320020bc26387b96a0126a0d49821ad3125e7d, reality has reached my previous statement.
I've also run into this on 0.5. I want to generate an URL with an encrypted query parameter for which the existing cookie secret would be the perfect fit. I tried to work around it, but so far I did not find a solution that does not involved my own copy of a secret key and encryption routine:
- Rocket does not have a API as proposed here, so I can not encrypt data directly
- The secret data key in the Config struct does not seem to have a way to actually get the secret data as input for a custom encryption system - all APIs seem to hide the key data entirely outside of rockets crate boundary.
- Misusing an private Cookie does not seem to work either:
- I can not construct a CookieJar that uses rockets secret from scratch
- Though I can clone an existing CookieJar to become independent from the request state
- But there seems to be no way to turn "pending" cookie changes into the actual encrypted values manually anyway.
- The only approach that seems like it could work in theory is to construct a local Rocket Client and let the whole request workflow run to get encrypted cookie data from LocalResponse/LocalRequest. I'm not going to do that though :D
Would there be interest for a PR that adds a API as proposed here?
Would there be interest for a PR that adds a API as proposed here?
Absolutely. I'd love that. To make things easier, please propose a concrete api and implementation idea. That way we can get the hard parts out of the way first. Given this is security critical, we need to make sure this is correct.