4 ms·

The point you may be missing is that the key itself contains information about records in the database that you don’t have access to. There are many famous exam

The point you may be missing is that the key itself contains information about records in the database that you don’t have access to. There are many famous examples in literature (e.g. the German Tank Problem [0]) of useful attacks on known unique serials to infer hidden information without access. In a database context, the keys for the records you are authorized to see can tell you much about the parts of the database to which you have no access. Strong randomization of record serials mitigates these attacks. [0] https://en.wikipedia.org/wiki/German_tank_problem https://en.wikipedia.org/wiki/German_tank_problem

Jarwain 1y ago
I thought we were talking about UUIDv7, which is random enough to make this not a problem right?
- sroussey 1y ago
  The idea being to expose uuid instead of the natural index. It’s been downgraded as people use uuids more. That said, security through obscurity is an effective layer, particularly for slowing an attack. Slowing lateral movement is valuable.
  - Jarwain 1y ago
    Sorry I'm a bit confused. I'm in agreement that a natural key shouldn't be used as the primary key for a record. I was responding to a comment about having a hidden "database ID" (which I interpreted as being a serial key?) and a public "Uuid", and questioning the utility of that hidden database ID versus having a public UUIDv7 as the sole primary key, followed by questioning whether the utility of obscuring that primary UUIDv7 is worth the complexity of having to manage multiple artificial keys. I agree that security through obscurity is a valuable layer in a multi-layered security position. I guess I just don't think obscuring a Uuid primary key is worth the added complexity in most systems. I see it like adding a second front door to your house with a separate set of keys. Sure it'd be more secure, but it's an added pain and doesn't help if you don't have a sturdy doorframe, or smash-resistant windows.
    - ringeryless 1y ago
      UUID is PUBLIC id, use it to look up the bigint numerical id, when necessary. one should not divulge scale, placement in numerical sequence, etc wtr to integer id, hence ouvlic UUID, which is basically unguessable token
      - Jarwain 1y ago
        Why have a bigint numerical ID at all?
        ringeryless 1y ago
        fast lookup for internal usage. it's significantly faster than a UUID on every DBMS i have ever seen
        Jarwain 1y ago
        That's a good reason! I think with UUIDv7, because it's sequential it's indexes are faster than UUIDv4. Still larger than bigints though. I'd like to do a benchmark at some point
sgarland 1y ago
The only thing UUIDv7 exposes is its creation time, which isn't tremendously useful or secret information.
HelloNurse 1y ago
In this case obscurity is security: leaked information from the database is directly useful and a secret in itself, not only a stepping stone that might or might not facilitate further exploitation.

Jarwain 1y ago

I thought we were talking about UUIDv7, which is random enough to make this not a problem right?

sroussey 1y ago
The idea being to expose uuid instead of the natural index. It’s been downgraded as people use uuids more. That said, security through obscurity is an effective layer, particularly for slowing an attack. Slowing lateral movement is valuable.
- Jarwain 1y ago
  Sorry I'm a bit confused. I'm in agreement that a natural key shouldn't be used as the primary key for a record. I was responding to a comment about having a hidden "database ID" (which I interpreted as being a serial key?) and a public "Uuid", and questioning the utility of that hidden database ID versus having a public UUIDv7 as the sole primary key, followed by questioning whether the utility of obscuring that primary UUIDv7 is worth the complexity of having to manage multiple artificial keys. I agree that security through obscurity is a valuable layer in a multi-layered security position. I guess I just don't think obscuring a Uuid primary key is worth the added complexity in most systems. I see it like adding a second front door to your house with a separate set of keys. Sure it'd be more secure, but it's an added pain and doesn't help if you don't have a sturdy doorframe, or smash-resistant windows.
  - ringeryless 1y ago
    UUID is PUBLIC id, use it to look up the bigint numerical id, when necessary. one should not divulge scale, placement in numerical sequence, etc wtr to integer id, hence ouvlic UUID, which is basically unguessable token
    - Jarwain 1y ago
      Why have a bigint numerical ID at all?
      - ringeryless 1y ago
        fast lookup for internal usage. it's significantly faster than a UUID on every DBMS i have ever seen
        Jarwain 1y ago
        That's a good reason! I think with UUIDv7, because it's sequential it's indexes are faster than UUIDv4. Still larger than bigints though. I'd like to do a benchmark at some point

sgarland 1y ago

The only thing UUIDv7 exposes is its creation time, which isn't tremendously useful or secret information.

HelloNurse 1y ago

In this case obscurity is security: leaked information from the database is directly useful and a secret in itself, not only a stepping stone that might or might not facilitate further exploitation.