When the breach was announced, they revealed that they did not store the passwords themselves in plain text, but had a second store that did, so they could prevent users from posting their passwords in chats. [0]

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)

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?

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

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...

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)

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.

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

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

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

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

This just goes to show that badly designed security measures can be worse than no security measures at all.

Laziness implies you know the right thing to do but don't do it due to the extra effort. I'd put this more likely down to incompetence.

So you think that someone who's capable of building a system like this, has somehow missed the fact that you should store passwords safely? Nah, I don't buy that.

I do. You do an online tutorial, and together with bits of code from Stack Overflow you can tie together APIs, including payment processing APIs relatively easily into what you want. You don't read the documentation, you just google till you get the code you want from SO, so any warnings in there are lost. Your boss is on your back about it and you're on your 4th straight 20 hour day, so you just do whatever to get the result your boss requires.

I'm sure that Orange (Telecom) does that as well for Consumer password. "Technical debt" probably.

(My password was reset by something/someone, as it contained a '*'; when trying to set it anew, 'star' was a forbidden character...)

I find this kind of error the most unsettling, it implies the people writing the authentication system don't trust the underlying ORM/database sanitisation layer (if there even is one!) enough, so to 'play it safe' they manually filter out 'suspicious characters'.

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.

I was once doing some SEO work for a client and noticed something similar. Any URL that contained an apostrophe would return a completely blank page. I asked my manager if I could spend a little time investigating that as a security vulnerability that would have been out of scope for the project and within 45 minutes I had a working SQL injection proof of concept that would return credit card details from their order table.

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.