What if it was just because of the F word?
AT&T does the same thing.
https://gizmodo.com/why-at-t-wont-let-you-swear-in-your-pass...
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.
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 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.
Does anyone actually, no, not that I've seen.
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.
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.
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.