7 ms·

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 onl

by yardie 6y ago

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.

mc32 6y ago
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...
- MCOfficer 6y ago
  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.
  - mc32 6y ago
    “Should“ but do they?
- shakna 6y ago
  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.
mytailorisrich 6y ago
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.
- RandomWorker 6y ago
  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.
gruez 6y ago
>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.
- tomato2juice 6y ago
  > 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/ http://srp.stanford.edu/
  - gpm 6y ago
    Should, yes, probably. Does anyone actually, no, not that I've seen.
  - jaywalk 6y ago
    From http://srp.stanford.edu/demo/ 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.
    - erinaceousjones 6y ago
      > 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/KeyServerProtocol https://wiki.mozilla.org/Identity/AttachedServices/KeyServer...
ceejayoz 6y ago
> 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.
- michaelt 6y ago
  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.
  - ceejayoz 6y ago
    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.
spacephysics 6y ago
Hopefully not SHA-1, see SHAttered. At least SHA-256

by yardie 6y ago

mc32 6y ago

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

MCOfficer 6y ago
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.
- mc32 6y ago
  “Should“ but do they?
shakna 6y ago
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.

mytailorisrich 6y ago

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.

RandomWorker 6y ago
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.

gruez 6y ago

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

tomato2juice 6y ago
> 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/ http://srp.stanford.edu/
- gpm 6y ago
  Should, yes, probably. Does anyone actually, no, not that I've seen.
- jaywalk 6y ago
  From http://srp.stanford.edu/demo/ 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.
  - erinaceousjones 6y ago
    > 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/KeyServerProtocol https://wiki.mozilla.org/Identity/AttachedServices/KeyServer...

ceejayoz 6y ago

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

michaelt 6y ago
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.
- ceejayoz 6y ago
  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.

spacephysics 6y ago

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