What are the security risks of logging the hash of rejected passwords?

If properly hashed (i.e. with random salt and strong hash) a hashed password is not reversible and hashed passwords for different accounts differ even if the passwords are the same.

This means that almost none of the analysis you want to do can be done with the properly hashed (i.e. random salt) passwords in the first place, i.e. you gain almost nothing from logging passwords and at most you lose since you leak some information into places where an attacker might get easier access since logs are usually not considered as sensitive as stored passwords.

When using a plain hash instead (no salt) some of the things you mention are possible at the cost of an increased attack vector since now an attacker can use pre-computed hash tables to reverse your logged passwords.

Maybe you have some misconceptions about what proper password hashing means. I recommend reading How to securely hash passwords? to get an idea how proper password hashing is done and why it is done this way but in the following I will address some of the misconceptions you seem to have:

Check if it is just typo : if a user often failed login at first time with the same hashed password but later it logs in successfully, then it is possibly just a typo

You cannot check a typo using the hashed passwords since even a small change on the input results in a huge change in the output. You also cannot check for the typo in the original passwords since you cannot reverse the hash to get the password for comparison. To check if the entered wrong password is always the same you could log the hash salted with the same salt as the stored (correct) password as Jon Bentley suggested in a comment. If the logs are at least as well protected as the stored passwords then this would only slightly increase the attack surface, but as I said logs are commonly not considered as sensitive as password storage.

... Some common passwords, just like 123456 and birthday, which has fixed hash, ...

Proper password hashing uses a random salt to make attacks using pre-computed hashes with common passwords impossible. This means that the same password results in a different hash when it gets hashed, i.e. your assumption of these passwords having a fixed hash is wrong. Again, you could use the more easy to reverse unsalted hashes here at the cost of an increased attack surface.

It might instead be better to do that kind of analysis when the entered password is still available and only log the result of this analysis.

... if a user usually failed to login with the same hash, and the hash is the same as another account but then login successfully, ...

Since hashes for the same password differ you need the originally entered password to do this kind of comparison. Since you cannot get this back from the logged hash it does not help to have the hashed password logged. Again, you could do this kind of analysis with unsalted hashes, but this would mean that all of your accounts must have their password available in the insecure unsalted way - which is a large increase of the attack surface. You could probably do this kind of analysis with salted passwords too but then would need to log the newly entered passwords salt-hashed with all the salts you currently have in use (i.e. one for each account).

This is not a common practice, and goes against security in general. IMHO, none of the reasons you list are good enough to log hashed passwords. In fact, I can’t think of a good reason to log them. You might run into compliance/legislation issues (PCI for example). Users typically fail passwords by typos, forgetting which password they used for which site, etc. You also will have these passwords in a place other than your database, even a remote server if you are using some sort of logging via syslog.

None of these are reasons to log hashed passwords. To answer your question directly, it is “better” to log hashed passwords compared to plaintext ones, but both are very bad and should not be done.

Example: Part of HIPPA focuses on the need to adequately and effectively protect Electronic Protected Health info (ePHI) by adhering to good and standard practices. According to the auditor I work with, logging passwords (hashed or otherwise) would leave you as incompliant because it is not a recommended and standard practice.

You're making many assumptions about:

• The usefulness of these actions.
• That hashing and storing the passwords are the only way to achieve those actions.
• Even that some of those actions can be gleaned from a properly salted and hashed password.

If a user fails a login, it could be for many reasons. For example, it might be because they have multiple passwords and are cycling through them, wondering which they used on the site... now you went from storing a (salted) hash of the users password for that one site to potentially multiple (salted) hashed passwords that the user tends to use. Similarly with emails, I have multiple emails I use, I may not recall which I used for the site. Now, you're storing my emails to correlate them (this portion depends on your correlation of password to user logic). Basically you're making a compendium of usernames/emails and password combinations for a potential future adversary of your site. Some of your ideas:

"Check if it is just typo"

Why do you care? If it is a typo, the user made a typo and figured it out. If your goal is to develop fingerprinting to tell an attacker brute forcing, there are other ways. This also isn't possible with a properly salted and hashed password. That is the very goal of salting and hashing, you, yourself, shouldn't be able to reverse engineer what the original plain text was without considerable effort. If you don't have the plain text and the hashing algorithm is good, you will not be able to achieve telling if a typo was made.

"Check if there is someone trying to guess password"

First, make sure actual users don't have these passwords. Second, there are other methods. Third, if you really wanted to, you could in stream hash the input and compare it to hashes of known weak passwords, if so, then log that it matched, there is no need to log the password in any form itself.

"Check if a user have alternative account"

Unless you have a an explicit reason to do so, something that goes against your terms, this is unneeded from a user standpoint. Further, a properly salted and hashed password will not be immediately comparable to other records in your system. That is the point of salting, so pre-computed hashes of various plain text inputs can't be matched. Thus, if someone did have the same password across two different accounts, that hash by the notion that the salt added to them is random, will not match regardless. Even if they did match, it could be an entirely different user with the same password or a password that is one character off (typo, or password variation).

The very idea pretty much violates every security notion that exist. I would not recommend it.