My favourite part form the original report was that paradox had no way to find their security team ( to contact) and their security page just had "We worry about security, so you don't have to."
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.
hardwaresofton
9 hours ago
[ - ]
A third problem that senior engineers might recognize: using numeric IDs on an outward facing object. UUIDs would have made this impossible as well
jszymborski
8 hours ago
[ - ]
Ok, this is probably a stupid, very bad, no good idea considering I've not heard of people doing this, but can't you retain many of the benefits of numerical IDs but also the secrecy of UUIDs by using an HMAC ?
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.
hardwaresofton
7 hours ago
[ - ]
You could also "just" have an internal-use only numeric ID, or use a UUIDv7.
sam_lowry_
2 hours ago
[ - ]
or ULIDs or any other partially sortable ids.
lelandbatey
9 hours ago
[ - ]
Using numeric IDs on an outward facing object is, for the most part, totally fine. It's a serious tradeoff to ditch the nice properties of numerical IDs and the legibility they provide in order to cargo-cult a "we must reveal nothing" approach, as you would here via UUID. It also misses the point of the actual security lesson: no matter the identifier, you need to be applying access controls to your data. Even if your UUIDs were generated via 100% airtight cryptographically random sources, you have to, y'know, communicate with them. That means you'll probably leak them, expose them, or other folks will collect them (often incidentally via things like system logs). If all it takes to gain access to a thing is knowing the identifier of that thing, you've blown it in a huge way. Don't stress about the theoretical benefits of something like an opaque identifier and then completely neglect the necessary real world access control.
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"?
overfeed
2 hours ago
[ - ]
> If all it takes to gain access to a thing is knowing the identifier of that thing, you've blown it in a huge way.
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.
hardwaresofton
8 hours ago
[ - ]
I think I disagree with "totally fine"... Even if that were true though, this case is definitely a point where you wouldn't want to give away information with a numeric ID. Giving away # of applications/growth of that over time is definitely business information that arguably should not be discernible.
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 :(
mattl
8 hours ago
[ - ]
Yes it makes very little difference if I can see all your public published blog posts on a WordPress site by iterating the number.
bsuvc
9 hours ago
[ - ]
Not impossible, just more difficult to guess.
"Security through obscurity" isn't really good enough.
tyre
9 hours ago
[ - ]
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.
0cf8612b2e1e
8 hours ago
[ - ]
The security is that your server will crash from overload long before someone can guess the ids.
zarzavat
8 hours ago
[ - ]
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.
xeromal
8 hours ago
[ - ]
I may be a dingleberry but who doesn't use uuidv4 for everything?
cobbal
7 hours ago
[ - ]
UUIDv4 may or may not use a cryptographically secure random number generator. Python's UUID library, for example, falls back to the insecure 'random' module. Given a handful of outputs, it's possible to predict future ones.
maple3142
5 hours ago
[ - ]
For python specifically, the uuid4 function does use the randomness from os.urandom, which is supposed to be cryptographically random on most platforms.
shakna
5 hours ago
[ - ]
Uh... Come again?
def uuid4():
"""Generate a random UUID."""
return UUID(bytes=os.urandom(16), version=4)
Gasp! I had no idea about the Python implementation. Not that I do anything where it would matter (just need a random id), but for an already slow language, I would prefer the safer default.
hardwaresofton
8 hours ago
[ - ]
UUIDv7 indexes better in databases
hardwaresofton
8 hours ago
[ - ]
Yes, you are technically right -- I should have said "functionally impossible". It's not actually impossible, but close enough for the average random onlooker.
thaumasiotes
8 hours ago
[ - ]
> It sounds like there were two separate problems:
> 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.
Natsu
9 hours ago
[ - ]
123456 was both the username & password, they were hit by CWE-1392 because someone failed to change the default credentials.
thaumasiotes
8 hours ago
[ - ]
The writeup never claimed that 123456:123456 were default credentials?
Stupid question, if we really tried brute forcing websites with less than 100k monthly traffic, how many such cases would be actually run into?
micw
10 hours ago
[ - ]
Wait, 64 million applicants, not applications? That's like 20% of the US population!
mousethatroared
9 hours ago
[ - ]
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.
crazygringo
8 hours ago
[ - ]
Which is 1,615 applicants per US franchise.
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.
yieldcrv
6 hours ago
[ - ]
No its 64 million chatbot interactions that instantiated it at all
Its not as deep as the guesses
Volundr
10 hours ago
[ - ]
Maybe it includes applications outside the US?
bigfatkitten
10 hours ago
[ - ]
They use this site for hiring globally. The number of privacy regulators they will have to notify and deal with is going to make this messy.
atm3ga
9 hours ago
[ - ]
If this was disclosed via a vulnerability disclosure or bug bounty program and there are no indicators of a data breach then it's effectively like the findings from a pen-test so very likely no regulatory reporting requirements.
ezekiel68
5 hours ago
[ - ]
This is what happens when "Minimum Viable Product" meets modern threat environments.
'Move fast and break things' indeed.
pyman
9 hours ago
[ - ]
Please stop giving OpenAI ideas on where to find and download more data!
$ Downloading 64M transcripts...
ajsnigrutin
9 hours ago
[ - ]
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)
ceejayoz
8 hours ago
[ - ]
The McDonalds consumer-facing app is quite possibly the worst app from a major company I've ever encountered. It's shockingly bad.
rahimnathwani
2 hours ago
[ - ]
It can be confusing for new or infrequent users.
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.
parpfish
8 hours ago
[ - ]
The UI is atrocious.
I do computers for a living and can barely navigate and figure out what’s going on.
Keverw
3 hours ago
[ - ]
I noticed it freezes up on me sometimes when I open it. I assume something is blocking instead of being asynchronous when it pings their servers, but instead of waiting to dismiss a loading screen it just shows the full app and like freezes.
whatsupdog
4 hours ago
[ - ]
Why does one even need an app for a fast food restaurant?
brikym
2 hours ago
[ - ]
I don't eat that junk but my understanding is McDonald's have segmented their customers into two groups:
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.
acuozzo
4 hours ago
[ - ]
1. You can exchange privacy for 20% off.
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.
hippich
9 hours ago
[ - ]
Btw, I wondered why they flight root on the phone at all?
le-mark
8 hours ago
[ - ]
My theory is they store payment information on the mobile app. The app connects to the store wifi automatically, even when going through the drive thru. And processes the payment then. I theorized it so they don’t store credit card info on their servers, simplifying their PCI audits. Presumably they think all that is better than preventing the app from running on rooted phones.
ajsnigrutin
9 hours ago
[ - ]
I have no idea... maybe they store their "coupons" locally and are afraid you'll clone them? Don't know, I eat there twice a year and it's not worth it :)
suhide in magisk makes my banking app work, but not mcdonalds :)
mediumsmart
6 hours ago
[ - ]
That’s the default pin for iPhones too.
deafpolygon
11 hours ago
[ - ]
Incredible! That’s the combination to my matched luggage!
sans_souse
9 hours ago
[ - ]
The spoof prophecies are being proven! now we're all stuck in a real-life Spaceballs movie.
Wait, sixty-four MILLION people actually wanted to work there?
Are they counting everybody since 1954?
notepad0x90
8 hours ago
[ - ]
getting jobs is hard. majority us on this thread couldn't get a job at mcdonalds if we tried our best. and that's mostly because they think we'll quit after a few days/week. and there are harder to get jobs that pay even less! it's about supply/demand, not how desirable the job is.
chungy
8 hours ago
[ - ]
It's the second largest fast food chain, behind Subway. It is everywhere and provides steady good work.
'123456' password exposed chats for 64M McDonald's job applicants
(bleepingcomputer.com)
106 points
by: nan60
11 hours ago
58 comments
jofzar
4 hours ago
[ - ]
My favourite part form the original report was that paradox had no way to find their security team ( to contact) and their security page just had "We worry about security, so you don't have to."
https://web.archive.org/web/20250208000940/https://www.parad...
bsuvc
10 hours ago
[ - ]
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.
hardwaresofton
9 hours ago
[ - ]
A third problem that senior engineers might recognize: using numeric IDs on an outward facing object. UUIDs would have made this impossible as well
jszymborski
8 hours ago
[ - ]
Ok, this is probably a stupid, very bad, no good idea considering I've not heard of people doing this, but can't you retain many of the benefits of numerical IDs but also the secrecy of UUIDs by using an HMAC ?
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.
hardwaresofton
7 hours ago
[ - ]
You could also "just" have an internal-use only numeric ID, or use a UUIDv7.
sam_lowry_
2 hours ago
[ - ]
or ULIDs or any other partially sortable ids.
lelandbatey
9 hours ago
[ - ]
Using numeric IDs on an outward facing object is, for the most part, totally fine. It's a serious tradeoff to ditch the nice properties of numerical IDs and the legibility they provide in order to cargo-cult a "we must reveal nothing" approach, as you would here via UUID. It also misses the point of the actual security lesson: no matter the identifier, you need to be applying access controls to your data. Even if your UUIDs were generated via 100% airtight cryptographically random sources, you have to, y'know, communicate with them. That means you'll probably leak them, expose them, or other folks will collect them (often incidentally via things like system logs). If all it takes to gain access to a thing is knowing the identifier of that thing, you've blown it in a huge way. Don't stress about the theoretical benefits of something like an opaque identifier and then completely neglect the necessary real world access control.
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"?
overfeed
2 hours ago
[ - ]
> If all it takes to gain access to a thing is knowing the identifier of that thing, you've blown it in a huge way.
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.
hardwaresofton
8 hours ago
[ - ]
I think I disagree with "totally fine"... Even if that were true though, this case is definitely a point where you wouldn't want to give away information with a numeric ID. Giving away # of applications/growth of that over time is definitely business information that arguably should not be discernible.
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 :(
mattl
8 hours ago
[ - ]
Yes it makes very little difference if I can see all your public published blog posts on a WordPress site by iterating the number.
bsuvc
9 hours ago
[ - ]
Not impossible, just more difficult to guess.
"Security through obscurity" isn't really good enough.
tyre
9 hours ago
[ - ]
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.
0cf8612b2e1e
8 hours ago
[ - ]
The security is that your server will crash from overload long before someone can guess the ids.
zarzavat
8 hours ago
[ - ]
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.
xeromal
8 hours ago
[ - ]
I may be a dingleberry but who doesn't use uuidv4 for everything?
cobbal
7 hours ago
[ - ]
UUIDv4 may or may not use a cryptographically secure random number generator. Python's UUID library, for example, falls back to the insecure 'random' module. Given a handful of outputs, it's possible to predict future ones.
maple3142
5 hours ago
[ - ]
For python specifically, the uuid4 function does use the randomness from os.urandom, which is supposed to be cryptographically random on most platforms.
shakna
5 hours ago
[ - ]
Uh... Come again?
https://github.com/python/cpython/blob/3.13/Lib/uuid.py0cf8612b2e1e
7 hours ago
[ - ]
Gasp! I had no idea about the Python implementation. Not that I do anything where it would matter (just need a random id), but for an already slow language, I would prefer the safer default.
hardwaresofton
8 hours ago
[ - ]
UUIDv7 indexes better in databases
hardwaresofton
8 hours ago
[ - ]
Yes, you are technically right -- I should have said "functionally impossible". It's not actually impossible, but close enough for the average random onlooker.
thaumasiotes
8 hours ago
[ - ]
> It sounds like there were two separate problems:
> 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.
Natsu
9 hours ago
[ - ]
123456 was both the username & password, they were hit by CWE-1392 because someone failed to change the default credentials.
thaumasiotes
8 hours ago
[ - ]
The writeup never claimed that 123456:123456 were default credentials?
gnabgib
10 hours ago
[ - ]
Discussion (125 points, 2 days ago, 69 comments) https://news.ycombinator.com/item?id=44513940
vivzkestrel
3 hours ago
[ - ]
Stupid question, if we really tried brute forcing websites with less than 100k monthly traffic, how many such cases would be actually run into?
micw
10 hours ago
[ - ]
Wait, 64 million applicants, not applications? That's like 20% of the US population!
mousethatroared
9 hours ago
[ - ]
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.
crazygringo
8 hours ago
[ - ]
Which is 1,615 applicants per US franchise.
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.
yieldcrv
6 hours ago
[ - ]
No its 64 million chatbot interactions that instantiated it at all
Its not as deep as the guesses
Volundr
10 hours ago
[ - ]
Maybe it includes applications outside the US?
bigfatkitten
10 hours ago
[ - ]
They use this site for hiring globally. The number of privacy regulators they will have to notify and deal with is going to make this messy.
atm3ga
9 hours ago
[ - ]
If this was disclosed via a vulnerability disclosure or bug bounty program and there are no indicators of a data breach then it's effectively like the findings from a pen-test so very likely no regulatory reporting requirements.
ezekiel68
5 hours ago
[ - ]
This is what happens when "Minimum Viable Product" meets modern threat environments.
'Move fast and break things' indeed.
pyman
9 hours ago
[ - ]
Please stop giving OpenAI ideas on where to find and download more data!
$ Downloading 64M transcripts...
ajsnigrutin
9 hours ago
[ - ]
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)
ceejayoz
8 hours ago
[ - ]
The McDonalds consumer-facing app is quite possibly the worst app from a major company I've ever encountered. It's shockingly bad.
rahimnathwani
2 hours ago
[ - ]
It can be confusing for new or infrequent users.
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.
parpfish
8 hours ago
[ - ]
The UI is atrocious.
I do computers for a living and can barely navigate and figure out what’s going on.
Keverw
3 hours ago
[ - ]
I noticed it freezes up on me sometimes when I open it. I assume something is blocking instead of being asynchronous when it pings their servers, but instead of waiting to dismiss a loading screen it just shows the full app and like freezes.
whatsupdog
4 hours ago
[ - ]
Why does one even need an app for a fast food restaurant?
brikym
2 hours ago
[ - ]
I don't eat that junk but my understanding is McDonald's have segmented their customers into two groups:
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.
acuozzo
4 hours ago
[ - ]
1. You can exchange privacy for 20% off.
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.
hippich
9 hours ago
[ - ]
Btw, I wondered why they flight root on the phone at all?
le-mark
8 hours ago
[ - ]
My theory is they store payment information on the mobile app. The app connects to the store wifi automatically, even when going through the drive thru. And processes the payment then. I theorized it so they don’t store credit card info on their servers, simplifying their PCI audits. Presumably they think all that is better than preventing the app from running on rooted phones.
ajsnigrutin
9 hours ago
[ - ]
I have no idea... maybe they store their "coupons" locally and are afraid you'll clone them? Don't know, I eat there twice a year and it's not worth it :)
suhide in magisk makes my banking app work, but not mcdonalds :)
mediumsmart
6 hours ago
[ - ]
That’s the default pin for iPhones too.
deafpolygon
11 hours ago
[ - ]
Incredible! That’s the combination to my matched luggage!
sans_souse
9 hours ago
[ - ]
The spoof prophecies are being proven! now we're all stuck in a real-life Spaceballs movie.
bigmattystyles
8 hours ago
[ - ]
Just in time for the sequel!
jonplackett
10 hours ago
[ - ]
For the uninitiated (ie probably anyone under 35)
https://m.youtube.com/watch?v=a6iW-8xPw3k
dylan604
8 hours ago
[ - ]
Earlier this year, Mel posted a video saying they are making a sequel.
mattl
8 hours ago
[ - ]
Check your luggage for fries
ChrisArchitect
7 hours ago
[ - ]
[dupe] https://news.ycombinator.com/item?id=44513940
RandomBacon
5 hours ago
[ - ]
[dupe comment] https://news.ycombinator.com/item?id=44537871
theturtle
9 hours ago
[ - ]
Wait, sixty-four MILLION people actually wanted to work there?
Are they counting everybody since 1954?
notepad0x90
8 hours ago
[ - ]
getting jobs is hard. majority us on this thread couldn't get a job at mcdonalds if we tried our best. and that's mostly because they think we'll quit after a few days/week. and there are harder to get jobs that pay even less! it's about supply/demand, not how desirable the job is.
chungy
8 hours ago
[ - ]
It's the second largest fast food chain, behind Subway. It is everywhere and provides steady good work.
There should be no surprise here.