Generalising this; you don't need stateful logged-in authentication to defeat IDOR, you can include an appropriately salted HMAC in the construction of a shared identifier, optionally incorporating time or other scoping semantics as necessary, and verify that at your application's trust boundary.
This tends to make identifiers somewhat longer but still fit well inside a reasonable email'd URL to download your phone bill without having to dig up what your telco password was.
However, note that one of the baseline requirements of privacy-oriented data access is issuing different and opaque identifiers for the same underlying thing to each identifiable principal that asks for it. Whether that's achieved cryptographically or by a lookup table is a big can of engineering worms.
A password-capability system is a password-capability system. Not requiring an account does not make it not an access control. (Though it does make it e.g. not selectively revokable, which is a known weakness of password capabilities.)
(The intended contrast is with “object capabilities”, where the designation is once again necessary and sufficient but also unforgeable within the constraints of the system. Think handles / file descriptors: you can’t guess a handle to a thing that the system did not give you, specifically, a handle for.)
a fun retail banking variation of this misadventure is (1) someone designs an elegant RESTful API for doing something or other (2) and it gets applied to credit cards, where the credit card number is used as the natural primary key and is RESTfully embedded in URLs, which people endeavour to avoid logging, but then when you (3) integrate middleware to report metrics to some SaaS monitoring platform, the end result is that you're spraying all your customers credit card numbers into the monitoring platform
why would anyone who ever suggested such a thing not be relegated to permanent headlight fluid fetching duty?
The failure of depending on natural keys is simply highlighted by that problem.
Aren't those guys hammered nearly daily (at least weekly) with one real-world example after another about how natural keys aren't unique?
That reminds me of Stallman's apocryphal story about favoring a password instead of ACLs, and why GNU doesn't have a "wheel" group :)
https://administratosphere.wordpress.com/2007/07/19/the-whee...
Sometimes a few of the users try to hold total power over all the rest. For example, in 1984, a few users at the MIT AI lab decided to seize power by changing the operator password on the Twenex system and keeping it secret from everyone else. (I was able to thwart this coup and give power back to the users by patching the kernel, but I wouldn't know how to do that in Unix.)
However, occasionally the rulers do tell someone. Under the usual I'm on the side of the masses, not that of the rulers. If you areHow would that work? What is it about the wheel group that stops the sympathetic wheel from revealing his own login information to other people?
The wheel member probably doesn't want to reveal their own login information. They want to share the root password with other users; on systems without a wheel group that works, but on systems with a wheel group non-wheel users can't su.
What's the difference? What would be something the other user could do in one of those scenarios that they couldn't do in the other one?
Then there's a paper trail, bob logs in 10 times as much as anyone else and from all over the place.
Anyway this is all silly ancient politics and shared admin passwords as a method of freeing the people is long past relevant.
full stop.
The answer is _always_ auth over obfuscation.
lmm•2h ago
magnio•2h ago
vrosas•1h ago
Tostino•1h ago
8organicbits•1h ago
https://medium.com/google-cloud/understanding-uuidv7-and-its...
kbolino•55m ago
findjashua•33m ago
kbolino•18m ago
crazygringo•59m ago
And if your database is 99% reads 1% writes, the difference probably doesn't really matter.
And tons of database indexes operate on randomly distributed data -- looking up email addresses or all sorts of things. So in many cases this is not an optimization worth caring about.