this post was submitted on 11 Feb 2025
1340 points (98.6% liked)
Programmer Humor
23136 readers
1169 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I'm sure folks on here know this, but you know, there's also that 10K a day that don't so...
What makes this especially funny, to me, is that SSN is the literal text book example (when I was in school anyway) of a "natural" key that you absolutely should never use as a primary key. It is often the representative example of the kinds of data that seems like it'd make a good key but will absolutely fuck you over if you do.
SSN is not unique to a person. ~~They get reused after death, and a person can have more than one in their lifetime (if your id is stolen and you arduously go about getting a new one).~~ Edit: (See responses) It seems I'm misinformed about SSNs, apologies. I have heard from numerous sources that they are not unique to a person, but the specifics of how it happens are unknown to me.
And they're protected information due to all the financials that rely on them, so you don't really want to store them at all (unless you're the SSA, who would have guessed that'd ever come up though!?)
It's so stupid that it would be hilarious if people weren't dying.
Just curious, but if SSNs were not recycled after death, would there be any reason not to use them as a primary key?
They're sequential, so the values above and below yours are valid SSNs of people born in the same hospital around the same time.
This would make it trivially easy to get access to records you shouldn't
Isn't that assuming you have access to doing arbitrary SQL queries on the database? Then you'd by definition have access to records you shouldn't.
No. You can have control over specific parameters of an SQL query though. Look up insecure direct object reference vulnerabilities.
Consider a website that uses the following URL to access the customer account page, by retrieving information from the back-end database:
https://insecure-website.com/customer_account?customer_number=132355
Here, the customer number is used directly as a record index in queries that are performed on the back-end database. If no other controls are in place, an attacker can simply modify the customer_number value, bypassing access controls to view the records of other customers.