3
We were talking about database security.
Came the question: worth encrypting Ids coming from the database to the frontend?
E.g.: I click on a client from a list where the link goes http://localhost/get_posts/id_encrypted return to me all the posts of this.
Anyway, an application would be safer using the encrypted Ids?
4
I think you have to define what your concerns are, so you know whether it’s worth it or not.
There are use cases and cases. Youtube is an example, it does not use sequential identifiers. That is: a video will be youtube.com/1 another will be youtube.com/821, instead of /2.
Now, why does Youtube generate non-sequential identifiers? To prevent you from accessing "unlisted" videos, after all if they were sequential you could access the videos with /3, /4, /5 and, I believe, not to conflict with several simultaneous submissions...
PS: Youtube, like Instagram, doesn’t use numbers, but it codes for Base64. The encoding is NOT about security, the advantage is that whether it is 1 or 18446744073709551614, it will be represented by the same amount of characters and will use less than using numbers, since the two numbers can be stored in 8 bytes.
Exposing the ID in general is not a problem, Facebook and Instagram, exposes the user ID and is sequential as well. Instagram’s first photo is the ID: 2 and the first of Facebook is ID: 4, but is that a problem?! It’s okay to know that information.
PS: Note, private posts on Instagram have another identifier, which is longer and does not appear to be sequential.
If it is, my advice would be: create another column like id_random, and use it as a id. We won’t need anything related to the encryption, except a secure random generator, and that’s it. But, if you want each user to see a different ID, then derive it using some KDF (an HMAC/Keyed-Hash) for a user-specific key or encryption using some algorithm that guarantees integrity (AES-GCM, Chacha20poly1305, Salsa20poly1305...) or use some "non-ccriptographic obscurator to your desire", thus the identifier of a user (or a "something") will vary depending on who is currently connected. Now where might that be useful? I don’t know.
2
More or less, if the security of your application consists in hiding from the user what it can move, it will be as safe as now, the difference is that the ID will be "messy"
It may even be harder to find another resource if you’re using sequential ids, as you just add or decrease to access the next or previous one. But this does not give a lot of security, an attacker can be making mass requisitions with random ids and end up finding anyway
If the user is not allowed to access a particular resource, you should not only hide, but do a validation before showing and returning an error
Browser other questions tagged php mysql laravel mysqli
You are not signed in. Login or sign up in order to post.
best use
.htaccessthan scramble ids.– Augusto Vasques
I’ve seen this discussion here on the site, I’m just not remembering the context to link. I already say that almost always does not make the least sense, and when it does, the author of the code usually clearly sees the need. Usually "obfuscations" of ID more generate problems than they solve (you start having to worry about collision and other N things) - not to confuse with using different bases for URL, as do bit.ly and other shorteners, for example. In these cases only a larger set of characters is used to compress the information.
– Bacco