WeChat permanently closes account after user sets offensive password
twitter.com
twitter.com
- open up private browsing
- press F12 (or however you get the developer console on a mac) and go to the networking tab
- go to gmail.com say
- enter your gmail credentials
- look at the post request generated, and at the request tab, it will contain your password in plain text
So passwords don't get hashed on transit, this is why having HTTPS is so crucial, which is to prevent someone in the middle (say when you connect to an open Starbucks wifi) from sniffing out your unencrypted password. The password on the server side initially can be unencrypted before it gets hashed to be stored into the database. So in this instance, the password in the database is hashed, but there is a small period where the password is plain text in memory.
For a site called hacker news, it's really sad how little people here know about hacking.
I appreciate they where trying to protect passwords & promote security, but it definitely caught me off guard that this wasn't widely understood.
I think you meant "don't get"
Hashing in the client leads to a fair share of security issues, especially if it's not also hashed on the backend using the usual salted hashes.
There are protocols like SRP to do it securely, but it's non-trivial. And remember that such protocol is only useful if you trust the client implementation—it's kind of pointless for a third-party webpage or app.
Use randomized per-site password. Solves everything.
I've yet to see someone give a good reason to not hash on the client and the server... I would be curious to hear if you have any.
It's definitely non-standard though.
It might protect the password if the user is reusing it elsewhere, but it doesn't protect the account the password is securing during the intercepted transmission.
The MITM attacker can just replay the hash.
I can't see a reason why this hurts, but it's probably not worth it. The only benefit I can see it having is if the user reuses their passwords on other sites, as now a potential malicious MITM would have to brute force the client side hashed password in order to reuse it on other sites. They would still be able to use that client side hashed PW to authenticate to the service in question, though.
Basically, hashing on the client does absolutely nothing for the security of the transfer or storage of the password. Whatever the client passes to the server, whether it's hashed or not, is effectively their password, and intercepting that (again, whether hashed or not) would give an attacker the actual credentials of the user.
There is zero downside to doing an extra hash, except the chance that someone codes such a basic thing wrong.
But only if neither site uses salt, so salt all your hashes. (Not even a salt is necessary here, just a site-wide addition would be fine. Or honestly you could just use a hash that wouldn't be used by a site too dumb to salt their database.)
If you want secure password transfer, do not construct a ghetto solution with stacked hashes, but use a proper protocol like SRP (which, again, is pointless unless the client is trusted).
Especially in the case of Twitter, doing this provides absolutely nothing in respect to credential confidentiality as both sites of the transaction is written by Twitter.
"Assuming an attacker has broken TLS" - this makes no sense. If I had broken TLS, I could send you a login form with no hashing. I could modify your legitimate API requests, without the need for your credentials. I could take your token and forge requests as I wanted. All your assumptions go down the drain, as the security relied on the presence of TLS.
Basically, making this setup is generally harmful, while only providing negligible benefit in a doomsday scenario where all bets are off regardless.
If you truly want to have better security, you need an entirely different system. E.g., local private keys used to sign requests, or a proper password exchange/validation protocol. Smacking another hash on top does nothing good, and the idea is a good example of why normal people shouldn't crypto.
I agree with you on the general pointlessness of client hashing, though, and oh what a world if we had pub-priv keys for authentication instead of passwords...
The main issue is that security analysis is non-trivial due to the interaction of their security guarantees. The end-result is effectively a new hashing algorithm. Figuring out the properties of this new algorithm requires a new cryptoanalysis (which is more than just avalanche tests).
> It also flies in the face of common in-practice schemes (pre-bcrypt) like doing n rounds of sha256. There should be no real problem with doing the first round on the client.
Old practices are deprecated for good reason, primarily due to flaws. Looking at what we used to do it not that useful.
The main problem is that it's not just "n rounds". The hash on the client must be salted, and it must be salted uniquely for that credential set, and must use a different salt from the backend hash. Plenty of ways to mess this up, and that's before we're even consider the implementation details of salting.
Then comes the interactions between likely different hashes. All in all, it's pretty complicated.
> I agree with you on the general pointlessness of client hashing, though, and oh what a world if we had pub-priv keys for authentication instead of passwords...
Especially with the only sensible procedure being password managers, it's silly we don't have asymmetric authentication. :(
If it's true, the attacker just has to do additional hashings to crack the password.
Passive sniffing requires the same attack vector, and the idea of an attacker only utilizing passive attacks makes no sense.
The point is that additional hashing designed for the premise of "broken TLS" fails the thread model test: It is pointless, as the only time it is applicable is when everything is fallen apart.
Are thinking of encoding / decoding? If so it isn't used for passwords.
this obviously does not eliminate the need for other security measures, so it's possibly more a question of "is it worth it?"
If you're trying to argue that the user puts in, say, 60 bits of entropy, and that the hashing algorithm is going to accidentally throw out 10 of those to result in 50 bits of entropy, I believe that any hashing algorithm that did that in a way that anyone can exploit with realistic computing power (a computer smaller than the size of the solar system) would be considered irredeemably broken.
And then: By the password not leaving the system you avoid another issue with humans: If the hash is lost (accidental logging and locks leaking and such things happen) this won't allow to sign in to other accounts, where the lazy human used the same password.
For machine-to-machine communication tokens with higher entropy can and should be used.
2. It provides no additional security in the authentication process.
3. It provides no additional security-at-rest for post-breach protection.
Doing something like that ends up in the dangerous bucket of duct-tape crypto. I don't mind people playing with crypto, but things are not as simple as they seem, and "more" is not necessarily better.
Sure, if you're foolish enough to not hash on the server side then you're setting yourself up for failure. But I fail to see what the problem with hashing on the client side is?
Use SRP or similar if you need private password transfers (which again is still pointless if the client isn't trusted).
You shouldn't be sending passwords in any form over unencrypted HTTP, and there isnt a clear case for hashing or obscuring the password over HTTPS.
Hashing the password on the client limits the password entropy to entropy of hash you generate. Any addition entropy in the original password is thrown away.
Also naive hashing in the client just turns the hash into your password, all of the standard issues of transmitting passwords still exists (such as replay attacks as you mention).
This has nothing to do with client vs server. SHA1 of STRING will always have the same entropy wherever it is computed; it must, for the hashing to work.
EDIT: I suspect you are confusing PRNGs or KDFs with hashing. Entropy is relevant with the former, not the latter.
I'm not clear why you think this would be so. Hashes (with salts) prevent attackers from being able to derive the password, and can also be used in conjunction with nonces to prevent replay attacks.
You need both parties to know the nonce and the salt for this to work, so you’ll need to send it over. At this point what value are you gaining over just sending the password?
I get the impression you don't understand what the nonce and salt are, so I'll break it down.
The salt is used to make the hashes for particular values unique to this site. It generally does not change across the site, but it makes it impractical to use pre-computed hash tables to find the original values for a given hash. By using a salt, the site ensures that transmitted hashes cannot be trivially reversed.
The nonce is used to allow the use of an HMAC to create a one-time hash that cannot be reused. This would typically be implemented as follows:
1. Service sends NONCE, SALT
2. Client Sends password as SHA256(SHA256(ClientPasswd + SALT) + NONCE)
3. Service Computes SHA256(StoredSaltedHash + NONCE), confirms that it matches what the user sent
4. If the two match, the user is authed.
An attacker cannot reuse what the client sent because the nonce is not reused, and he cannot fake the nonced hash because he does not know either the password or the StoredSaltedHash.
There's essentially rainbow tables computed for "123456"+RandomSalt iterating over salts. There are a bunch of them covering the most frequent passwords. Since you are using the same salt for the whole site, two users with the same password have the same StoredSaltedHash, so you order by number of repetitions, and the most frequent is likely one of those ("123456" tended to be the most popular the last time I checked). This exposes your salt and then it's game over.
What I'm trying to get across (and failing apparently) is that this is still vulnerable to lots of attacks, which means that you'll have to use HTTPS underneath all of this. Once you are doing all of this over a HTTPS connection, there's simply no point in doing it, you are just increasing the attack surface for no substantial gain in security.
This is only an issue if the hash can be reversed. The entire raison d'etre for salts is to prevent hash reversal via precomputed tables.
>There's essentially rainbow tables computed for "123456"+RandomSalt iterating over salts
Rainbow tables are already enormous-- in the hundreds of GB range for 9+ character passwords. Iterating over the range of possible salts makes the storage requirements untenable.
As long as you choose an unlikely or unique salt which could simply be your site's FQDN or its MD5 hash, this isn't an issue. No one is going to have a rainbow table for md5(yourFQDN.com) as salt.
>which means that you'll have to use HTTPS underneath all of this
You should but it is not necessary for secure password transmission. This is a solved problem for decades now.
>Once you are doing all of this over a HTTPS connection, there's simply no point in doing it, you are just increasing the attack surface for no substantial gain in security.
Layered security is a thing. Root CAs can be compromised, trusted CA stores can be tampered with, SSL busters like CRIME or BEAST can show up on the scene, someone can gain network access behind the SSL termination.... Layered security is why when LastPass got popped nothing of value was lost, because they used legit KDFs and salts.
There's no increase in attack surface for using an HMAC behind SSL. If SSL is your only line of defense, your security model is stuck in the 2000s.
If password is sent over HTTP in plaintext, then password can be used in a replay attack.
Of course you can also do a dozen other things with it, such as attack other sites.
And of course this flaw is trivially rectified by having the site send a nonce.
In other words you can combine salts + hashes + nonces to both eliminate the server's need to know the password and the possibility of a replay attack.
Recovering whatever the server has stored is typically going to be sufficient to authenticate the user, but storing it as a hash mitigates some threats.
Put plainly, nonces are countermeasures specifically for replay attacks and they work.
E.g., if your user-agent does it all for you, you could consider it trusted, but if all the code is provided by the "untrusted" service-provider that you won't want to see your password, it ends up just being for show.
Similar situation with ProtonMail: As long as you use the clients shipped by them (webmail, app), all of the security hinges on nothing but a promise. Their app can read the passwords and keys as much as it wants.
I also found out that protonmail doesn't seem to send the password in plain text in the post request itself. Really keen to see how they do it as well.
Allen-Ebrahimian has focused on the crackdown against peaceful pro-democracy protestors in Hong Kong and the dismantling of "one country, two systems" (1), genomic surveillance of ethnic minorities in Xinjiang (2), and Huawei (3), among other topics. Last week, a CCP mouthpiece publication labelled her an "anti-China journalist" for her work (4).
She also uses WeChat for research (5).
I believe her WeChat account was very closely monitored, more than the average Western user.
1. https://twitter.com/BethanyAllenEbr/status/12634694294358835...
2. https://twitter.com/BethanyAllenEbr/status/12682239479397457...
3. https://twitter.com/BethanyAllenEbr/status/12063586414246830...
4. https://twitter.com/BethanyAllenEbr/status/12657932056285552...
5. https://twitter.com/BethanyAllenEbr/status/10961659522643312...
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.
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?
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.
They might also want to check it against a list of most used passwords.
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.
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.
[1] https://blog.cryptographyengineering.com/2018/10/19/lets-tal...
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.
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.
At the time, (most) every store in the world had a 56k frame relay network connection back to the Bentonville, Arkansas home office. The main purpose of this connection was to do various credit/debit/EBT,check/etc authorizations.
Stores in China had something additional: a fractional 56k frame link, the far end terminated by some other entity.
Normally, in store point of sale systems sent authorizations to the then named VISA system in Bentonville. (It was called VISA but it handled most electronic transaction types. It was replaced by a far more robust and generalized system called E-Pay shortly thereafter.)
In China, the POS systems also sent the transactions across that other link.
We didn't know officially who was on the other side, but it was widely speculated that it was the Chinese government.
My knowledge of these things is nearly 20 years old now, do take my recollections with a grain of salt. Also, I have no idea how this setup has subsequently evolved.
Someone is probably watching closely what this reporter is doing.
I've seen worse user experiences.
But yeah lets just go with the passwords are in plaintext and she's a journalist beijing doesn't like as the only possible outcome. Thats the explanation I'm going to go with when Facebook security reviews blindside my new accounts and close it unilaterally.
AT&T does the same thing.
https://gizmodo.com/why-at-t-wont-let-you-swear-in-your-pass...
This only proves they aren't encrypting passwords on the fly. And have, and do, the ability to read your password.
Honestly, I don't know why anyone uses WeChat. In China it's a requirement but for any other reason give it a hard pass.
Not really, even if you have password hashing, the password is always in the clear when you're attempting an login or you're setting it. They can simply run the detection system then, without loss of security.
Not anymore. Modern logins should use something like SRP, which doesn't send a password over the wire on every login.
There's nothing modern about a system that requires Java in the browser. No thanks.
I have a feeling that the page referenced is not so "modern" :-)
BUT, that doesn't make it a necessarily bad protocol for modern browsers to be implementing, i.e. as part of their "identity management" stuff, like Firefox Sync [1].
Remember that the Stanford Java applet implementation was purely academic, intended as a demonstration and developed at a time where JavaScript was too limited for the large number arithmetic they wanted to do (no BigInteger equivalent).
That purely academic implementation does not invalidate the work itself, or future implementations thereof.
[1] https://wiki.mozilla.org/Identity/AttachedServices/KeyServer...
Also it has the ability to generate a session key.
The good news is that using SRP is definitely not worse than DH as a key agreement protocol.
The bad news is you probably already have a nice modern ECDH key agreement protocol, you wanted secure passwords and the proof for how SRP does that involves a lot of flailing about. Flailing about which so far reached SRP version 6a
If browsers and backend stacks and everything else was one config change from doing SRP 6a tomorrow it's tempting to say hey, go ahead it can't hurt.
But in fact SRP is very niche, so it makes at least as much sense to try to deploy OPAQUE or other things that have a clearer security rationale.
On any client where you can run code you can authenticate without ever sending your plaintext password over the wire. And on clients where you can't run code you can still accept the plaintext password as a fallback.
I don't see any plugins or libraries to add to any of the huge number of exiting authentication libraries. Has it even been subject to a hostile security audit? Has it been put in a place where it will face a serious state-sponsored attack and performed at least as well as existing systems?
Ya, the first time I heard of it I had the same reaction, but it's legitimate.
https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco... That page is quite old, but lots of bodies use it: http://srp.stanford.edu/links.html
Amazon uses it in a service: https://docs.aws.amazon.com/cognito/latest/developerguide/am...
Also, as another commenter said, Apple uses it in Homekit.
Does anyone actually, no, not that I've seen.
I've never worked on a webapp that did this, though I have heard of it. What's the point, really, if you're using SSL? If you don't trust the server then don't use the service
It’s pointless client side. Trusting the clients hashing of a password is the same as using a clear text password. Aka some admin or hacker learns the hash they can use a modified client to send the hash directly.
Hashing on the client what the user actually types and sending that hash to the server which then treats that hash as the password can help in the case of users that construct similar passwords for different sites.
A user who uses passwords of the form "<site>.19%Gkm19^GB", for example, would normal be sending "gmail.19%Gkm19^GB" gmail, "twitter.19%Gkm19^GB" to Twitter, and so on. If anyone one of those gets compromised there is a good chance they all will be.
If the sites had a first step of client siding hashing then the password that gmail sees is "0d156132c43e7110b5d678eafd7117b5a4649fbf" and the one twitter sees is "cfd9d7f62b92eb025a242bc860d41aae60ebeacf". One of those getting compromised on the wire or at the server doesn't put the other at risk.
However, it is difficult to draw any conclusions from a tweet.
The author is a journalist covering China so she might already had performed various 'tests' on her WeChat account that raised various red flags for various reasons until her account ended up being flagged for deletion.
If they are really checking cleartext passwords against 'offensive' keywords they are impressively thorough, tbh, but it would still seem odd to delete an account just like that instead of rejecting the password so I'm thinking that there is more to her story, if it is true.
Not at all. They could simply be checking against rules before hashing the password. Pretty much any passworded system already does this in order to enforce minimum length rules.
If that's their password length checker, they've got the maddest password length check design I've ever heard of.
> Recently, I decided to change the password.
and in a subsequent tweet:
> Within 45 SECONDS of me changing the password, my WeChat account was permanently closed.
Nearly instant, likely automated based on that timeline, and immediately after a "change password" form submission.
In the story, they gave him no warning that the password was prohibited, or why, and then permanently deleted the account with no recourse.
That's pretty different from "oh we don't allow that, pick another one", even if the latter is also annoying.
/She/ is also a well known journalist who could easily have had her account being monitored. Other people on that thread claimed that they changed their password to the same and nothing happened.
I read the top 3 tweets there. She doesn't say how, within 45s, she was informed of the account closure?
If she just couldn't login, for example then it could simply be she mistyped the password.
The narrative of how she just suddenly decided to check if writing FuckCCP89 in the password field would cause any effect seems distinctly unlikely. If she had a tip-off that it would have an effect, then fair enough; but she should note that and add credence to her story.
Not convinced.
I'm not sure we can determine the verity of it.
- password goes through filter check onSubmit and some flag is set on the account immediately, it's added to a queue, pw is hashed and stored
- "account moderation" worker picks up task from its gigantic queue of Chinese accounts that need some automated action taking on them, bans account, notifies user, does whatever else needs to be done when closing an account for a service like WeChat
Edit just to remark: a lot of people commenting on this thread are making some pretty big assumptions about both what apps do do and should do with passwords.
In my experience, you can more or less say this: most companies and applications in 2020 do hash passwords before storing them in the database.
Beyond that, all bets are off.
To be clear, I wouldn't bet it all that the passwords are stored in plaintext. But I would bet it all that the CCP has their own special key and/or backdoor access which allows them to continue having omnipotence and omniscience while keeping pesky foreign powers out.
I doubt it. The CCP is bad, but it's also pretty rational. Doing this would just be dumb.
My first foray into options trading I lost around 3% of my net worth, and I'd say I'm more than twice as confident about this than I was about that.
I'd evaluate the odds of the CCP doing something, to be in line with the odds of them benefiting from doing something, regardless of the expense/risk to their populace.
There's nothing I'd really put past them, we know for a fact they harvest organs from political dissidents, but we're skeptical on if they'd store passwords plaintext?
Given people tend to re-use passwords, I'd imagine having a massive trove of plaintext passwords for all Chinese citizens, or even anyone who communicates with them, would be incredibly useful.
Not to mention the fact that they have to maintain a list of anti-CCP passwords, which would be a tedious process, or they'd have to automate something to detect anti-CCP sentiment. I think an interesting experiment would be to see what less obvious anti-CCP passwords get you banned. With enough probing and data, I'd possibly increase my wager to 10%.
As a well known and outspoken critic of the CCP, she might be elevated to the status where they actually just have a person reading everything she types into WeChat 24/7. Do you think they fully staff the night shift, or would the ban have taken twice as long outside of Chinese business hours?
Would I bet that the Chinese Government has this properly implemented and can't access passwords once set? Yeah no way.
Just in terms of security policies this is nuts.
Inspecting the political contents of passwords is nuts and tyranny.
Inspecting the contents of passwords at all is nuts and spectacularly bad.
Like choosing business associates based on their politics, just at a larger scale.
Evaluating a passwords' strength or complexity is incredibly routine.
Because the CCP is a totalitarian state with an interest in controlling expression, even in passwords?
Just because WeChat does numerous, dislikable things, doesn't mean they monitor passwords. Or did this.
Is there like only one xi jingling in the whole china? If not, what at others supposed to do?
Change their surnames
And why would you do fuckery with a journalists password? Seems like especially stupid thing to do
Surely the least likely of all possible explanations, but an easter egg blocking passwords that are variations of "I refuse to cooperate" would be a hidden artistic statement in its own way.
Would you trust the third party that flagged this as offensive:
F*ckCCP89
Edit: given that her account was permanently deleted after just 45 seconds, I actually think some party member working at WeChat is monitoring her activities in real-time. The password probably get him angry enough to push the permadelete button.
Would a native Chinese speaker even have that visceral emotional reaction to English profanity? I'm curious about how that impact translates.
I'd also assume they'd assign the english speaking North American dissidents to a monitoring person who speaks good english.
Also, I have hard time seeing an automated system that deletes someone's account including all data for using the f-word in their password.
People reuse passwords, so its likely that WeChat passwords allow access to other systems (like Facebook, Twitter, Alibaba, Amazon,...)
This attack angle of just collecting passwords for government has not yet occured to me before.
And then people getting surprised from where do those ginormous plaintext password leaks come from.
All kinds of popular online forum engines were being hacked for password captures since times immemorial. PHPBB still uses server side hashing for example.
Now, for people concerned, take a look who was the party who sank crypto forms at W3C.
Direct access via the companies themselves is probably much more valuable today.
In the case of China in particular we know that part of the "Great Firewall" have IP addresses associated with Chinese residential ISPs, whether those are "hijacked" or the relevant agency just asks nicely we do not know. So it may be that "Chinese central government intelligence agency" and "My neighbour's WiFi" are similar IP addresses if you live there.
But yes multi-factor authentication can reduce the impact of credential stuffing attacks.
WeChat service will receive the password in plaintext. It's able to do processing on that plaintext value.
It is likely storing a hashed version of the password in the database.
At some point all passwords are plain text, be it on the client or whatever, they could simply check it before it is encrypted and stored, even on the client end if they wanted to.
In the OP case it could be many factors added together that led to the banning.
This underscores how precious and fragile the freedom of speech is.
As has already been stated, multipled people have tried what she did (myself included; just tried with a spare SIM)and we have not had our accounts banned.
WeChat also has little reason to ban someone a private password because that can hardly be considered a communications risk (it's not like her password is being publicly posted for everyone to read). It seems much more likely that her account was closed for reasons outside of this password change.
A few months later I also uninstalled all Facebook related apps from my phone.
Close out accounts randomly and see if someone tries to rationalize it in a disgruntled manner. If you're a Western agitator you'll complain. If you're a proper patriotic member of the CCP you'll understand that it's all for the good of the Party.
Jesus. Did I just write that?
What a world we live in where that isn't unreasonable. Then again I really shouldn't be going and giving places ideas I suppose.
"g̶o̶d̶ the ccp works in mysterious ways"
That means hackers can break in to WeChat and leak all the passwords.
>Fwiw just changed my wechat password to the same one bethany used just to test this, continue to be able to use it without incident.
https://twitter.com/BethanyAllenEbr/status/12687275190517473...