5 ms·

Thinking that harder-to-guess IDs will mitigate attacks is an example of security by obscurity. It's better to think of any IDs in your database as being public

Thinking that harder-to-guess IDs will mitigate attacks is an example of security by obscurity. It's better to think of any IDs in your database as being public knowledge, because they will leak anyway. Assuming that no one can guess another ID leads to shoddy practices. I generally keep IDs sequential and build security around the basic assumption that IDs are not keys, passwords, sessions, or secrets - they're just the public matching identifier for those things. To that end, I think it's neat to be able to improve indexing on UUIDs, but it's not a security solution.

berkes 3y ago
Doesn't that still leak (statistical) information? It may not be technically security, but e.g. knowing your competitor just added N products to their shop, might be a security issue for the business.
- hughesjj 3y ago
  You're absolutely right, this is also why you generally encrypt sessionized or "consistent view" pagination tokens for public apis (save for primitives like ddb or Kafka) The end user should know no details about your internal key space.
- noduerme 3y ago
  It may. Certainly, for instance, sequential invoice numbers do. If a business decides to take measures to obscure that, no problem. All I'm saying is that obscuring a numbering system for data artifacts shouldn't be considered any sort of security as far as keeping your endpoints from being hacked.
  - berkes 3y ago
    The point on invoice-numbers brings another issue to mind. We model our domain(s) using DDD, and often "The ID" really is best left a thing with meaning. Customer-id, Bank-account-number, invoice-number, email, etc. At least within the domain, it is. The business (and laws etc) already ensure there can only ever be one invoice with this number. Its terribly counterproductive to have two ID's for something. "Hey, can you have a look at invoice 20230233, because it seems the VAT was applied wrong. Hmm, do you have the UUID for that invoice and DM me that? You know, the long one with the hyphens". I guess there isn't a one-size-fits all solution and that "it depends" very much on what e.g. "public" means.
ivan_gammel 3y ago
Security by obscurity is a working solution if implemented with other measures. It increases the cost of attack, which in the presence of unknown vulnerabilities gives you precious time to respond.
Nevermark 3y ago
Security by obscurity is a necessary step in most software security. It hardens, completes and complements other measures. Examples of every day security using obscurity: every password and encryption key EDIT: Thanks for the replies. Ignore above! Obscurity is the low bit of security. But when it’s convenient, it still helps.
- PhilipRoman 3y ago
  passwords and encryption keys are secrets, not obscurity. Security by obscurity would be hiding your house key under a doormat for your friend to find - depending on the culture you live in you may be more or less safe but it is not security (just like hosting your ssh server on port 9384 will repel 99% of attackers but is not a security measure).
  - wolletd 3y ago
    I keep SSH on Port 22. After years, I'm still amazed about the operational model of these attacking hosts. They are completely dumb. I haven't kept record, but I have the feeling that some IPs in my fail2ban list are practically in there for month or even years now. I assume they are just sweeping the whole IPv4 range? No state, no cache. Either they successfully attack a host or they go to the next IP. Repeat 2^32 times, start again. I'm not sure where I wanted to go with this comment. Is it _that cheap_ to constantly sweep the IPv4 range or is it _that profitable_ to do it once you have a successful attack?
- earnesti 3y ago
  Obscurity and secrecy are different things. Though I agree with you. Moderate amount of well implemented obscurity is helpful.
  - Sebb767 3y ago
    > Moderate amount of well implemented obscurity is helpful. You're getting that wrong: Everything else being equal, the more obscure system will always be the safer one. It's just that obscurity can easily be lost, so your system should, if in any way possible, still be secure even if fully known. In the end, however, no system is 100% secure, but more obscurity will make it harder to find the inevitably existing issues.
dalore 3y ago
Having sequential ID's is more than just a security risk, it's an information risk. Competitors can use them to estimate the size of your business, the number of customers you have, and all sorts of stuff. This was used in the war to estimate the number of German tanks based on the sequential IDs https://en.wikipedia.org/wiki/German_tank_problem https://en.wikipedia.org/wiki/German_tank_problem So just for business intelligence you don't want to leak your IDs.
- jabart 3y ago
  They can still find out through LinkedIn, ZoomInfo, BuiltWith, and any number of tools. The tank problem doesn't fit when the incrementing value is time since epoch. Integers yeah, UUIDs, KSUIDS, or any other semi-ordered thing to make your database indexes less fragmented I haven't seen a real leak issue with those.
- madeofpalk 3y ago
  Not disagreeing with the general concept - these IDs leak information - but these are sequential IDs, not auto-incrementing IDs. The leak is the time the ID was generated, not the volume of IDs generated.
  - crazygringo 3y ago
    That's still a competitive risk -- it does things like reveal if a given list of customers from recent orders/posts are all new customers or long-term customers. Or from a list of most recently added customers/users, you can figure out the rate of signups. Revealing timestamps is bad because it can reveal way too much information about the health of your business that you prefer to keep private, if a sequential list of ID's ever gets exposed (which is hard to prevent).
  - pnpnp 3y ago
    They’re not even strongly sequential (is there a term for this?). The gaps between them can be arbitrarily large.
    - 3y ago
wolletd 3y ago
Just friday I've had a discussion with a colleague about filenames. We do a lot of computer vision and in his project, each processed object is assigned a UUID and he wanted to save images to files for each one. So we took some time to go over various timestamp formats to be embedded into the filename to make the files sort chronologically. UUIDv7 is just spot-on solving our problem. In this use case, there are no real security considerations.
vidarh 3y ago
You should think of them as public, but that doesn't mean it isn't still helpful to obscure aspects of the information they carry. Obscurity can be helpful as part of defence in depth, to reduce the impact when someone does something stupid, or to make it more difficult to extract information that might be helpful as a means to attack the system from another angle. If you're already thinking about the implications, you can likely ensure people doesn't jump to the conclusion that the IDs can be trusted just because they look complex.

berkes 3y ago

Doesn't that still leak (statistical) information? It may not be technically security, but e.g. knowing your competitor just added N products to their shop, might be a security issue for the business.

hughesjj 3y ago
You're absolutely right, this is also why you generally encrypt sessionized or "consistent view" pagination tokens for public apis (save for primitives like ddb or Kafka) The end user should know no details about your internal key space.
noduerme 3y ago
It may. Certainly, for instance, sequential invoice numbers do. If a business decides to take measures to obscure that, no problem. All I'm saying is that obscuring a numbering system for data artifacts shouldn't be considered any sort of security as far as keeping your endpoints from being hacked.
- berkes 3y ago
  The point on invoice-numbers brings another issue to mind. We model our domain(s) using DDD, and often "The ID" really is best left a thing with meaning. Customer-id, Bank-account-number, invoice-number, email, etc. At least within the domain, it is. The business (and laws etc) already ensure there can only ever be one invoice with this number. Its terribly counterproductive to have two ID's for something. "Hey, can you have a look at invoice 20230233, because it seems the VAT was applied wrong. Hmm, do you have the UUID for that invoice and DM me that? You know, the long one with the hyphens". I guess there isn't a one-size-fits all solution and that "it depends" very much on what e.g. "public" means.

ivan_gammel 3y ago

Security by obscurity is a working solution if implemented with other measures. It increases the cost of attack, which in the presence of unknown vulnerabilities gives you precious time to respond.

Nevermark 3y ago

Security by obscurity is a necessary step in most software security. It hardens, completes and complements other measures. Examples of every day security using obscurity: every password and encryption key EDIT: Thanks for the replies. Ignore above! Obscurity is the low bit of security. But when it’s convenient, it still helps.

PhilipRoman 3y ago
passwords and encryption keys are secrets, not obscurity. Security by obscurity would be hiding your house key under a doormat for your friend to find - depending on the culture you live in you may be more or less safe but it is not security (just like hosting your ssh server on port 9384 will repel 99% of attackers but is not a security measure).
- wolletd 3y ago
  I keep SSH on Port 22. After years, I'm still amazed about the operational model of these attacking hosts. They are completely dumb. I haven't kept record, but I have the feeling that some IPs in my fail2ban list are practically in there for month or even years now. I assume they are just sweeping the whole IPv4 range? No state, no cache. Either they successfully attack a host or they go to the next IP. Repeat 2^32 times, start again. I'm not sure where I wanted to go with this comment. Is it _that cheap_ to constantly sweep the IPv4 range or is it _that profitable_ to do it once you have a successful attack?
earnesti 3y ago
Obscurity and secrecy are different things. Though I agree with you. Moderate amount of well implemented obscurity is helpful.
- Sebb767 3y ago
  > Moderate amount of well implemented obscurity is helpful. You're getting that wrong: Everything else being equal, the more obscure system will always be the safer one. It's just that obscurity can easily be lost, so your system should, if in any way possible, still be secure even if fully known. In the end, however, no system is 100% secure, but more obscurity will make it harder to find the inevitably existing issues.

dalore 3y ago

Having sequential ID's is more than just a security risk, it's an information risk. Competitors can use them to estimate the size of your business, the number of customers you have, and all sorts of stuff. This was used in the war to estimate the number of German tanks based on the sequential IDs https://en.wikipedia.org/wiki/German_tank_problem https://en.wikipedia.org/wiki/German_tank_problem So just for business intelligence you don't want to leak your IDs.

jabart 3y ago
They can still find out through LinkedIn, ZoomInfo, BuiltWith, and any number of tools. The tank problem doesn't fit when the incrementing value is time since epoch. Integers yeah, UUIDs, KSUIDS, or any other semi-ordered thing to make your database indexes less fragmented I haven't seen a real leak issue with those.
madeofpalk 3y ago
Not disagreeing with the general concept - these IDs leak information - but these are sequential IDs, not auto-incrementing IDs. The leak is the time the ID was generated, not the volume of IDs generated.
- crazygringo 3y ago
  That's still a competitive risk -- it does things like reveal if a given list of customers from recent orders/posts are all new customers or long-term customers. Or from a list of most recently added customers/users, you can figure out the rate of signups. Revealing timestamps is bad because it can reveal way too much information about the health of your business that you prefer to keep private, if a sequential list of ID's ever gets exposed (which is hard to prevent).
- pnpnp 3y ago
  They’re not even strongly sequential (is there a term for this?). The gaps between them can be arbitrarily large.
  - 3y ago

wolletd 3y ago

Just friday I've had a discussion with a colleague about filenames. We do a lot of computer vision and in his project, each processed object is assigned a UUID and he wanted to save images to files for each one. So we took some time to go over various timestamp formats to be embedded into the filename to make the files sort chronologically. UUIDv7 is just spot-on solving our problem. In this use case, there are no real security considerations.

vidarh 3y ago

You should think of them as public, but that doesn't mean it isn't still helpful to obscure aspects of the information they carry. Obscurity can be helpful as part of defence in depth, to reduce the impact when someone does something stupid, or to make it more difficult to extract information that might be helpful as a means to attack the system from another angle. If you're already thinking about the implications, you can likely ensure people doesn't jump to the conclusion that the IDs can be trusted just because they look complex.