←back to thread

'123456' password exposed chats for 64M McDonald's job applicants

(www.bleepingcomputer.com)
111 points nan60 | 1 comments | 11 Jul 25 21:48 UTC | HN request time: 0.748s | source
Show context
bsuvc ◴[11 Jul 25 22:54 UTC] No.44537604[source]▶
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.

replies(3): >>44537968 #>>44538121 #>>44538299 #
hardwaresofton ◴[11 Jul 25 23:48 UTC] No.44537968[source]▶
A third problem that senior engineers might recognize: using numeric IDs on an outward facing object. UUIDs would have made this impossible as well
replies(3): >>44538043 #>>44538169 #>>44538538 #
lelandbatey ◴[12 Jul 25 00:24 UTC] No.44538169[source]▶
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"?

replies(3): >>44538381 #>>44538590 #>>44539947 #
1. hardwaresofton ◴[12 Jul 25 01:43 UTC] No.44538590[source]▶
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 :(