Why would it matter. The password shouldn't be visible to them. If they were doing it right the word "fuck" would be an illegible pile of SHA1 hashes.

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.

>This only proves they aren't encrypting passwords on the fly. And have, and do, the ability to read your password.

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.

> the password is always in the clear when you're attempting an login or you're setting it.

Not anymore. Modern logins should use something like SRP, which doesn't send a password over the wire on every login.

http://srp.stanford.edu/

From http://srp.stanford.edu/demo/ "This demo requires a browser that supports both JavaScript and Java."

There's nothing modern about a system that requires Java in the browser. No thanks.

> The SRP JavaScript demo has been tested successfully under the following browser environments: > > Mozilla 1.x, Netscape 6, 7 > Netscape 4.x - JDK 1.1.5 w/bignum support required > Internet Explorer WindowsNT 4.0 (IE4)

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

That's an ancient demo, I guess I should have linked a modern implementation sorry. More info here : https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...

SRP is good. Apple uses it for HomeKit. The HomeKit pins you use are authenticated by SRP. The page is just a really old demo, the protocol itself is still sound and some have come up with variations for more security.

Also it has the ability to generate a session key.

SRP is... weird.

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.

It's an educational demo for students to learn about the protocol ya nincompoop. The actual protocol is language independent and only really requires that the client do I teeny bit of lifting.

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.

Dude what? I don't think anybody uses that. I've never heard of it before. Just because somebody created a thing doesn't mean it's safe or secure or that we should all switch to it before it gets some solid testing and validation under its belt.

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?

> Dude what? I don't think anybody uses that. I've never heard of it before.

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.

Should, yes, probably.

Does anyone actually, no, not that I've seen.

Requires Java? Was this modern in 2009?

I've written many webapps in my life time with browser and server-side validation. Encrypting is the very first step once the form is submitted. We never knew the password the only thing the library could do is validate it for minimum requirements and compare to stored hashes, that's it. If your password was "CannibalisticBabyRaper42!" as far as the server is concerned it met all the requirements.

> Encrypting is the very first step once the form is submitted

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

Server side, the more you pass around a clear text password the more likely you are to have a security issue. So it’s very good practice to immediately hash any submitted passwords to avoid them ending up in logs accidentally etc.

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.

It's only pointless to hash client side if the server does not also hash.

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.

If you accept that someone could compromise the web server but be unable to modify the website sent then sure. More generally if you don’t trust the other end you should not be using passwords.

If you're using SSL the password is encrypted in transit. Once it reaches the server it needs to be to encrypted at rest. When I see billion dollar companies with an ungodly IT budget not do something basic like salt and hash passwords in the database I have to wonder how they could miss something so basic.

Fully agree that a password should not be manipulated beyond what is absolutely necessary and this is usually just hashing it and getting rid of the cleartext asap.

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.

I’ve been thinking that it could be a great safety feature. If every site had its own mapping then uses a hash it would eliminate simple password matching. If they get access to the database, you could find the password by taking common paswords hash them and do a match. This would not be impossible with the speed of databases. If every site did that it could prevent this line of attack. I can’t really see a bad thing about.

> This only proves they aren't encrypting passwords on the fly. And have, and do, the ability to read your password.

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.

Password length rules are enforced at form submission time, before the account is opened - whereas the twitter post says the account was opened, then permaclosed.

If that's their password length checker, they've got the maddest password length check design I've ever heard of.

That's not what the Twitter post says, at all.

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

Hopefully not SHA-1, see SHAttered. At least SHA-256

Maybe they just have simple hashes (unsalted) of their disallowed passwords and flag hits to them. They compute all the password combos that trash the CCP (and whatever else) and autoban, I guess...

I doubt people were using "Fuck", rather something like "FuckMyEx" or whatever, which has a completely different hash. Also, passwords should be hashed with salt.

“Should“ but do they?

In which case they aren't even salting the password, which means that hashing the password isn't doing a whole heap. It isn't plaintext, but it isn't that far from it.

AT&T prohibits bad words, but it's not "the same thing" as in the story.

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.

> In the story, they gave him no warning that the password was prohibited, or why, and then permanently deleted the account with no recourse.

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

AT&T prohibits commonly used passwords, which includes a lot of curse words.

Why would a company care what you have as a password in the first place?

Probably some overeager dev or maybe somebody higher up not understanding that you should never see a plain text password if you are doing it right.

In this case it seems like a form of thought control. Even if no one else knows your unpatriotic password you can't use it because you shouldn't be thinking those thoughts.

They don't. They care about keeping people opposed to the government off their app.

That's basics of SaaSS.