31–40 of 81 posts
Earlier quoted context omitted.
Yes and… 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.
You are both right. UUIDs, if randomly generated from a CSPRNG are impossible to guess. But not all UUIDs are generated from a secure RNG, or use randomness at all.
Wait, 64 million applicants, not applications? That's like 20% of the US population!
Others have said it's for the global site, but would 64 million really be that off for the US? 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.
It's funny how mcdonalds did everything in their power to make it almost impossible to run their mcdonalds app on a rooted phone, but their backend infrastructure is beyond broken (security wise)
It's funny how mcdonalds did everything in their power to make it almost impossible to run their mcdonalds app on a rooted phone, but their backend infrastructure is beyond broken (security wise)
Btw, I wondered why they flight root on the phone at all?
Earlier quoted context omitted.
You are both right. UUIDs, if randomly generated from a CSPRNG are impossible to guess. But not all UUIDs are generated from a secure RNG, or use randomness at all.
I may be a dingleberry but who doesn't use uuidv4 for everything?
Earlier quoted context omitted.
A third problem that senior engineers might recognize: using numeric IDs on an outward facing object. UUIDs would have made this impossible as well
Not impossible, just more difficult to guess. "Security through obscurity" isn't really good enough.
It sounds like there were two separate problems: 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.
A third problem that senior engineers might recognize: using numeric IDs on an outward facing object. UUIDs would have made this impossible as well
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.
It's funny how mcdonalds did everything in their power to make it almost impossible to run their mcdonalds app on a rooted phone, but their backend infrastructure is beyond broken (security wise)
The McDonalds consumer-facing app is quite possibly the worst app from a major company I've ever encountered. It's shockingly bad.
I do computers for a living and can barely navigate and figure out what’s going on.