As I write this, I am locked out of my 401(k) plan's website because it allows you to reset your password to an illegal string, which fails when you try to log back in. Crappy corporate UX boggles the mind.

Why not? OK I'm no cryptographer, so I'm probably talking out of my arse but why not store a random salt PER user, and the hash of (password + salt)? To an attacker, a one character password will be as hard to crack as a complex one.

A 1-char password can be guessed in as many attempts as the size of the allowed character set, and in half the guesses on average. Even less guesses are required on average if passwords aren't distributed uniformly and this distribution is known (i.e. from previously cracked password databases you know most users pick "e" for a password, so you start with that character and get into the accounts of 40% of all other users in a single guess).

More generally, the average number of attempts required to crack a password with a known length is 1/2 * charsetsize ^ length. So with alphanumeric case-sensitive 1-char passwords the number of attempts required on average is 31. That's not a lot.

The only thing that salt + hash does is make it possible to check the password without having to store the passwords on server; it only serves to protect user passwords after the password (hash) database has been stolen by attackers.

The only way to keep a semblance of security when user passwords are very short is to aggressively rate-limit password attempts, but in the case of 1 char passwords that doesn't help, you'd have to lock the user out after a single wrong password entry, and even then attackers would have a chance of 1/62 (26 lowercase letters, 26 uppercase letters and 10 numbers) chance of getting into your account.

Besides, if you're using the same one-character password for multiple systems, the password can easily be deduced on a system that only uses hashing (or a weak form of salting), and an attacker can use that password to access accounts on stronger systems.