I'll un-shorthand my comment since it wasn't understood too well, sorry about that. If it was password-strength validation, then it would have been blocked imm

I'll un-shorthand my comment since it wasn't understood too well, sorry about that. If it was password-strength validation, then it would have been blocked immediately during signup, with an error message that would have prevented the sign up flow altogether. The alternative flow that I'm calling the "weirdest shit ever" would be letting the user sign up without a password error which would mean they are logging the password in plain text for manual review later. You're both not actually making the password rules set during the registration process, but you're also manually logging the password so someone can see it in plain text. That's why it's the "Weirdest shit ever" especially if this code was written by a security person. > What do you mean by "security of the regex"? Let's say you use the regex on this page: https://mkyong.com/regular-expressions/how-to-validate-password-with-regular-expression/#:~:text=Whole%20combination%20is%20means%2C%206,a%20strong%20and%20complex%20password https://mkyong.com/regular-expressions/how-to-validate-passw.... If I suddenly want to add words like "fuck" or "f*ck" to the regex as banned words, the complexity of that already complex regex goes waaaay up, and it compromises its validity/stability. If you worked on regexes in the past that have multiple alternative flows, it's very easy to fuck it up and make it accept anything. It's not a good idea to change a regex to have stop words because it has a high chance of breaking the regex itself. Again however, it's highly unlikely the password was blocked in the password regex step because it allowed signup to continue. > And you're saying that they'd prefer to store the passwords as plain-text out of concern for the "security of the regex"? No I wasn't saying that they prefer to store the passwords in plain text. I was saying that it's 10000 times more likely that the password is stored in plain text IFF (if and only if) the reason for the ban was because of the password. How would they ban the user if they didn't see the password, because of either a logged file or simply stored plain text in the database. And the reason it's likely to be plain-text database is because it's probably the number one first approach to store a username password combination. Even though WeChat is a huge company it honestly wouldn't surprise me if they are not using a salt and hash or bcrypt directly at this point. Yes I get that most people you know would use bcrypt or a salt/hash combo, but when you open to the world of all developers, specifically ones in China, what do you think the default user table is going to look like?