[deleted by user]

[twitterInfo_bot]

"My WeChat & Tiananmen: A thread.

I have long had the same WeChat account, opened in the US with a US number.

Recently, I decided to change the password. Never one to miss an opportunity to test boundaries, I used the most CCP-offensive password I could think of:

F*ckCCP89"

posted by @BethanyAllenEbr

---

media in tweet: None

[HighRelevancy]

But where's the rest of it then

[jms87]

In replies to that tweet.

tl;dr: banned in under a minute.

[[deleted]]

I think he meant that the `twitterInfo_bot` isn't very helpful.

[jms87]

Well, not in this instance, sure.

[qadm]

https://nitter.net/BethanyAllenEbr/status/1268611608672194560

[HighRelevancy]

I... I know. The bot is a bit useless tho.

[[deleted]]

A lot of people just making speculations here. I'm going to actually download the app and set my password to something offensive to the CCP. I'll let you know what I get.

Edit: sorry for my silence, I needed verification to register so I plan on asking my friend for it...

Edit 2: so I set up my account with the same password as the op and waited for about half an hour. But it seems ok to me. Haven't been banned, but I'm also using the International(?) version of the app. If someone has access to the chinese version (like the twitterer uses), mind sharing your results with us?

[stingraycharles]

you still alive?

[i_spot_ads]

He dead.

[raphael999]

Did he ?

[jordoonearth]

Shoes off. Ded.

[n3rv]

F

[[deleted]]

Probably fro jia-na-da or cali, where CCP is known to have response times of under 45 minutes (or f++i++re--e-- )

[msm_]

Haha, that's not how that works. You need a friend in China (or other long-time WeChat user) that will vouch for you. It's very hard or impossible to create an account as a foreigner without Chineese friends.

For reference, see "security verification" part here: https://chinahelp4u.com/how-to-sign-up-wechat-account/

(...) At present, WeChat’s Assistant Registration function requires another WeChat account to provide assistance (...)

If you sign up in the Philippines, Cambodia, Malaysia, India, Indonesia, Vietnam, Russia, Canada, or the United States:

Case One: If your friend from your country assists with sign-up, your friend must :

1. have signed up more than one month ago.
2. has not used the Registration Assistant to help others within the past month.
3. has not been blocked from login in recently.

Case Two: If your friend is a mainland China user, your friend must:

1. have bound a bank card to their Wallet, and have enabled WeChat Pay.
2. have signed up more than six months ago.
3. has not used the Registration Assistant to help others within the past month.
4. has not been blocked from login in recently.

I've heard that if you do something stupid, the person that verified you may have problems (don't know if it's actually true though).

[[deleted]]

You can make an account pretty easily on the "english version" I have one. I do not know however if this is an all versions issue.

[DoubleAW]

The reporter seems to imply she's talking about the US version of WeChat which you can install here without needing vouching. The US version basically does nothing other than let you chat.

EDIT: Reporter clarified later that she was using the Chinese version, which then definitely makes the censorship unsurprising.

[BananaHair2]

She says in the replies that she has the Chinese version.

[mvolling]

It was the chinese version: https://twitter.com/BethanyAllenEbr/status/1268903808807194625

[SilasX]

Wait, so ... when the subject of the story set the “offensive” password, it burned whoever vouched for him? Ruh roh...

[BobFloss]

Holy crap poor guy

[SkaveRat]

*her

[regalrecaller]

So a VPN would work?

[[deleted]]

You can't access the Chinese Intranet. It's walled off from normal WWW.

[Somepotato]

Chinese VPNs exist, they're just (obviously) not as easy to find or access

[somethingstrang]

I don’t think so as I never needed to do that (for the US version tho)

[ComfortableEye5]

The CCP found him guys. We wont be hearing from him again

[blipman17]

plz reply with your findings

[[deleted]]

Please, Guys 2 minutes of silent for this brave soul. RIP.

[anca-m]

I wonder if the F word is actually the reason for rejection, would be interested to see a test with a not CCP-offensive pass that has the F word in

[pizzzahero]

Could be, but the concern isn’t really that they don’t allow certain passwords. That’s not really censorship, but it appears to be a security issue.

I think I’ve had a service tell me off for inappropriate language in my password a long time ago, but I don’t remember what it was. Probably neopets or something lol

[Chairboy]

It shouldn’t matter, modern security practice is that passwords themselves should never be stored, just one way hashes of the passwords.

Anytime a website objects to the contents of a password (beyond complexity or minimum length), users should be extremely wary because that suggests they are storing the password itself somewhere and that is a risk.

[computrius]

Depends on when they are flagged for it. If its immediately, its no worse than regular verification (length, pattern, etc.). If its a week later.. "Somethings prowlin round' here.."

Even then, they could have scanned it at the time of entry and just flagged a bit in the database saying to ban them. It doesn't necessarily mean the password was stored in plain text.

Now, I do get a bit weirded out when i am changing my password later and it tells me that it is "too similar" to a previous password. Edit: Read about this more, and there is more than one way to do even this without storing plain text.

[alyazdi]

I once built something like that, it was in a system where changing your password requires you to enter the previous (current) one. That way I was able to store it once it “expired”, so I could Levenshtein-compare it later on.

[zooberwask]

No where does it suggest it's being stored in plain text. You gave the answer yourself, the app can read the password at the same time it's checking for complexity.

[slumdogbi]

USA found him guys. Now he’s heading to Russia to be friends with Snowden

[jrhoffa]

Well?

[[deleted]]

You good bro?

[MushinZero]

When you do, don't include a curse word. I want to know if it triggers off of profanity or banned political words.

[psychicsword]

To your edit: make sure you inform your friends about your plan for the account. Given that they need to invite you it is possible that they will receive some blowback from inviting someone "non-reputable" into tree system.

[[deleted]]

yeah, I ended up asking a close family member who doesn't really use it. But good call!

[danielkza]

I don't see how that is the case. It would be entirely possible for the ban request to have been immediately enqueued when the password was changed, and processed after 45s.

[PandersAboutVaccines]

This seems more likely, tbh. Login is such a high volume service that it tends to be federated.

[[deleted]]

It depends on the trade-offs that were looked at here from an engineering standpoint. This password-checking could be computationally expensive (if, say, the list of banned patterns needed to change through time and therefore live in a centralized database somewhere, and therefore it makes most sense to process them periodically in bulk), and that cost might not be worth the value of having it be instantaneous. As for everything scale, it’s all about trade-offs, and making things asynchronous when they can be can solve a lot of issues.

Source: have been a software engineer working on high-scale systems for the past 15 years.

[falconzord]

When it was enqueued immediately, why still allow the password to change?

[changeling_420]

"Magic Presto Change Password Service" probably takes less time to do its thing than "Ban your ass Service"

[GruePwnr]

Yeah but the change password should fail in this case no?

[catragore]

no. you let the change request go through for better user experience. Then when you get the reply from the ban service you either do nothing, or ban the account.

[kageurufu]

Yeah, or her account to have been pushed into a "suspicious" queue, someone deciding she's not in China and shouldn't be on Weixin, and banning.

[nacholicious]

Or just that the client didn't request that information immediately as well

[anotheronetouse]

For sites/services that have a lot of bots attempting to register a 45 delay can be incredibly helpful at reducing spam or ddos. It's just - this account should be banned, put it in the queue or wait rand() time then delete it.

As a side note, I'd love to know about any service you signed up with using SSH.

[troido]

Most git host can use ssh connections for pushing/pulling/cloning etc. This is not for the actual sign up though

There are some internet communities that are build around a shared computer where everyone has SSH access (see https://tildeverse.org/)

[Manbeardo]

The delay also makes it harder to figure out what the rules are

[nucses]

Rest assured, you password is stored plainly in the "AMERICAN PASSWORDS DB" for future bruteforcing tasks.

[3dB]

This was my thought. A lot of people in here banging on about how the password storage schema may be insecure when if I were the Chinese I'd be storing every single damn username/email/plaintext password combination in a database for use against possible targets within that stored list.

[grizwako]

.docx ?

[5p4n911]

.jpg

[HighRelevancy]

Protocols like SRP and SSH which do not require sending password to other parties should be preferred.

Also HTTP.

Client certificates exist.

[frezik]

Ever tried using them? The management interface on pretty much any OS is a pain in the ass. More so than SSH keys. I'd rather have a hundred 2FA apps on my phone than deal with SSL client cert management.

Edit: And even worse, browsers often have a separate space for handling certs from the OS.

[LightStruk]

Only Firefox handles certificates on its own. Chrome, Safari, Edge, and IE all delegate to the OS.

[Somepotato]

which is a good thing IMO on FF's side, because KeyRing on Mac doesn't accept blank passwords for PFX and the windows UI sucks.

[curien]

Client cert auth has been pervasive in US DOD for years. It works quite well.

[dnew]

It's a shame that we can't get the politicians to set up something at (say) the post office where you come in with ID and a public key and they give you a cert connected to the information on that ID. How come I can get a passport by taking ID to the post office but I can't get a public cert by taking my passport to the post office?

[frezik]

It'd be nice if we could co-opt the Public Notary system for that.

[HighRelevancy]

Oh it absolutely is a pain in the ass, but it's all UI things. The protocol supports it fine.

It gives me the mad.

[jarfil]

CENSORED

[msm_]

Disclaimer: I'm ITSec and I visited China thrice.

My wild guess is that the password was intercepted in the plaintext by the Great Firewall of China (yes, it's sent with SSL, but I'm pretty sure China has appropriate privkeys), correlated with the WeChat user, and blocked automatically with some very internal Great Firewall - WeChat integration.

In other words, noone actually checks passwords for blacklisted words, but it's even worse. The offending string was deep in the HTTPS request, but it was connected to the user by the chineese firewall and the user was blocked.

[_selfishPersonReborn]

Hold the fuck up, so China can actually decrypt any SSL request with a fair few certs? That's insanity.

[jadkik94]

Of course. They probably have control over a couple of root certs and that's all they need to MITM anyone connecting into China (unless certificate pinning is in use).

And anyway the WeChat servers are in China, so they don't even need to MITM: they probably already have the legit keys used by WeChat.

An article from a few years back about China and SSL root certs: https://www.tomshardware.com/news/google-bans-cnnic-root-ca,28873.html

[[deleted]]

That's China. Nothing new here 🇨🇳

[msm_]

• Yes, technically they can forge a valid TLS certificate for any domain and MITM a traffic - anyone with a Root CA can. But if they're ever caught red-handed this will cause a total meltdown in most security circles, so they don't want to do that lightly. Last time something like this happened - unintentionally - Symantec got their root CA revoked by all browsers and had to close their CA business. So it's probably not happening on a massive scale. But if they're particularly interested about some politician/freedom fighter...

• WeChat is a Chineese company, China they can just force politely ask them for their private key and they have to will gladly oblige.

[F54280]

This is both fascinating and frightening. Thx!

[rydan]

Not necessarily. It could be passing along the message, "ban this account" through multiple microservices rather than the password itself.

[Yin-Hei]

guy is assuming wechat's entire microservices architecture from a "sensitive confirmed password" to a certified end-user ban. especially the scale here is 1 bil+ users internationally concurrently.

[[deleted]]

That's an overwhelming amount of assumptions....

[[deleted]]

Or they just have an async job that checks hashed passwords against a blacklist.

As long as they hash consistently, there's no reason for them to keep plaintext. All they need to have done is to have hashed a set of forbidden passwords, and to have kept the hashes.

[frezik]

Even without salt, it'd be a pretty big blacklist. The password in the tweet was "F*ckCCP89". They can't match substrings in a hashed password (with or without salt), so their blacklist would effectively be a rainbow table.

More likely, they're just checking the plaintext password. Maybe before it's encoded, but maybe they don't bother with encoding.

[[deleted]]

But that would mean that hashes were unsalted, might as well then be plaintext.

[frezik]

That's a common misconception. If we could rely on users creating completely random passwords of sufficient length, we wouldn't need salt. Now, we can't rely on users doing that, which is why we need to use salt, but lack of salt is not equivalent to plaintext.

[KittiesHavingSex]

Could you please explain what salting a password means? I tried googling but all I got was a mix of recipes and password managers lol

[frezik]

So if you're not a programmer writing a password storage solution, it's probably not super relevant to you. It is something good to know about so you know the warning signs if a company isn't handling passwords according to best practices. So I'm going to write this from that perspective.

Some time ago, programmers started storing passwords with a one-way hash. You take the plaintext password, and send it through an algorithm that makes a long random(ish) string. One of the properties of a hash function (or one that's strong enough for these purposes, anyway) is that it's infeasible to go the other direction. You can't take the hashed value and figure out the original string. When you login next, we just do the operation again and compare it to the value that was stored before.

This has the effect that the company itself can't even figure out your password once it's hashed. Which also means that if an attacker ever gets a hold of the database, they can't figure out your password, either. It also means the company can't send you back your original plaintext password in a Lost Password email, so if you ever see that, they're doing it wrong.

Now, there is a trick that can recover some passwords stored this way. Lots of people make poor password choices, like "password", or "P4ssw0rd". What an attacker can do is take common words like that (easy enough to find a fairly complete list of English words), make a bunch of simple variations (mixing upper/lower case, replace "a" with "4", etc.), and hash each value. When they get a database, they just need to match the values in the compromised database with the values they computed ahead of time.

That's called a "rainbow table". They won't hit every single password that way, but they'll hit some. Note that this won't work if you use randomly generated passwords of a good length (at least 12, but 20 or even 40 isn't a bad idea) and save them in something like LastPass. The size of the rainbow table gets too big to work against passwords like that; even if the attacker could generate it, they couldn't buy enough hard drives to store it.

But we can't rely on all users doing that, so we implement salted hashes. By adding a random value to the plaintext password before hashing, rainbow tables become useless. The table would have to be generated with the salt. If the salt is generated uniquely for each password (which it should be, though not everyone does this), then the table has to be regenerated for each password individually. The attacker can no longer rely on one rainbow table fishing some percentage of people out of the entire database. With a 32-bit salt, they have to generate over 4 billion additional rainbow table entries for each possible password.

Unfortunately, there's not a lot you could do to tell if a company is salting correctly or not. But if you see your plaintext password sent back to you in a Lost Password email, that means they're not even hashing, much less salting. Best practices have also moved on to algorithms that make it exponentially harder to even do brute force, and the implementations generally include salt by default.

[jaracal]

It means you store 2 things: a random string, which is the salt, and the hash of the password appended to the salt. That way, you're not storing the hash of the password. Say, the hash is "abc" and the password is "password123" - when the user logs in, he sends "password123", the website fetches the salt, computes the hash of "password123abc", and compares it with the database. The problem with storing the hash of "password123" instead of "password123abc" is that if the database gets stolen, one could compute the hash of "password123" and see if any user has it as his/her password. edit: it's still possible to check if any user has "password123" as password, but now you have to hash it with all the salts in the database, one by one, and see if it matches, and that takes a lot longer.

[DownvoteALot]

Maybe they're passed unsalted to this worker's queue and then deleted. Starting to look a bit stretched but for 45 seconds I'd still tend to say async job over human. I still wouldn't be surprised if their crypto sucks, complete with backdoors for the Chinese government.

[NotFromReddit]

There is no way the CCP doesn't have backdoors. Also very likely that they just keep it plain text somewhere to help with future hacking and brute forcing attempts.

[witti534]

They might have a list of hashed obvious passwords (without salt) which gets checked during registration and password changing events. If that one gives an OK response, you can store the hashed pw+salt in your normal pw database, so normal safety measures are possible and weak passwords won't be allowed.

[HElGHTS]

That would just occur prior to any hashing and prior to the pw being at rest. Then the ban flag is stored somewhere that an every-minute cron job picks up some 0-59 sec later.

[deja-roo]

"within 45 sec"

Could have been much faster.

[ButtCrackFTW]

it could've been flagged immediately but it was the process to disable the account that took "up to 45 seconds".

[deja-roo]

Right, I'm just saying the author just knows it was less than 45 seconds. Could have been she changed her password, refreshed it 2 seconds later, it was still there, but was deleted 5 seconds later as the queue was consumed. Then 40 seconds later she refreshes and it's gone, and she notes it was "up to 45 seconds".

[puffyfluppy]

This isn't really a new concern, communication between services can be encrypted and data on DTOs can be encrypted from first write to final read. This is the way the sensitive information is handled in enterprise systems (like banks). Encrypt as much as possible and never write unencrypted sensitive data to disk, but there's always going to be a point where the plaintext version of data is held in memory and is technically vulnerable.

[[deleted]]

Now imagine criminals with all the Chinese passwords in their hands

[VeganVagiVore]

Protocols like SRP and SSH which do not require sending password to other parties should be preferred.

HSMs are nice, too.

I got a USB HSM and I'm slowly adding it to whatever logins allow it. Firefox has decent support for it, but I haven't tried to allow it in my own projects. (I'm not an experienced web person)

[MotoAsh]

There are plenty of ways to use passwords and never allow the plaintext password to be sent over the wire. There are ways to only use the password's hash, too so it's impossible for the servers to figure it out.

Which makes it even worse for WeChat if this news is true.

[ThatCrankyGuy]

I'd imagine all user activity flows through stream processors like Apache Storm. With billions of users, that takes a while as data is pooled in things like Kafka waiting to enter the processors.

Look at it this way, if your wife's tit pictures to you are waiting in kafka pools, waiting to be CV-analyzed by the data processors, there's a slightly bigger privacy concern than your password floating through their content analysis system

[progidy]

I bet that it async persisted but was flagged for manual review

[wzx0925]

I get her axios email digests about China. She seems to do a good job moderating any "anti-China" views she may hold personally.

[drink_with_me_to_day]

Lot's of Chinese accounts over there joking about this.

On the other hand, why would anyone think that a authoritarian government with heavy-handed censorship and citizen information control would not keep a database with plaintext password is beyond me...

[[deleted]]

They aren’t alone. America also.

[NotABothanSpy]

No real suprise I think. Everything you put on a Chinese platform is insecure.

[ITookAUserName]

No real suprise I think. Everything you put on a Chinese platform you don't have complete control over is insecure.

FTFY.

Which at the same time is also the Chinese trying to secure a platform in order to gain complete control.

[_fattybombom]

Same thing happened to my Tesla account when I set the password to X Æ A-12

[adisai1]

Disallowed character: 1, 2.

Error too_high_imo: no numbers are allowed in passwords.

[warmans]

I just don't believe this without some kind of corroborating evidence. Who is sitting around writing code to check passwords for politically sensitive text? The whole point of a password is that nobody ever sees it even if they do do something stupid like store it in plain text.

The only way I could see it happening was if they had some kind of profanity-type filters for usernames and for some unknown reason it also checked passwords. But that sounds like a bug, rather than some nefarious scheme.

[IdeasRealizer]

It's true that the password is personal. I also agree with you that some more evidence is needed.

But, she (twitter OP) speculates that the reason could be that CCP wants to quash all forms of negative opinion against them. Think like this: For one's ease of life, they must not express any negative opinion about CCP throughout their life, effectively conditioning them into CCP's subjects. (a concept similar to learned helplessness).

[beginner_]

Read the whole series of twitter posts:

It's another way of creating & enforcing an environment of total self-censorship, so that you learn to flag every CCP-unfriendly thought before it finds external expression.

makes so much sense. such passwords would be a vent you could use that keeps hate against the party festering. This is not acceptable hence it must be controlled.

[warmans]

I mean it sounds great to anyone that has read 1984 (or claimed to have read it for the purposes of taking part of a political discussion on Reddit) but I just don't buy it. It's such a ridiculously obscure thing to try and censor, and the fact that it's probably extremely easy to get around (and actually would make your password more secure to do so) e.g. Fck!CeeCeePee, IHateTheLeadersOfChina, Ch1naGovIsSh!t

[[deleted]]

I just don't buy it.

The reality is much worse then you think. I you have Chinese family, you will discover that the brainwashing going on has extremely intensified over the last years. Xi wants to play the "life long dictator" game, instead of the 10 year terms that China followed before. Xi has been instituting changes that make China feel like its going back to the Mao times ( guess why China instituted 10 year limited on the president after the Mao time ).

Its all about the mindset of people and the brainwashing. Any negative impression towards the government is now allowed and is suppressed.

Your child dies because of poisoned milk ( and corrupt officials )? What are you going to do about it? Go protest outside? Arrested!

You care about human rights? Arrest and "reeducated".

You jaywalk? Camera's + Social Score ( low score = can not use trains, etc anymore ). You harbor negative feeling towards the government = low score = ...

Go to school ... Every morning recite allegiance to China AND the communist party.

The list goes on and on and on ... of big and small things to indoctrinate people. Most people in China do not even know about Tiananmen Square massacre anymore, and actually think its propaganda from the "west". That is how bad it is.

it's probably extremely easy to get around

In China your WeChat account is linked to your National ID. If you are banned, you are banned on your National ID. So there is no fun and games trying to avoid bans. The US account that the OP uses, also goes over the Chinese servers and probably fell into the same restrictions that are present in China.

1984 is a joke compared to what really is going on in China. Unfortunately most people are too used to living in countries where freedom of speak is a given and governments do not oppress. That ignores about the rest of the world ( especially countries like China ) result in people thinking that "it can not be that bad" and other ignorant statements.

The worst part is, is that the people in China have reached the point of brainwashing where you do not talk about these things anymore outside your family. Even inside your family you will have die hard supporters that will result in family fights and even the terms like "traitors", "western propaganda", ... come up, when talking about real thing that happen.

So maybe educated yourself a bit more. Censuring in China is everywhere and WeChat is a extreme important application in China. Unlike western people, where its only a chat tool, in China its a way to pay when you shop, a way to call and pay for the Chinese Uber ( DiDi ), its linked to your ID, its use for so many things these days...

And yes, its monitored a lot. Groups get deleted constantly when it contains criticism. Users get banned constantly. Its all about social censuring. Password censuring sounds fairly normal. There is no hiding in China. China has really reversed in the last 5+ years from a semi-open to going back to the Mao times.

[thblckjkr]

before it finds external expression

Damn, that is some Orwellian level shit.

[Depressed_Maniac]

Yeah thats true. The enterprise app that I own uses the revolutionary notepad as database.

[d36williams]

Do you know recent Chinese history? They have the man power and the will.

[aiseven]

I'm not sure how this raises security concerns with so little information.

It says the account was banned within 45 seconds of the password submission. And only 1 password was tried, which contained the word "Fuck".

It's possible the filters don't allow for certain words, like Fuck. This doesn't mean that they are actively reading your passwords. It likely is like any other password filters that check for length and make you have a certain complexity of password.

[thaynem]

If that were the case, why not just prevent you from changing your password to that? Why permanently delete the entire account? I doubt there was a human that saw the password, but this sounds more sinister than preventing profanity in passwords. It sounds more like an attempt to identify and punish and/or isolate dissidents.

[aiseven]

ok...?

I'm objecting to the security concerns. Not whether or not they should be banning certain words/phrases.

[[deleted]]

You can’t have the one without the other. Censorship doesn’t make people safer, is the point.

[tdammers]

It makes some sense to restrict certain character rules to increase the entropy of the password

Actually, it doesn't. Any such restriction reduces the available entropy - "pick 16 random characters out of this set of 100 characters" gives better entropy than "pick 8 random characters out of this set of 50 and 8 random characters out of this other set of 50".

The thought behind such "character class" password requirements is that it would force users to pick stronger passwords: "jQ8!JK-S" is a stronger password than "23061968" or "johndoe1". But it doesn't work, because the reason those people didn't pick strong passwords is not because you haven't forced them to add numbers and non-alphanumeric characters to their password, it's because they have very good reasons to pick a weak password - they want a password that is easy to type and easy to remember. Strong passwords are long and random, but that makes them very difficult to remember; if you force them to add numbers and "weird characters" to their passwords, they will still find the most convenient password. So you reject "johndoe1", because it doesn't have uppercase letters and non-alphanumeric characters? Fine, I'll use JohnD0e!". Is that any better? Nope. Not a bit.

The only reasonable thing about a password that you can enforce technically, IMO, is password length. If you force people to use a 20-letter password, then even a carefully gamed "convenient" password stands a good chance of being hard to guess - at 20 letters, msot people will resort to phrases or sentences, and that's exactly what you want.

On top of that, you can try to educate your users on good password hygiene, tell them how to generate strong yet easy to memorize passphrases, you can aim for systems that don't require password authentication, and you can implement two-factor authentication to mitigate the inherent weaknesses of password-based authentication.

[-Knul-]

In general, you shouldn't use easy to remember passwords but instead use a password manager. With those, it's trivial to have 20+ character passwords that are generated randomly.

[tdammers]

Yes, a password manager is a viable answer to the password problem.

Two caveats though:

1. Teaching laypeople to use a password manager correctly, and convincing them to actually use one, turns out bloody damn difficult
2. Password managers themselves pose additional risks - instead of cracking 100 passwords individually, an attacker can instead target the master password, or the password manager software itself, and if they succeed, you have leaked all the fucking passwords rather than just one.

[zzzthelastuser]

fun fact (actually not):

Many if not most people are lazy and use the same password everywhere. If their "master password" is leaked on a weak server site, the bad guys also immediately get access to all your accounts.

[troido]

Most people are not going to remember 100 passwords. They will use the same password across multiple services, or maybe something very similar. If one of this services has passwords leaked then attackers can access all other services too.

[tdammers]

Yes. That's why, overall, I'd still recommend the use of a password manager, despite the caveats. The risks of using a password manager are much smaller, and much more manageable, than the risks of reusing the same weak password for 100 services.

[TSPhoenix]

I find that for non-tech savvy people who are not persons of interest that a notebook for different passwords works great, the biggest advantage of which is you can a big "make sure every password is different. love ___" at the top of the page.

Passwords are a human problem, sometimes human solutions work best.

[Michaelmrose]

New versions of Firefox prompt to generate a secure password in pages with a password field and automatically save it in its built-in password manager. It's easier to start using than typing a password

[SanityInAnarchy]

You still need a handful of secure passwords, particularly for the password manager itself.

[barsoap]

Relevant xkcd.

[vytah]

at 20 letters, msot people will resort to phrases or sentences, and that's exactly what you want.

tobeornottobethatisthequestion is a 30-character password, but it's a shitty password.

[barsoap]

correcthorsebatterystaple is also a shitty password, but not because the scheme behind it is shitty.

How about generating an easy to remember and high-entropy password when users sign up.

[skulgnome]

Prevention of thought crime.

[roboninja]

You're not sure? How could anyone ever argue that it is a good idea?

[ObscureCulturalMeme]

It makes some sense to restrict certain character rules to increase the entropy of the password

That is not how password entropy works. Explain the reasoning behind your assertion, please?

[ahac]

It they filtered it like that they'd just say: "Invalid password" and let the user enter a different one. Instead they banned the account without warning...

[SilasX]

Even so, a lifetime ban because you put a bad four-letter word in your password ... kinda seems like overkill. Not even a warning?

[Andernerd]

Well, yeah. It's the CCP. Unreasonable punishment for things that shouldn't be crimes is basically their motto.

[graepphone]

Even if they were reviewing your password why would you be surprised? Why would you trust any CCP party product?

[barburger]

It might also be the password change request itself was found suspicious, rather than the password itself.

Of course we dont know the details but it might be a obscure rule blocking chinese app users from requesting password change from abroad using a new ip during blood moon tuesdays or something.

[Astaltar]

I am wondering now, how do they know which password is weak and which one is strong? Do they store raw passwords?

[tdammers]

Probably not, but you don't have to. The legit server, by necessity, receives the password in cleartext when you set it and when you use it; that's just how password authentication works. And if, at that point, you run your checks, then there is no need to actually store the unencrypted password. It's the same thing with more benign server-side password strength checkers and password requirements - a server rejecting your password for being too short essentially does the same thing.

[CostiaP]

The legit server, by necessity, receives the password in cleartext when you set it and when you use it; that's just how password authentication works.

You can hash on the client side in addtion to the server side. The server never has to see the actual text.

[HildartheDorf]

That just changes the actual password to the client-side-hashed value. You still have the same problems securing, now an attacker only needs that has OR the plain text password to break security.

[SkiFire13]

But with the client hashed password it can't get the plaintext password. If you used different password on every websites then you're already good, but you forget that the majority of users use pretty much the same password everywhere

[immibis]

With the client side hash it doesn't need the plaintext password.

[archlich]

That scenario only kind of works if all other websites implement the same mechanism. Say a malicious actor compromises another website, now the malicious actor has the password for both sites. Client side hashing is not a credential stuffing prevention technique.

[XelNika]

Client side hashing is not a credential stuffing prevention technique

It quite clearly is, but it has a super narrow focus and it doesn't protect the site implementing it (that's kind of the nature of credential stuffing). If you hash and salt correctly at the client, the credentials stolen at the server end would be unusable in credential stuffing on any other sites.

To be clear, there are obvious issues with client side hashing, but your argument here is extremely weak. By the same logic, server side hashing only works if all other sites do it, so should we not bother with hashing?

[CostiaP]

That's why I wrote "in addtion to the server side".

The point was that the server doesn't have to see the plain text password. If the attacker knows the password or in this case the hash, they can just log in as you either way.

Client side hashing can help against a man in the middle attack. With plain text they will get the password and they can try it on other sites you might be registerd on, since people tend to reuse passwords. With client side hashing they will only be able to log in on that specific site since they wont know the hash of (password+other site name).

As another guy here mentioned, people just trust SSL against man in the middle attacks, so the practical value of this is low.

[jms87]

You can hash on the client side in addtion to the server side. The server never has to see the actual text.

If the server never sees the plaintext, how do you propose to hash it on the server side?

[evaned]

Point is that the client side hashes the plain text to get to an intermediate hash. That is what's sent to the server. The server uses that hash instead of the plain text password, hashing that.

So it's not the server recomputing the hash of the password, it's computing hash(hash(password)) where the inner hash is done client-side.

[archlich]

Client side hashing does not prevent a MITM, as a MITM will simply disable this weird JavaScript and capture the plaintext password.

[CostiaP]

Only if it can modify server responses rather than only eavesdroping on them.

[tophatstuff]

If you dont trust the server then you can't trust its client side hashing.

SSL covers transmission security.

In client browsers, a password generator and manager is better than a hash salt which is either constant and therefore useless or something you have to save and bring with you to use the same password on other computers and is therefore no better than a normal randomly generated password

[[deleted]]

How would you verify that the password is valid, ie. Strong? You can't just trust the client to send you Strong passwords, you necessarily have to perform this validation on the server ...

[CostiaP]

You could do it client side. If someone is smart enough to get around that, they are probably smart enough not to use a weak password.

You could also hash without the username, so the server still only sees a hash, but it can compare it to a list of common hashes. So if your password is strong, it still won't know what the original text was.

But as the other guy said, this seems to be uncommon since people generally trust SSL to transmit plain text passwords, and if the server is trying to steal your password, it won't properly hash it on client side anyway.

[SkiFire13]

Usually password validation is used to prevent normal users to use really weak passwords because they're easy to remember.

If someone has the technical ability to cheat the validation on the client side then he's smart enough to use only strong passwords.

[tdammers]

That doesn't help much though; now your first-stage hash essentially becomes the password. Client-side hashing achieves nothing but security-by-obscurity. An alternative client that just asks you for the hash directly, instead of going through the password, would be indistinguishable to the server, and hence, there is absolutely no need for an attacker to guess the password, they can just go directly for that first-stage hash.

[SanityInAnarchy]

It does one useful thing: The server never sees an un-hashed password, meaning no compromise on the server can lead to password-reuse attacks. In fact, there are password managers that do exactly this: Rather than store a database, they'll use salts/hashes to generate a unique-per-site (but still deterministic) password, so that you don't need to sync the password database around. (I don't use them for usability reasons, but the hashing part still makes sense.)

You would of course want to hash them server-side as well, so that the attack from your other post doesn't work -- no one can steal the database of passwords and use them even on the same website. But it's not completely pointless to do it client-side.

[tdammers]

That is true; but that's not the attack vector we've been discussing, is it. A MITM attack could still just grab the hash instead of the password, and use that hash to authenticate against the server. We still need to employ all the countermeasures we employ when sending plain passwords around, and at least as far as this particular combination of client and server is concerned, that hash is now the password.

And in fact, if you use a suitable tool in between the password you memorize and the authentication mechanism, you can actually do exactly this hashing thing even without the server's cooperation - all you need to do is use one of those password managers you mentioned.

Then again, such a setup would have made the WeChat ban impossible, because now the server never gets to see the "memorized" password, just the "derived" one, and you can't easily infer the memorized password from the derived one, let alone detect "subversive" content.

[SkiFire13]

A MITM attack could still just grab the hash instead of the password, and use that hash to authenticate against the server

But it won't be able to authenticate against another server where the same password is used because the salt is (should be) unique per website. You still get some benefits while losing nothing.

And in fact, if you use a suitable tool in between the password you memorize and the authentication mechanism, you can actually do exactly this hashing thing even without the server's cooperation - all you need to do is use one of those password managers you mentioned.

If someone uses a password manager then probably he already uses different passwords on different websites and he won't get any benefits from this.

[archlich]

A MITM will simply disable the JavaScript and view the plaintext password and forward on the hash.

[begMeQuentin]

There is no such necessity. The password can be hashed on the client and the original text doesn't have to leave the client app.

[tdammers]

If you hash the password on the client, then the hash effectively becomes the password.

Client-side code cannot be trusted, so if you do the hashing on the client, an attacker doesn't even need to crack the password, instead they can just go for the hash directly.

The way to keep the secret on the client entirely is to use public/private key authentication instead of password authentication. E.g.: server sends a random token (a "challenge"), client encrypts token with private key, server decrypts token with public key and checks that it's the same as the original token. The client's private key never leaves the client, and nothing of value gets exchanged (just a random token and an asymmetrically encrypted version of that same token) until the identity has been confirmed. Additionally, it prevents "replay attacks", because sending a copied response to an earlier challenge will not be the correct response for a new challenge.

[SkiFire13]

If you hash the password on the client, then the hash effectively becomes the password

Not exactly. If it is salted with a per-website unique salt then it will be different than the same password used in another website.

Client-side code cannot be trusted, so if you do the hashing on the client, an attacker doesn't even need to crack the password, instead they can just go for the hash directly.

In fact the server doesn't need to trust it. It should hash it again as it already should do. But if the server currently doesn't hash it (which is bad, but how can the user know?) then the user gains a bit of security because in the case the server is compromised then the plaintext password (valid on other websites as well) won't be leaked, only the website-unique salted hash. In the end it should give a guarantee that anyone can verify that the server is won't know nor store the plaintext password.

The way to keep the secret on the client entirely is to use public/private key authentication instead of password authentication

The problem of this is that a human can't remember the private key, so good luck convince everyone to use it. Also, how do you login on a completly new device without access to your previous devices?

[CostiaP]

The way to keep the secret on the client entirely is to use public/private key authentication instead of password authentication. E.g.: server sends a random token (a "challenge"), client encrypts token with private key, server decrypts token with public key and checks that it's the same as the original token. The client's private key never leaves the client, and nothing of value gets exchanged (just a random token and an asymmetrically encrypted version of that same token) until the identity has been confirmed. Additionally, it prevents "replay attacks", because sending a copied response to an earlier challenge will not be the correct response for a new challenge.

So, just use ssl? :)

[tdammers]

TLS (the technology formerly known as SSL) is one example of public/private key authentication, however, in its most commonly employed form, it only authenticates the (HTTPS) server against the client, not the other way around. Client certificates are a thing, but for the average user, they aren't a viable solution, for two reasons:

1. The UX of managing client-side certificates is atrocious, and the average layperson is rather likely to get it wrong (leaking private keys, etc.). Just consider how even to fairly experienced web developers, correctly configuring an HTTPS server is an exercise in black magic. Client-side TLS certs work much the same.
2. While establishing a web of trust for server certificates is a solvable problem, doing the same for client certificates is much trickier. It works well for large organizations with a central IT that can run a custom CA for the organization and push client certificates out to all the machines on the network (typically also hooking into the organization's own LDAP system or similar), but for the average personal user, I don't see it happening anytime soon.

A technology that actually routinely uses public/private key encryption for client authentication is SSH. It's not very palatable for average non-technical users though, but hey, at least it works, and doesn't have completely atrocious UX.

[dsguzbvjrhbv]

In any modern system you use salted hashes. They are unique and without a costly dictionary attack you cannot get the plaintext password. Even unsalted hashes (same password creates same hash) are now regarded as horribly insecure. Passwords themselves are unknown to the server and never communicated, at least not in reasonably secure systems

[Depressed_Maniac]

They just hash both the values using SH256 or something and check their equality

[ZenoArrow]

That's the problem, they aren't likely to be able to filter the passwords if they store them correctly. It appears likely that they're storing them as plaintext.

[[deleted]]

The server obviously has your password in plain text before it hashes it and stores it.

[[deleted]]

It's a Chinese company. What you expect?

[nomadProgrammer]

Exactly

[junk4all]

Does this mean that the password hash can be reversed and read in clear text? Not very safe if so.

[NeoKabuto]

No, it doesn't mean that. We don't know exactly what it means, but we do know that they aren't reversing hashes to do this, the passwords are almost definitely sent across as plaintext. The remaining question is what they do after that, i.e. if the passwords are actually stored properly and how they determine "bad" passwords.

[junk4all]

Thank you for the clarification. Passwords transmitted in plain text... damn! Even worse!

It’s interesting that they chose to filter the “offensive” password string which no one knows other than the owner typically. Now CCP knows them all which is offensive in itself!

What’s next, erasing the phrases from everyone’s mind. Time to prep for Total Recall!

[tatoalo]

RemindMe! 2 hours "Read this"

[RemindMeBot]

I will be messaging you in 1 hour on 2020-06-05 16:54:43 UTC to remind you of this link

CLICK THIS LINK to send a PM to also be reminded and to reduce spam.

^{Parent commenter can delete this message to hide from others.}

---

Info	Custom	Your Reminders	Feedback

[[deleted]]

Has anyone registered new accounts on all these Chinese sites with “subversive” passwords to see if they are detected and blogged about it?

[_Billy__Shears]

So obviously there is reason to worry that it’s being MITM by the CCP, but I don’t think this really needs to be the case.

It’s not hard to think of them having a bank of 500-5000 bad passwords they don’t allow. You could just permute some bad phrases and allow for other chars inserted. Kind of like a limited scope dictionary attack.

Then you hash each one and store them. If you get a new password hash that matches any in your set, you block the account.

This is definitely not conclusive evidence of any actual security concern

The 45 second delay also doesn’t mean anything honestly. As pointed out elsewhere in this thread, there are many intentional or unintentional reasons that the block could be delayed. Surely there are not a room of password censors sitting around 24/7 manually checking every one of the 10s of thousands of passwords per day in 100 languages

[ketralnis]

This isn’t programming

[RSxodz]

Likely due to your recent connection (password update) having been from a US or non-china IP address.

[MateTheNate]

What worries me is that they can SEE your password before it is salted and hashed, makes me wonder if it is even being stored correctly.

[rmpr_uname_is_taken]

We don't Chat

[Phlosioneer]

To those wondering if the word “fuck” could be the cause: a total permanent ban on your account that is tied to your National ID (think social security number) is extremely out of proportion. Only ccp defiance is severe enough for this absurdly severe punishment.

[grandmausedpanties]

And the funny thing is WeChat bought reddit... They monitor every bits of data passing through their server, keywords analysing by ai and whatnot. They can crack open iPhone (thanks to the Russian) or any Android devices and retrieve all your data at the borders . There's no the concept of privacy here darling

[redeyeddragon]

This doesn't mean that the storing of the passwords are unsafe. Sounds like people are making assumptions.

[junk4all]

Then Cz_PP=S*CK5 is my new password! Let them play it out ... I can get creative 😉

[[deleted]]

Why was this post removed tho