They were doing this so they could filter out the passwords from chats (i.e. to make it so users can't give out their passwords to other users). Not saying this justifies it, but it's interesting.
They were doing this so they could filter out the passwords from chats (i.e. to make it so users can't give out their passwords to other users). Not saying this justifies it, but it's interesting.
Also, the premise is faulty, because as soon as users figure out they can't type their password in the chat, they'll just describe it in words or split it into two pieces etc.
It could however in general have a problematic side-effect if the password is a common word that could be guessed from surrounding context when censored that way. Something I'd find a lot more likely here than passwords with spaces.
Also, you probably can't just try hashing each word, since there could be whitespace and punctuation in the password text, so I think you'd have to hash all possible substrings of each message to be able to reliably catch passwords.
Obviously, though, they shouldn't have been storing them in plaintext.
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.
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.