Be that as it may, it doesn't explain why WeChat appears to be storing or transmitting plaintext passwords. That's incredibly alarming, if true. As are the implications of such a design.
In the mediocre, they are sent to a server-side app and hashed without being analyzed, and stored in their hashed/salted state.
No good service analyzes your password server side, much less for the offensive nature of your password.
edit: Okay, I suppose there can be some analysis of password strength server-side before hashing at rest. Still, it should not be analyzed for the social acceptance of its content.
What does this protect against?
- The actual password being known to an attacker who can read everything but the client-side state.
- The password has a high chance of being used at other sites as well, so preventing attackers from knowing the password on this site, also prevents them from using it to attack other sites.
But:
- It does not protect against determination to get an authorization token, which is the client-side hashed password that the server sees.
- It does not protect against an attacker who can modify the code which the client receives and runs.
So that string is valid only once.
If the hash in the backend is the only thing you need to calculate the salt challenge, then it is the equivalent of a plaintext password. Someone with access to dumps of a compromised backend database can use the hash directly.
[1] https://blog.cryptographyengineering.com/2018/10/19/lets-tal...
If the password 'Superman' is stored as text in this configuration file I need to fix for a user, there's a good chance I inadvertently learn their password is "Superman" and I may remembers this for hours or days even though I did not set out to learn it. Maybe I half-forget and think it was Spiderman or something, and this wouldn't happen if it was 16 alphanumerics chosen at random, but it isn't.
Whereas suppose the file obfuscates that password with Base64 and stores U3VwZXJtYW4= my brain doesn't see that and realise "Huh the user's password is Superman" or even "The user's password is U3VwZXJtYW4=" it just goes "Some gibberish not important to the current problem" and an hour later I couldn't tell you what it was.
There are a bunch of things we do not because they stop malevolent people from doing evil, but because they avoid tempting good people to be naughty.
They might also want to check it against a list of most used passwords.
Look at it from the state's perspective: You have nearly unlimited control over your population, but you still can't read their minds. Given how common password reuse is, why wouldn't you track everyone's passwords in case you want access to data stored on systems that aren't already integrated into your sweeping surveillance system?
That the banning came with a short delay makes me guess that they scan all input to their app, indescriminately. They just send all keystrokes to their censorship server and check them there, and apply penalties if neccessary.
The reason they would do this is because WeChat is actually many apps in one. Third parties can embed mini apps as HTML pages in their profiles. For example, when in China I used a WeChat applet to control a coffee vending machine. In order to monitor content in every app, it makes sense to just blanket scan the inputs. Someone brave could test this by typing offensive things into some text field but not submitting them.
edit: I'll take back most of my comment here because it was admittedly hard to read and slightly out of context.
> blocking specific words is extremely unlikely because it would probably compromise the security of the regex itself.
What do you mean by "security of the regex"? It's not like the regex is supposed to be some kind of secret.
And you're saying that they'd prefer to store the passwords as plain-text out of concern for the "security of the regex"?
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-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?
I am not suggesting that this is what WeChat does, but I think it is possible to have a blacklist without plaintext transmission.
Assuming they want to check against all casing combinations, the list of hashes would be 3 orders of magnitude bigger for a list of 7 letter words. If they want to check for substrings or spelling variations, list would combinatorially explode.