One-off encryption?

We use several systems and our app is the glue + the persistent layer keeping track of it all. Your point is valid and well understood – but happily not critical in this case.

Worst case scenario is that one of those external systems will know we’re sending some numbers back to our webhook. And those numbers expire and are unusable minutes later.

One caveat: In our case it was important that the same db record (a user) was not mapped to the same hash/encrypted text, because that would allow the external system to essentially track activity. If that’s no concern in your use case, some random bytes in your database are your best bet, indeed!

Nope, a very plain Plug project so Phoenix is off limits for now.

That… I haven’t thought of that. That actually might be the best solution.

Thanks for showing me that I am dumb today. I needed it.

If you already use Phoenix, you can use Phoenix.Token.encrypt/4 to encrypt a token with a given secret.

Why not just generate a random string, store it in the database and send that ? (or a hash like @derek-zhou said.)

So even if someone sniffs it, it is meaningless. Is there a fundamental problem to send a value that is also stored in the database, it the value is just a one-time key for fetching?

We’re no crypto experts either, so I feel obligated to reference this SO post the chosen cypher and padding seemed a good fit for our use-case where we’re encrypting a user ID that goes through a 3rd-party service and comes back via webhook as well.

I get what you are saying. We’re not expecting serious attacks. I just don’t want that integer ID flying around naked on the net (even though it goes through HTTPS).

I still might go with hashids btw. I’ll take an hour or so Soon™ to evaluate both suggested approaches. Your has the advantage of being super simple while offering adequate protection.

for inputs that lack entropy such as short integers, any encryption is not going to survive serious crpto attack. A breakable integer id and a secure hash of the original and un-transmitted payload still offer quite some protection.

EDIT: On a second thought, you can just send the secure hash, and use the hash as the primary key of your table to fetch the original payload. hashids is not needed here.

I see. But this seems to become a homegrown cryptography solution, which is something I want to avoid.