They should have been fined more than a measly €20k in my opnion. As a developer I'm deeply ashamed that people are still storing user passwords in plain text. There is no reason behind this behaviour what so ever, other than pure laziness ...
Still stupid, but at least the had good intentions, just bad execution.
[0] https://www.golem.de/news/datenleck-warum-knuddels-seine-pas... (in german)
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?
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...
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
(My password was reset by something/someone, as it contained a '*'; when trying to set it anew, 'star' was a forbidden character...)
It makes you wonder that if there's a team that isn't as rigorous elsewhere (or a team on which pressure has been applied to accidentally leave in some such 'mistakes') what kind of SQL injection possibilities exist.
1. They tried to prevent SQL injection attacks by stopping the page from loading instead of properly escaping data.
2. They failed to actually check if parameters had the forbidden characters they were looking for (they checked the URL, instead of the parameters after they were parsed so all it took was URL encoding an apostrophe)
3. They stored credit card details that they should have never recorded in the first place (including CVV code) rather than just storing the transaction ID from Authorize.net
4. They never bothered to archive old order data even though their ecommerce site didn't even have a customer login and they had absolutely no use for old orders after they were complete.
If you spot that kind of incompetence on something inconsequential from a small team, dollars to donuts they're making the same kind of mistakes with far more serious code. And due to the Dunning-Kruger effect, they're probably too incompetent to realize that they shouldn't be touching anything related to i.e. payment processing or authentication.