How to encrypt the id so that after receiving this encoded id it would be possible to decrypt it and get the id?

Question

PHP

Hello.
The question, in my opinion, is very simple. But something is missing for me - to answer it myself.
Given: my service distributes a widget (iframe) to the sites registered in the service. To do this, you need to place an iframe on the site. In order to be able to identify the site and determine whether it is registered in my service or not, the iframe contains the id of the specific registered site.
But I don't want to pass a "naked" id.
Question: how can I encrypt the id so that, having received this encoded id, I could decrypt it and get the id. Do I need to use some tricky function for this, or is everything much simpler?

Answer 1

Convert to base64 for example.
Use the tricky feature.
Store keys id = hash in the database.
Any option will do.

Answer 2

In my opinion, you just need to compare the request referer with the registered domain names of the sites in your service. Nobody bothers to copy the encrypted id and paste it on another site with the same success. The "call" of the frame url is still initiated by ordinary users from the browser, they have no reason to engage in forgery of the referrer. For those paranoids who have referrer transmission disabled, just don't block the widget when the referrer is empty.
To confirm the url is unchanged in the abstract case, it is better to use a signature - for example url?id=123&hash=123456789abcdef, where hash=md5($id.$secret_key); Even nginx
has the ability to check such signatures

Answer 3

Do not encrypt in any way, just generate a separate key and associate it with a specific site. It's stupid to do mega encryption if you can separately create a key.

Answer 4

We take id. We consider its hash, for example, md5. For brevity, you can cut off half. We take the secret key from the config. Encrypt with AES(key, "hash|id"). This is the encrypted id. Instead of AES, you can choose another block (not stream!) cipher.
When transferring the encrypted id, we encrypt it using the secret key - unAES(key, secret_id). Split into hash|id. If it doesn't break, we got garbage, we throw an exception. We consider md5 (id), if we got a hash, then everything is OK, if not, garbage came, we throw an exception.

Answer 5

Habr pleases.
Just byte-by-byte, compose and serve.
Are you familiar with short urls?
Like goo.gl/OkoJ67d
OkoJ67 - very figuratively speaking - this is byte-by-byte folded data, which, when unfolded, has something like windows.com

Answer 6

You describe the authentication task with a single message without key disclosure.
(Otherwise, anyone who peeps on the value transmitted by another site - no matter naked or encrypted - will simply repeat it in his frame and be authorized ("replay attack")).
So this problem is solved by encrypting or hashing some known to everyone, but changing (this is important!) block of information with some secret key that you exchanged with a remote subscriber earlier.
Most often, either the current time is encrypted with some degree of error (for example, a minute or 30 seconds) or an ever-increasing counter (which is more difficult to implement, since it has to be supported on both the server and client sides).
Bank OTP tokens work on this principle.