[crazygringo]

Huh, that's actually... a decent-sounding intention.

Is there any way to do that in a secure manner? Because a hash says nothing about the length of a password (and you certainly don't want to store the length, which would make the attack space much smaller)... so if passwords are anywhere, say, from 8-64 characters, then for each chat message you'd need to hash every possible consecutive string of characters for every possible window size separately, which if the hash is even remotely computationally intensive could possibly turn into too much -- especially if being done on the server instead of the client (in order not to expose the hash and salt).

Is this just something it's not possible to protect against?

[y7]

Easiest way is to do it on the client. The client has the plaintext password anyway.

[crazygringo]

Good point.

But is storing a plaintext password, even on the client, good practice? E.g. in a browser that uses a cookie with something like a session ID to make sure you're logged-in... is storing a plaintext password in localStorage considered a valid security practice? I would have assumed not, although it's certainly not close to as bad as storing it on the server...

[xianb]

if you store plaintext password on the client, you'd be one XSS attack away from potentially having a lot of passwords stolen - best practice is to have password in plaintext for a little as possible (there's some research on not transmitting the password at all but I don't think there's anything widely accepted like bcrypt is for password hashing https://en.wikipedia.org/wiki/Zero-knowledge_password_proof)

[UncleMeat]

You are already one xss attack away from having your session stolen or having your credentials stolen or any number of other bad things. Passwords on the client are fine.

[anoncake]

Unless the user uses the same password for other things, which is extremely common.

[judge2020]

Storing the length is somewhat secure, as GSuite does it so administrators can audit who has strong passwords https://judge.sh/j0mMsLU.png

[xianb]

anything that makes computation less intensive for you also makes it less intensive for a potential malefactor - it's just an inherent tradeoff.

Rather than scan for password being contained in the message, something more reasonable to try would be to check if the whole message is the password since you can just plug that into the normal password hasher and run just one slower hash op

[kiriakasis]

or forbid password from having white spaces and only check at word boundaries