Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

bleepingcomputer.com

Post reply on HN
Print view View original

41–50 of 81 posts

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

#41

Post by hardwaresofton »

lelandbatey wrote: post #15
hardwaresofton wrote: post #9

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

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 you…

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 :(

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

#42

Post by hardwaresofton »

jszymborski wrote: post #38
hardwaresofton wrote: post #9

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

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…

You could also "just" have an internal-use only numeric ID, or use a UUIDv7.

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

#43

Post by cobbal »

xeromal wrote: post #31
zarzavat wrote: post #26

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?

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.

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

#44

Post by 0cf8612b2e1e »

cobbal wrote: post #43
xeromal wrote: post #31

Earlier quoted context omitted.

I may be a dingleberry but who doesn't use uuidv4 for everything?

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.

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.

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

#48

Post by maple3142 »

cobbal wrote: post #43
xeromal wrote: post #31

Earlier quoted context omitted.

I may be a dingleberry but who doesn't use uuidv4 for everything?

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.

For python specifically, the uuid4 function does use the randomness from os.urandom, which is supposed to be cryptographically random on most platforms.
Post reply on HN