Cryptographic hashes generally are selected for avalanche; changing one bit in the input should change about half of the output bits. This won't work as described with normal crypto hashes -- there are some hashes which do "nearness", but they have other tradeoffs.
I wouldn't do any of this, but if you really want to, it's interesting to think about the tradeoffs.
The more sane way to do this is to store some related hashes during original password creation time, or data about the password. The lowest hanging fruit with the least security risk is "is capslock on?" -- Mac OSX indicates this locally in the password dialog box. Next, just knowing the length is probably the most useful thing -- revealing that a 14 character password is 14 characters cuts the search space. This may or may not be acceptable. An attacker exhaustively brute forcing normally starts with "enter" and then moves up to single character, double character, etc. Say it is 4 character numeric only -- knowing it is 10^4 vs. (10^4 + 10^3 + 10^2 + 10^1 + 10^0) only costs you 11%. (obviously in real life you use common password lists, data about the user, etc., but for a 4-digit pin, especially one known to be randomly assigned, this is valid)
The next thing would be some kind of "finger alignment check" i.e. warning you immediately if the first character doesn't match -- maybe revealing the first character of the password, stored independently from the rest of it. Assuming it's random, it reduces the effective length of the password by 1 character -- taking an alphanumeric 14 down to an alphanumeric 13, or 62^14 vs. 62^14. Possibly ok.
I wouldn't do any of this, but if you really want to, it's interesting to think about the tradeoffs.
The more sane way to do this is to store some related hashes during original password creation time, or data about the password. The lowest hanging fruit with the least security risk is "is capslock on?" -- Mac OSX indicates this locally in the password dialog box. Next, just knowing the length is probably the most useful thing -- revealing that a 14 character password is 14 characters cuts the search space. This may or may not be acceptable. An attacker exhaustively brute forcing normally starts with "enter" and then moves up to single character, double character, etc. Say it is 4 character numeric only -- knowing it is 10^4 vs. (10^4 + 10^3 + 10^2 + 10^1 + 10^0) only costs you 11%. (obviously in real life you use common password lists, data about the user, etc., but for a 4-digit pin, especially one known to be randomly assigned, this is valid)
The next thing would be some kind of "finger alignment check" i.e. warning you immediately if the first character doesn't match -- maybe revealing the first character of the password, stored independently from the rest of it. Assuming it's random, it reduces the effective length of the password by 1 character -- taking an alphanumeric 14 down to an alphanumeric 13, or 62^14 vs. 62^14. Possibly ok.