adamfoneil / Dapper.CX

A Crud library based on Dapper
MIT License
8 stars 1 forks source link

support for string identity properties #14

Open adamfoneil opened 4 years ago

adamfoneil commented 4 years ago

I watched this video by Tom Scott. I like Tom, and this was an interesting video, but he goes on a rant about sequential Id values that bothered me. I've heard the criticism before that sequential Ids are a security hole because someone can infer stuff from the numbers, make guesses about your data, and possibly navigate unauthorized content very easily.

But this assumes you have no other security in the first place, and also assumes that whatever someone can guess about your data by playing with sequential numbers is inherently dangerous. I've used int identity types since forever because relational databases support them nicely, and we need as many things as we can get that Just Work. (Now, I think Freshdesk uses negative increment identity values to defeat the kind of "surreptitious analytics" that Scott is talking about, and I think that's a good solution.)

Of course, at least SQL Server supports Guids natively, and they are truly random. But Guids are hard to work with when you need to write SQL and debug things. Writing SQL and debugging need to be a low-friction/highly productive activity. Also, Guid support in SQL Server -- as it applies to generated row Ids -- has a question mark hanging over it: Do I use NewId or SequentialId (I can't remember the function name.) I've read some back and forth about this. Here again, I'm in favor of things that Just Work, don't require StackOverflow debate, and int identity(1,1) just works.

All that said -- I do see some value in supporting generated string identity values. These might be not quite as annoying as Guids since they wouldn't be too long, but I could be kidding myself. I'll use this issue to investigate this, looking at existing random string generation helpers that are likely out there, as well as looking at some I've done before.

adamfoneil commented 4 years ago

Note that I don't intend to support case-sensitive string Ids because such columns would require special collation, and I don't like the idea of anything "special"

adamfoneil commented 4 years ago

I can envision an option to support case-sensitive ids if you want, but the default would not be case-sensitive

adamfoneil commented 3 years ago

my new AO.StringId package would work here, I think.