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

Things you should do now (2011)

secure.phabricator.com

Post reply on HN
Print view View original

71–80 of 115 posts

Re: Things you should do now (2011)

#71

Post by ta3eea8bd »

DavidHilbert wrote: post #63
alexwebb2 wrote: post #49

Earlier quoted context omitted.

Serious answer: this is still very much in flux. We're not at the point where you'd get audible gasps from using these terms, but in certain audiences you'll get some raised eyebrows. If you believe that having "black=bad, white=good" connotations built into our jargon is harmful in some way, then yes, you should strive to use alternate terms. If you don't think that's harmful, and you're forceful in defending "black…

its not blacklist and whitelist because "black=bad, white=good", black is the abscense of light, hence the light is blocked, white would obviously be the opposite. So its black because you are blocking things, and white because you aren't.

It was never about this.

The meta-game is to mess with people and teach them compliance and self-censorship and hyper-attention to anything even remotely related to race. Race must be always the 1st thing you think of. Don't forget race.

Re: Things you should do now (2011)

#72

Post by dragonwriter »

LordHeini wrote: post #47
marcus_holmes wrote: post #20

Things you should never do: use integers as ID's. This is literally a solved problem, and the solution is UUIDs, which were invented for exactly this job.

No you should not. UUIDs are not always a good solution. If you order things by id (often useful for pagination, since incrementing ids are usually ordered by creation date) uuid are of no help. You would need to sort by created_at and this would require an additional index. No to speak of pagination by id ranges or whatever is used sometimes. UUIDs are mpossible to remember and thus somewhat cumbersome to use too. T…

> If you order things by id (often useful for pagination, since incrementing ids are usually ordered by creation date) uuid are of no help.

The use of ordering by a surrogate key is to have a stable ordering with no semantic meaning, so UUIDs work just as well as IDs there.

> You would need to sort by created_at and this would require an additional index.

Yes, if you want to sort by a semantically important data element in a table with surrogate primary key, you'll probably want an index on the data element. So?

> No to speak of pagination by id ranges or whatever is used sometimes.

Assuming a serial column is creation-ordered is not a good idea, but it's usually not too wrong; assuming it's dense, as well, is going to be wrong more often than it is right, except where data is never deleted. Assuming it is dense over the range of a query is even less reliable.

Paginating by serial ID ranges is, almost without exception, a horrible idea.

Re: Things you should do now (2011)

#74

Post by bob1029 »

marcus_holmes wrote: post #20

Things you should never do: use integers as ID's. This is literally a solved problem, and the solution is UUIDs, which were invented for exactly this job.

Integers are by far the best primary key material possible. Only for lack of discipline do they seem inferior to alternatives.

See a prior book I wrote on HN regarding this: https://news.ycombinator.com/item?id=25309248

The current domain model I am working with utilizes a global integer sequence to key all entities. This implicitly eliminates the class of bugs where the same keys of different types overlap and would otherwise mask exceptions. It also enables powerful domain modeling techniques in which the identities of things are themselves to be thought of as first class entities and referred to as a common class of thing. This is a little mind-bending at first, but it enables some really powerful abstractions that would otherwise be infeasible if we had to switch over all possible types of keys.

The benefits of an integer key vs a guid key are quite profound when you get into the academics of information theory. They provide implicit creation order of things, whereas GUIDs cannot. They are deterministic in that there will never be a collision. Their range can be made to be infinite. Integers are perfectly efficient, even if the computer representation isn't necessarily so - BigInteger types scale gracefully.

Re: Things you should do now (2011)

#75

Post by mewpmewp2 »

vsareto wrote: post #36
dkarp wrote: post #27

Earlier quoted context omitted.

The main issue in my experience are so called "user enumeration attacks", especially with sequential ids that are normally used. This is where an attacker is able to leak information from your system just by guessing ids. If you used a sequential id then you can cycle from 1 to X and probably easily find which are valid users. You can then likely see how many valid users/ids there are and potentially pull their data…

This is really an ancillary benefit and not a real solution to enumeration vulnerabilities. The concern is usually over sharding the data, unique ID generation guarantees, and performance. You shouldn't really be deciding UUID vs. Int based on the possibility for ID enumeration. It's almost certainly easier to come up with a solution to slow/prevent enumeration than move from Ints to UUID.

There's also leaking financial, business data. E.g you create an order and you see your order id being 3000 the first day and 4000 the next, so then you'll be able to guess how many orders this company has etc.

Re: Things you should do now (2011)

#76

Post by dragonwriter »

marcus_holmes wrote: post #34
dkarp wrote: post #28

Earlier quoted context omitted.

integer ids are still often used internally for database primary keys with UUIDs being the done thing for external interfaces. Personally I've never experienced the "whole class of bugs" that starting with a big integer is supposed to solve. I'm not using PHP so maybe that's why?

sooner or later you'll make a mistake in your code and use a document_id where you meant to use a user_id, and send a bunch of someone else's data to a user. the "big integer" stops this happening for other integers that might be used in your code and that you might accidentally send to the database as a user_id.

> the "big integer" stops this happening for other integers that might be used in your code

Unless you might also use big integers in your code. 32-bits is big enough for all numbers-used-as-numbers-instead-of-ids is...a risky assumption.

Re: Things you should do now (2011)

#77

Post by MaxBarraclough »

bryanrasmussen wrote: post #2

That start ids at a gigantic number idea is great, even though I've never encountered a bug caused by not doing it.

I like that pattern too. I've tried using it in a rather ad-hoc way in C/C++ enums. I suppose the proper solution would be to have a header file, enum_starting_vals.h, to centralise them.

Re: Things you should do now (2011)

#78

Post by MaxBarraclough »

continuational wrote: post #48

Don't use a raw integer as the ID type. Use different types for different IDs: UserId, OrganizationId, etc. It's a common bug to get different ID types mixed up, and a gigantic offset will do nothing to help you with that.

I agree, the 'microtype' pattern can be a good way of getting the type-checker to catch silly mistakes.

In Ada it's standard practice. In C++ you really need a library to do it easily, but there's a good one out there ready to go:

https://github.com/foonathan/type_safe/

Re: Things you should do now (2011)

#79

Post by dang »

evanelias wrote: post #61

This is from 2011, according to the commit blame info [1]. The advice appears to be from the standpoint of LAMP development a decade ago. [1] https://secure.phabricator.com/source/phabricator/browse/mas...

Year added above. Thanks!

Re: Things you should do now (2011)

#80

Post by corytheboyd »

blacktriangle wrote: post #29
dkarp wrote: post #28

Earlier quoted context omitted.

integer ids are still often used internally for database primary keys with UUIDs being the done thing for external interfaces. Personally I've never experienced the "whole class of bugs" that starting with a big integer is supposed to solve. I'm not using PHP so maybe that's why?

I've run into one, but it was pretty dumb. Multitenant application using the account ID as the first element in the URL on a Rails app. when it got to account 404, my address.com/404 went to the static 404 page rather than account 404. That user was pretty confused for awhile.

Ouch, using the top level path for something dynamic like that is rough. Hope someone learned the right lesson from that :p
Post reply on HN