[deleted]
Things you should do now (2011)
31–40 of 115 posts
Re: Things you should do now (2011)
#32I thought we weren’t supposed to call it “blacklist” or “whitelist” anymore?
You’re not wrong that a segment of the population has deigned this term offensive, but it’s maybe a very extreme fringe segment. A lot of self-proclaimed “woke” types would roll their eyes at this one. But the same language reformers did convince GitHub to rename “master” branches to “main” so who knows.
Regardless, this article is from 2011, so it predates the discussion.
Re: Things you should do now (2011)
#33For me #1 would be to add a version to any data format or communication
protocol. If you want to know how hard not doing so can bite, don't look further than Git and it's tourcherous migration from sha1.
Re: Things you should do now (2011)
#34Things 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.
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.
Re: Things you should do now (2011)
#35Earlier quoted context omitted.
What's wrong with integer IDs?
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, also there's no possibility of collision. You can't have two processes generate the same ID (which means you can generate your IDs in code and send them to the database, which is really useful in some situations).
Also, and this is the main one for me - if I mess up my code and accidentally use a document_id instead of a user_id, I'll just get "not found" instead of someone else's data.
Re: Things you should do now (2011)
#36Earlier quoted context omitted.
What's wrong with integer IDs?
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.
Re: Things you should do now (2011)
#37For me #1 would be to add a version to any data format or communication protocol. If you want to know how hard not doing so can bite, don't look further than Git and it's tourcherous migration from sha1.
are there good examples for this, and how it scaled across versions over time?
Re: Things you should do now (2011)
#38I thought we weren’t supposed to call it “blacklist” or “whitelist” anymore?
While I'll avoid the political nature, I do find the terms are misused. In Firefox extensions, for security it's more intuitive (based on prior usage) for security-related extensions like an ad block. Anything on a whitelist is allowed (to include ads), and on the blacklist, it is not allowed (ads are blocked).
But I have another extension that just modifies the format of some pages to make them easier on my eyes. It took experimentation for me to realize that items on the whitelist are modified, while those on the blacklist are not. My intuition told me whitelists are for sites that are good the way there are, and sites that are hard on the eyes should be put on the blacklist.
It's not the worst mix-up in the world, and perhaps many smarter than myself would have no such confusion, but I think it could be avoid with words that mean what they do. There's plenty of room in the extension configuration to put "apply to these sites" or "transformed", as well as "allow original format" or "unchanged."
Re: Things you should do now (2011)
#39Earlier 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, also there's no possibility of collision. You can't have two processes generate the same ID (which means you can generate your IDs in code and send them to the database, which is really useful in some situations). Also, and this is the main one for me - if I mess up my code and accidentally use a document_id instead of a user_id, I'll just get "not found" instead of someone else's data.
Actually, afaik uuids are pseudo-random and can thus absolutely collide in theory. Collision is solved by every db backend out there.
Re: Things you should do now (2011)
#40Things 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.
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?
One bug I saw came from picking an integer id as “one more than the largest id of the current elements we have.” This worked fine until they added support for deleting elements, which also worked fine most of the time.
A common disadvantage of integer keys is that programs will have bugs and use a foo_id as a bar_id. If most ids are small integers then it is likely that a valid foo_id may be a valid bar_id, whereas uuids probably won’t collide. This can be somewhat mitigated with a sufficiently strong type system. Even in a dynamic language like lisp you can represent your ids as e.g. (foo . ), and only need to get the tags right on the boundary.
An advantage of integer ids is density: if your ids are likely close together, there are probably some better or more compressed data structures you can use.