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.
It's possible to do that without storing the passwords in plain text though! Run each word of the chat though the same hash+salt mechanism and compare to what you have stored.
Assuming they're using a suitable hashing algorithm for passwords (ie, Argon2, bcrypt, scrypt, PBKDF2), this approach would be prohibitively expensive, especially for a chat platform, with presumably lots of messages.
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.
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.
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.
But what if people have multi-word passwords? At that point the solutions become so over-engineered(either use some ngram-like setup to detect passwords being posted or save a hash for each separate word of the user's password, which also decreases security since then you know the user has a multi-word password) that you might as well drop that feature.
That significantly reduces entropy in the password.
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.
Give them a big scary message "Never give out your password to strangers" when the censoring happens, because it's highly likely somebody is pretending to be an admin asking for a password in that situation.
I thought the same, although such a filter would be intended to help out unknowing users who might give their password to a stranger. People who use passphrases may know enough to not do that in the first place.
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.
What if this is part of someone's policy, with the knowledge of users of course? For example an app for the technically illiterate or for small children?