https://web.archive.org/web/20250208000940/https://www.parad...
The first was that 123456 was the credentials for the admin panel.
The second was an insecure direct object reference, where the lead_id querystring parameter can be changed on an API call to retrieve another applicant's data.
With HMAC, you can still ask for some sequential IDs
SipHash128(0, KEY) = k_0
SipHash128(1, KEY) = k_1
You get the same number of bits as a UUID.
You can't, however, sort by IDs to get their insertion sequence, however. For that you'd need something like symmetric encryption but this is already a bad idea, no reason to make it worse.
Can you tell I've been scarred by discussing designs with folks who focus on the "visible" problems without thinking about the fundamental question of "is this secure"?
Defense in depth is a thing, so even if you make a mistake in one place, and the attacker gets complete access - as what happened with the McApplicaton here - they won't be able to download your entire db within minutes. Even with zero authentication, non-guessable identifiers will slow down the exfiltration by several factors from dozens/hundreds of records per second to one record per $MANY_DAYS, with lots of 404s for the defenders to look at.
> That means you'll probably leak them, expose them, or other folks will collect them (often incidentally via things like system logs)
The additional friction of acquiring the UUIDs from a different channel is beneficial to defenders, compared to decrementing or incrementing IDs, which is trivial to do, and doesn't need RCE. It's the difference between "All users' data was exfiltrated" and "Only a couple/handful of accounts were affected", and this can make or break the breached company.
The point is not that UUIDs are magically secure, it's that they mean nothing to whoever gains access except a single job app. The assumption is that they will get out (they're in a public URL), and that they will have no meaning when they do.
It's a defense-in-depth thing IMO -- cargo-culting this approach defends you even when you don't do the other things right. It's simple -- with a non-zero probability that the actual access control is faulty, do you want a default that protects you or doesn't. What's the intentional trade we're going for? More DB perf? Easier to type URLs? There are other ways to deal with those
> Can you tell I've been scarred by discussing designs with folks who focus on the "visible" problems without thinking about the fundamental question of "is this secure"?
Yes :(
"Security through obscurity" isn't really good enough.
UUIDs aren’t “just more difficult to guess.” They are inconceivably harder to guess.
> Put another way, one would need to generate 1 billion v4 UUIDs per second for 85 years to have a 50% chance of a single collision.
def uuid4():
"""Generate a random UUID."""
return UUID(bytes=os.urandom(16), version=4)
So there really shouldn't be anyone using that today, thankfully.
> The first was that 123456 was the credentials for the admin panel.
No. 123456 was the credentials for the test setup, which contained nothing. But you could use the IDOR to access data from the test setup.
If 123456 had been the credentials to the admin panel, there would have been no point in exploiting an IDOR - as an admin, you can just look at whatever you want.
> Moreover, when Carroll attempted to alert Paradox to the breach, he was unable to find a security disclosure contact. The company's security page mostly consists of a simple assurance that users shouldn't need to worry about security. Eventually, after the researchers emailed "random people," Paradox and McDonald's confirmed that they resolved the issue in early July.
Shouldn't need to worry indeed. McDonald's evidently doesn't either.
Can someone tell them to put "Set a password a five-year-old child can't guess" onto their deployment checklist?
I just looked it up 13 of the 40k francises are in the US. Assuming linearity, thats about 21 million US applicants since they started keeping centralized, digital records.
20% of Americans younger than 40 is not a bad guess.
Seems totally reasonable to me.
2 shifts of 12 employees is 24 employees per day. Assume they all work there for 6 months on average, then if the system's been up for 10 years, that's 480 employees per franchise over a decade. Which means for every employee they hired, 2 were either rejected or chose not to work there.
Working at McD's is something a lot of people do for a few months when they're young.
Its not as deep as the guesses
'Move fast and break things' indeed.
I use it once a week and I don't find it annoying at all, except for the bug where it will let you complete an order for an airport McDonald's, and then soon after automatically cancel the order.
I can place an order in the Chick-fil-A app in about 10-20 seconds. Quick and easy.
A similar order in the McDonalds app throws up ads, unskippable animations in time sensitive spots, unresponsive or jumpy UI elements, popup alerts several times, unnecessary steps (like how the fries category has one item, but it still shows you the list view), etc.
I’ve wound up parked in the lot cursing at the app a number of times as I tap through obstacles.
I do computers for a living and can barely navigate and figure out what’s going on.
2. Many franchises have a crummy PA system, so you can avoid this if you plan on using the drive-through.
3. Customization. It's very tedious for all involved to repeatedly request "no cheese", "no ice", "extra sauce", etc. for a very large (e.g., $100+) order.
Never happens with apps.
1) People who just want to eat McDonald's now and don't care about apps. They will put up with the normal prices which are quite high now.
2) Cheapskate people who wouldn't go to McDonald's much due to the pricing, but can be enticed to go through deals in the app they are happy to jump through hoops to get.
suhide in magisk makes my banking app work, but not mcdonalds :)
$ Downloading 64M transcripts...
Are they counting everybody since 1954?
There should be no surprise here.