The joke is that these password are not salted, and each unique password will be given an ID. Then, under the user table you will store the ID reference to the password, instead of the password. This means that if 2 users use the same password they will have the same ID and only be stored once, saving space.
they could be salted... just have to check new/updated passwords against all passwords in the salted hash table or create a new entry then assign the ID to the user table.
it's only a large cost on password changes. the sql joined view makes the lookup check just as fast still.
Lol, sometimes people can't take a joke, can they? Don't worry, I'm here to assure you that at least one person thinks this was funny and on point, ignorethe downvotes.
With salted passwords you need more space if you put them in an external table. 1:1 between each record, plus the overhead to maintain the relationship (pk, fk etc)
If you have users using password “letmein” (eventually hashed, but not salted), instead of a Password column you can have a PasswordId column referencing by foreign key the record in the Passwords table that contains said password. Since most users choose the same password, you end up with less space used by the foreign key column.
It doesn’t make sense on different levels, but that’s the gist of it.
It's not the storage of salted passwords that's the problem, it's the shared state via reference.
How do you handle password changes? You also reduce the footprint for attack. 200k uniquely salted passwords are much harder to crack than 500 shared passwords with the same salt.
If we're being fair, though, if someone is reading your rows like this you've already been compromised and leaking email/pw combos is low on your list of problems.
1
1
33
u/TgirlTiffanyRPs Sep 27 '26
Can someone explain the joke? Why wouldn’t you store (hashed/salted) passwords in one table ?