Hacker News Reader

Comment by aafldkjfaljkdpr | Hacker News Reader

I think security systems tend to tell as little as possible in these cases because to do otherwise reveals something of the internal structure of a system, potentially indicating vulnerable points.

IIRC a post on naming servers where someone said if they knew one server was called Bilbo then they had a pretty good idea what the other servers might be named after. Seemed a good point.

View on HN

This seems misguided. If you are taking principle-of-least-privilege seriously (and it seems that's what people are trying to do with very sophisticated authz systems) then legitimate users will bounce off the edges of their privileges very frequently. If they can't figure out what those edges are or how to expand the frontier when necessary, they're not going to be able to accomplish necessary tasks.

A policy of "stay the hell away, don't even ask" only works if you're drawing the boundary very far from the user's legitimate sphere of influence.

Dunno, just reporting what I understood to be. It may be a distinction can be made between company-internal and company-external attempts at access, but that is pretty risky.

Any solution to the valid point you have made would have to be organisational.

But the saying goes something like "security annoying, good security is very annoying" - anyone know the original?

This is definitely a consideration for authorization. To do it well you need to be able to distinguish when you want to reveal information.

For example, our APIs push people towards returning a 404 if the user doesn't have read access (you shouldn't even know it exists!), but a 403 if you can read but not edit.

You would probably want to do similar here -- only return a reason if the user is allowed to know it exists, but they don't have access. (e.g. it might be "read_exist" vs "read_details" -> "you cannot read the details of this document because you are not a member of this folder".)

Reply on news.ycombinator.com