User IDs probably shouldn't be passed around as ints

I see this an issue of typing. Programs use integers in many different kinds of ways, and if you have a function that accepts an integer as an argument, neither static nor dynamic type checking will catch the case where you pass the wrong "type" of integer. The same goes for UUIDs, strings, etc. or whatever other opaque values you use to reference entities in your system.

You can avoid these problems by wrapping the integers in objects that you use solely for referencing entities of the relevant type. For example:

    class UserRef {
        id: int;
    }

Then you define functions like this:

    function ban_account(user: UserRef) {
        // ...
    }

And a static type checker will pick up incorrect uses. For dynamically typed languages, you could instead use a unique field name such as user_id, to achieve the same thing (though getting a runtime error instead of a compile time error).

Obviously you'll still be using ints or strings as an external representation, but as long as you do the conversion at the point where the identifier enters the program, the type system will take care of the rest for you.

Basically saying that don't use numbers because somebody might write crap code and it'll get run on your deployment database?!

If getting such dangerously awful code deployed to production is likely then sequential IDs are just one of your many problems!

Sequential IDs for key data can be good to avoid for a few good reasons but awful code isn't one of them. Testing, code reviews and not having bad programmers should be in place to fix that.

Problem is that randomly assigned ids tend to perform sub-optimally in relational databases due to the sparse distribution screwing up row estimates and causing fragmented writes to the underlying table. For this reason many people have a policy of having (nice sequential) "internal" ids and then (pseudorandom) "external" ids.

Hi, I'm mister UUID and I have been living in your favourite framework since 2001. Use me.

Looking at the provided example. Nothing like that has ever happened in any code I've ever written, or I've ever seen written by anybody else, and I have absolutely no fear that I will ever see anything like that happen in any code I write for the rest of my career/life.

So, not a great example, and not a very convincing argument to me to stop using integers.

This can be addressed by using 'opaque ids' which are typed to be incomparable & non interchangable. Then have explicit to/from int conversion

There are several points in this article :

1/ stuffing random ints into your user functions : that problem can be solved with typing and tests. I'm hoping that extensive testing of any piece of code which would have a drastic effect on a user would get extensive testing before going into production.

2/ ID canary : seems a rather good idea, like stack canaries commonly used when you don't have much stack space and you might get a collision with your heap. It's only a problem for languages for which point 1/ couldn't be a solution.

3/ Using UUIDs to avoid disclosing information about your user count : I think that's a separate problem. You should avoid disclosing unneeded information in general. If you use int IDs, always have an opaque public_id field that you use publicly and for interoperability with third-parties. But it does not mean you have to use UUIDs internally. However they do have a number of advantages, mainly that you don't need a central authority to distribute new sequence numbers, you can just generate UUIDs where you need them which will save you DB round-trips and make sharding of your DB easier. Also will help avoid issues such as this one : https://blog.travis-ci.com/2018-04-03-incident-post-mortem

Types, as mentioned, make this easy to avoid. For example:

A User has an ID of type UserId.

A Message has an ID of type MessageId and a sender of type UserId.

ban_senders_of_messages would have a parameter of type [Message]

ban_account would have a parameter of type UserId

I think the real problem is the terse coding style. Why does the for loop always use "i"?

When I write code, I don't use "i" or other single-letter variable names. I write long names, like "currentItem", "currentMessage", "currentUser", etc. If I reference an object, I usually name it "thisItem", "thisMessage", "thisUser".

Compilers shrink executables, so it's not a size issue. I don't know why people want code to be shorter; I prefer it to be easy to read and debug.

Since I largely program in C#, I typically define the unique ids on my classes as enums. Enums in C# are open, not closed, so you can define something like a UserId like so:

    public enum UserId { Unset = 0; }

    public class User
    {
        public UserId Id {get;set;}
    }

This works with various ORM and other mapping tools since enums are ints underneath, but you get static checking.

Then there's the issue of protection when passing around ids in web apps as parameters, in cookies, etc. I devised Clavis [1] as an experiment for protecting URL parameters via an HMAC. The idea works pretty well in practice, but it's current incarnation is a little too cumbersome to use.

[1] A url http://foo.com?userId=1234 becomes http://foo.com?-userId=1234&clavis=asdbwef67t34rfbs, where the 'clavis' parameter is an HMAC of the URL's protected parameters, and changing any of them causes the request to fail. Unprotected parameters are also supported, so GET form submissions are still possible. See: http://higherlogics.blogspot.ca/2014/01/clavis-rebooted-secu...

Last week we caught a bug caused by a security check on the users id (a Java Long) that was accidentally using == instead of .equals(). Since Java caches Long’s between -127 and 128, == will pass for any ids <128, including those from our tests. Our QA stage only caught it because the tester happened to be a later stage employee, so had a user ID > 128.

Another risk is that numerical ids for users (as well as for other database tables) can be used to infer the growth rate of a business. If you record the time that a user is created at, and then repeat the process over a time period, you can work out how many users are joining the app over that time period, and potentially work out the total number of users too.

Strongly typed languages help somewhat, but you still often need to store or serialize the data in something less clever (e.g. JSON).

To reduce risk of mixup of different kinds of IDs in the system I used different increment values in Postgresql sequences (e.g. 13 for users, 7 for categories), so the IDs quickly went out of sync and had little overlap.

Another reason: prevent users from incrementing their ID in the URL bar and discovering whatever pages...

Whenever I deal with an external API, even if it gives me what looks like an integer for any object it has, I treat it as a string. I never do math on it, I don’t care about saving space, and I never know when they’ll run out of space and need to switch. Remember when Twitter famously stopped working because their IDs were BigInt but in JavaScript you only have 53 bits of space? Yeah, I don’t want that.

Also a stupid number of APIs I deal with like to use one or more leading zeros in their identifiers. The meaning isn’t different, but it gets annoying when trying to do search, because of course the end user typed those in and wants to be able to look up whatever as 021.

By the same argument, Unix file descriptors should not be ints, either.

This argument is, in essence, an argument for strongly typed languages. There are many argument against this historical argument, and it is by no means a settled issue – on the contrary, it is very slowly, as the years go by, looking more and more like the strongly typed languages are on the way out.

What you more likely want is a sense of privileged, sensitive, and/or high-consequence users who arent trivially compromised or blocked.

E.g., https://en.wikipedia.org/wiki/Politically_exposed_person

That and some sanity in your account-handling ops.

It's standard security practice not to expose integer user IDs. Anyone who goes through standard security training knows this.

Granted, one thing languages could do is provide easy type containers so it's hard to misconstrue an I'd as referring to a wrong type. I once tried to do this with generics in C# but it wasn't worth the effort.

I think user IDs should be passed around as ints. It's efficient and simple. If you've got critical code that might lock someone out (or worse), you're much better off spending time testing it to ensure it works, rather than building in inefficient paradigms into your data model. For argument's sake, imagine if your data model also stores the sender's current manager per message. You could by mistake do this as well (a little slip of the finger when using code completion):

  ban_senders_of_messages(messages) {
    for (i = 0; i < messages.size(); ++i) {
    
  ban_account(message[i].sendersManager);
    }
  }

The only way to catch that is to test, and because the manager and sender will have similar data types, it will compile/execute just fine. The point is, this is probably a more likely error than the one mentioned in the article, and needs manual inspection and testing to correct. If you're carrying out that process anyway, the added inefficiency of a more elaborate data type just for user IDs seems redundant.

I can recommend the ShortUUID[1] Python package I wrote, I use it for all my IDs nowadays. The good thing about it is that it makes nice and short human-readable/typable IDs that you can use for all your objects, so you don't care even if you expose them to the user.

This has nothing to do with user IDs. It's a general problem with antiquated languages that quietly convert/promote compatible integer types and can happen to any other integer types.

Solution: use a modern language like Go or use pointers to structs like everyone else.

I hope that it's obvious that you shouldn't expose part of your implementation to your end users a la auto incrementing primary keys.

Obfuscation of how data is queried and stored is pretty low hanging fruit, security-wise.

Besides all the other arguments made in the comments about other solutions for user id's...

This code is so easy to write a unit test for. I hope it didnt even get committed, let alone deployed to prod.

Doesn't pretty much every language nowadays have foreach loops that don't require keeping an integer index around when iterating over elements? That seems like a way better idea.

If you need a way to uniquely identify something in the universe, there is no reason to get clever. Just use Universally Unique IDentifiers. UUIDs. Done.

I use a UUID for the primary key, it protects against this as well as other issues. Does have some drawbacks though.

And also you should not recompute the size on each iteration, or ban the same user more than once.

Why would you use anything but a string for User IDs?

My understanding of numerical types is that they exist to perform math. User IDs are not used for math, they're a completely arbitrary vanity system to assist with identification, so they should be strings, equally arbitrary.

Personally, I think E-mail addresses are the best user identifiers these days. Back in the day when there were like 5 websites everyone used, having your username was a cool thing. These days there's a billion websites and nobody uses the same ones and there's zero inter-user interaction on most sites. From the perspective of user friendliness, E-mail addresses are the easiest because you kill two birds with one stone (contact method + username + password recovery).

If you want a numerical ID, what about using a hash of the E-mail address? Or perhaps a combination of things, email, full name, sign-up date.