Implement Pepper for User Authentication

[DavidRieman]

Right now, if an attacker manages to get access to the DB, they can get user salts and hashed passwords, and could then potentially brute force their way into other user accounts. One simple way to help mitigate this is for part of the hashing process to be further hidden (called a "pepper"). This helps because (like 2FA) an attacker who got access to the DB is still at least severely hindered in cracking rate if they did not also figure out how to get ahold of the pepper.

The risk to having pepper though is that if an admin changes it after accounts were created, or the pepper gets lost or maliciously deleted, then no existing user accounts will be able to log in anymore. So for this ticket, we need to:

• Carefully consider options. ATM I'm leaning towards starting with a well-documented App.config property with a short starting value like "Pep" and adding markdown documentation about it (and the impact should it change after user accounts exist) in the detailed admin section.
• Implement the feature.
• Ensure through telnet that new users can still be created, quit, reconnect, and log back in with their username+password.

[DavidRieman]

This might be a "good first issue" for someone who already has some understanding of the related security principles. (TBH, I'm no security expert myself. If anyone wants to add context to confirm/refute this idea, or add good study links here, they would be welcome.)

[DavidRieman]

Did some reading and decided we don't want to pepper. Mainly per: https://stackoverflow.com/questions/16891729/best-practices-salting-peppering-passwords