How to properly mask the _id field when passing it to the UI?

Question

MongoDB

If two documents are created in the same database with a time interval of less than a second, then the _id of the last one is an increment of the previous one, which differs only in the last character:
ObjectId("585f695e45a2c61b5c7ca452")
ObjectId("585f695e45a2c61b5c7ca453")
i.e. knowing the _id of the last one, we can "almost exactly" know the _id of the document that was created before it.
Let's say the organization of links on my site is a call to a document through an explicit indication of _id (in the address bar), but I would not want a person, just by looking at the request, to be able to find out and access documents from this _id range (authorization is not taken into account).
The first thing that comes to mind is to assign your _id as a random one.
The second is to make a hash on _id, then the meaning of _id disappears, and I would like to leave it for connections, because, as far as I understand, service information is encrypted in it, which is needed when distributing the database (for the future).
Is there a built-in method in mongo that comes up with _id in a more interesting way, or can someone suggest a different approach algorithm in organizing _id, without unnecessary checks and requests?

Answer 1

Let's say the organization of links on my site is a call to a document through an explicit indication of _id (in the address bar), but I would not want a person, just by looking at the request, to be able to find out and access documents from this _id range (authorization is not taken into account).

Isn't it better then, for these purposes, to use not an ID, but some value other than ID, generated in a different way, with the index set to it (for performance similar to that which will be when using ID).
I'm not a great monga expert, but in my opinion, the idea is pretty shitty, in general.
I would still leave ID alone and would not try to make a "gun out of a stick". Add a new field as the URL of the document and write the hashed ID there, I don't think that increasing the size of the document by 20-40 bytes of data can lead to a total crash of the system (it would be strange at least). Well, or, if you really want both ... both, use the "reversible encryption" mechanism, i.e. hashing is essentially "one-way encryption" (to put it simply), a hash cannot be turned back into data. Use reversible encryption like this . The idea of ​​reversible encryption can be developed and come up with some additional keys or salt, if you really want to "encrypt it really scary"...
PS The library for encryption in the example is the first one that came up in the search. Judging by the tags, you use Node.JS, I'm sure there should be plenty of such libraries and algorithms for it.

Answer 2

"almost exactly" to know

almost exactly hack, almost exactly see secret secrets.
For those who want to know some secret links, the last thing that comes to their mind is to sort through the numbers in such a line, because it is initially clear that this is a very long set of alphanumerics that cannot be picked up just like that.
Only if this is a stoned schoolboy who does not understand anything in life at all.
Besides that to receive "almost identical" records it is necessary to add it is direct in general simultaneously.
Further than 1 ID, the neighboring one is unlikely to "get over" with a brute.
In short, it's all Elusive Joe.
And if you need security and protection from prying eyes - you need to check the authorization.

Answer 3

> could recognize and access documents from this _id range (authorization is not taken into account)
That's where the problem is, not in IDs. Security by obscurity doesn't work. Set up a rights check and at least pass IDs with integrators.

Answer 4

The apogeios there is actually timestamp based, but that's just so the admins don't say they didn't answer the question.
On your question recently deleted about 20k, there are ideas, but such things are not publicly discussed.
If the intentions are serious, write to Skype FenixSumi, we will discuss it, if the theoretical reflection, then you yourself understand.

Answer 5

They suggested the answer in one of the chats in the Telegram.
In general, on the client side, apparently, it is not always possible to check for the fields being filled in, in other words, their browser spat on required and such emails with empty content periodically occur.
It is necessary to perform checks on the server side, in the context of my task, the following code came up to me:

$num = 0;
foreach ($_POST as $key => $value) {
  if($value != '' && $value != ' '){
    $num++;
  }
}
if($num >= 4){ //если в массиве есть значения 4-х и более полей - производим отправку
  mail($admin_email, adopt($form_subject), $message, $headers );
}

Answer 6

Try to enter mail from Yandex or Google