[Someone]

Store the length L of the password, its salted hash H, and its bytes, XOR-ed, X.

For every message typed, compute a running XOR of each sequence of L bytes (2 XOR’s per character, so as good as free). Whenever it equals X (about once every 64 letters or so, because typical text doesn’t use all bits in each byte equally), compute the salted hash of the last L characters, and compare with H.

Unicode and Unicode normalization will complicate that, but I think it should be fast enough for a chat.

You probably can also improve on that factor 32 by storing multiple XOR-like (but slightly more computationally expensive) hashes and computing multiple running totals.

Given that this is to protect users from falling for scammers who claim they need their password to help them, you may be able to run it on the user’s machine.

I fear, however, that a scammer will just ask them to type their password with a space inserted, spell it in the NATO spelling alphabet, or whatever. If you fall for a scammer, that won’t stop you from giving them your password.

[donaltroddyn]

I did think of similar approaches, but anything I could think of that helps you to quickly determine if a given string contains the password also helps an attacker if the passwords and salts are compromised.

In the suggested case, storing the length of the password alone massively reduces the search space, and storing the XOR (of the plaintext with the hash, I think you're suggesting?) negates the value of using a hashing algorithm suitable for passwords, since the point is that checking if a password matches a hash is an expensive operation.