Plain:server stores the password, client sends the password - matching is simple. When server is breached, all passwords are known.
Hash:server stores a hash of the password, the type of hash. Client sends the plain password, server hashes and compares. When server is breached, most passwords are known, by way of rainbowtables/brute force.
Salted hash: same as hash, servers additionally stores random salt pr account. Hash is over plain password and hash. When server is compromised, weak/dictionary passwords are compromised via brute force.
Pepered passwords: an additional secret is used for salting. The stored hash now depends on plaintext password, plain salt, "secret" pepper. When server is compromised, most likely pepper is compromised too. If not (eg: only database/backups are exposed), pepper needs to be recovered before brute force of passwords is viable. If the attacker has an account (know a password) it's straightforward to attempt to brute force the pepper, but unless it's weak (eg not a 128 bit random number) - it should not be feasible.
Finally, horcruxing - has nothing to do with server side. Has nothing to do with hashing. Is a simple suffix appended to any given password stored in a password manager, in a INMHO misguided attempt at improved security.
Server sees full password on account creation and login. Seems to suggested to share "horcqrux" cross accounts.
An attacker compromising the passwords stored in the password manager, only gets ~half the password. Need to get the other half via brute force, through compromising another account sharing the same suffix/horcrux, via keyboard logger etc.
A physical compromise of a device with a password manager seem to likely open up for a lot of these attacks.
Note that bitwarden uses 2fa to authenticate a client - but AFAIK if you have a copy of the data/vault - the passphrase is sufficient to get the decryption key.
Horcruxing defends against some odd threats, and otherwise adds more complexity than security IMNHO.
It would be very confusing to reuse this term for what is described in this article, so a new term like "Horcruxing" can be relevant. I like it.
But “client-side peppering” won’t get you to the front page of HN..
Okay, I didn't literally LOL, but you did earn a really big grin and even a chortle. Well done.
BTW, I would totally read "Harry Potter and the Protocols of Security". Some of the "Methods of Rationality" fan fiction by Eliezer Yudkowsky nods in that direction (eg. the Death Eaters' opsec).
If nothing else, "Methods" succeeds in giving agency to more characters, including the villains (not necessarily to their, or Harry's, benefit), and explores/tests the "system" of magic in more depth.
I particularly liked the section where Harry is trying to find out how magic "works". He starts with the gross physicalities: the materials the wands are made of, the sounds of the recited spells. He ends up with the mathematics underlying physics, learning how to create new spells. He uses his new found knowledge to create a very powerful weapon spell he uses to kill a mountain troll. If you want to know how the spell works, you'll have to read the book. I highly recommend it. (I've read it more than once.)
What is a password manager but a database of your passwords? Peppering is a token that is not in the database of passwords that needs to be applied for the password to be correct. Whether it's applied by an application, or a person doesn't seem relevant, as what is an application but a set of instructions a person could do carried out automatically?
I don't care what it's called, but I don't really see a difference in the scenarios you've outlined.
Well, typically a server only cares about verifying the user (still) knows a password.
A typical server (today) does not have a way to reconstruct the plain password, only a way to check if any given string matches.
A password manager, typically does have a way to supply the password.
Peppers and salts are typically manipulated by the server system, plain passwords are typically managed by the password manager.
In this case the password manager never sees the hocrux, and cannot leak it. A server will typically leak a pepper to anyone with access to ram (or access to a hw enclave, which is expected to be more difficult).