6 ms·

The Axios journalist who did this, Bethany Allen-Ebrahimian, is a huge thorn in the CCP's side - one of the most outspoken, widely read, and retweeted media cri

The Axios journalist who did this, Bethany Allen-Ebrahimian, is a huge thorn in the CCP's side - one of the most outspoken, widely read, and retweeted media critics of China's domestic policies and international activities. 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/1263469429435883521 https://twitter.com/BethanyAllenEbr/status/12634694294358835... 2. https://twitter.com/BethanyAllenEbr/status/1268223947939745792 https://twitter.com/BethanyAllenEbr/status/12682239479397457... 3. https://twitter.com/BethanyAllenEbr/status/1206358641424683009 https://twitter.com/BethanyAllenEbr/status/12063586414246830... 4. https://twitter.com/BethanyAllenEbr/status/1265793205628555264 https://twitter.com/BethanyAllenEbr/status/12657932056285552... 5. https://twitter.com/BethanyAllenEbr/status/1096165952264331264 https://twitter.com/BethanyAllenEbr/status/10961659522643312...

echelon 6y ago
> I believe her WeChat account was very closely monitored, more than the average Western user. 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.
- xur17 6y ago
  I suppose it's also possible they are checking the submitted passwords against a blacklist before storing.
  - rhacker 6y ago
    Pretty unlikely. That would be the weirdest shit ever. This reeks of plain-textifying a password, probably running through https, but rather either logged in plain text when the auth code is running or, and this is even more likely, they are storing the passwords in plain text. That's 10000 times more likely than checking a blacklist or running a banned password regex list. It definitely is likely there is a regex for password constraints but blocking specific words is extremely unlikely because it would probably compromise the security of the regex itself. edit: I'll take back most of my comment here because it was admittedly hard to read and slightly out of context.
    - jolmg 6y ago
      What are you talking about? It'd be similar to password-strength validation. Why would that be "the weirdest shit ever"? > 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"?
      - rhacker 6y ago
        I'll un-shorthand my comment since it wasn't understood too well, sorry about that. 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-password-with-regular-expression/#:~:text=Whole%20combination%20is%20means%2C%206,a%20strong%20and%20complex%20password 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?
- jakear 6y ago
  They can be transmitted encrypted over https and still readable by the server. It doesn’t make a ton of difference if you encrypt client side, whatever the client sends is “the password”, encrypted or not.
  - unethical_ban 6y ago
    In the best of systems, client-side encryption/hashing occurs. 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.
    - jakear 6y ago
      > In the best of systems, client-side encryption/hashing occurs What does this protect against?
      - jlokier 6y ago
        - Accidentally recognisable passwords in logfiles, tracefiles, network dumps, HTTP request traces, HTTP proxy coredumps. - 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.
        jakear 6y ago
        So instead of the attackers/admins seeing your password, they see a string of characters that, when delivered to the server along with your account id, grants access to your account. Hm.
- deleted 6y ago
  [deleted]
- sn41 6y ago
  Does it need to be plaintext though? Just a theoretical possibility: They can maintain hashes of potentially offensive passwords. You then need to just compare hashes. This is somewhat like registering all domains which can harm your reputation yourself, before anyone else does. I am not suggesting that this is what WeChat does, but I think it is possible to have a blacklist without plaintext transmission.
  - zeeZ 6y ago
    This only works if the password hashes aren't salted
  - hunter2_ 6y ago
    But you just do the comparison before hashing.
  - acituan 6y ago
    > They can maintain hashes of potentially offensive passwords 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.
- qwertox 6y ago
  Even Google transmits the password in clear text in the POST request (secured by TLS).
- captainmuon 6y ago
  I believe they are doing something more sinister than storing a plaintext password. Why would they even check the contents of it? 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.
- bradly 6y ago
  Don't most login forms do this? I assume they just scan all input coming in the same regardless of the field type.

echelon 6y ago

> I believe her WeChat account was very closely monitored, more than the average Western user. 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.

xur17 6y ago
I suppose it's also possible they are checking the submitted passwords against a blacklist before storing.
- rhacker 6y ago
  Pretty unlikely. That would be the weirdest shit ever. This reeks of plain-textifying a password, probably running through https, but rather either logged in plain text when the auth code is running or, and this is even more likely, they are storing the passwords in plain text. That's 10000 times more likely than checking a blacklist or running a banned password regex list. It definitely is likely there is a regex for password constraints but blocking specific words is extremely unlikely because it would probably compromise the security of the regex itself. edit: I'll take back most of my comment here because it was admittedly hard to read and slightly out of context.
  - jolmg 6y ago
    What are you talking about? It'd be similar to password-strength validation. Why would that be "the weirdest shit ever"? > 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"?
    - rhacker 6y ago
      I'll un-shorthand my comment since it wasn't understood too well, sorry about that. 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-password-with-regular-expression/#:~:text=Whole%20combination%20is%20means%2C%206,a%20strong%20and%20complex%20password 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?
jakear 6y ago
They can be transmitted encrypted over https and still readable by the server. It doesn’t make a ton of difference if you encrypt client side, whatever the client sends is “the password”, encrypted or not.
- unethical_ban 6y ago
  In the best of systems, client-side encryption/hashing occurs. 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.
  - jakear 6y ago
    > In the best of systems, client-side encryption/hashing occurs What does this protect against?
    - jlokier 6y ago
      - Accidentally recognisable passwords in logfiles, tracefiles, network dumps, HTTP request traces, HTTP proxy coredumps. - 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.
      - jakear 6y ago
        So instead of the attackers/admins seeing your password, they see a string of characters that, when delivered to the server along with your account id, grants access to your account. Hm.
deleted 6y ago
[deleted]
sn41 6y ago
Does it need to be plaintext though? Just a theoretical possibility: They can maintain hashes of potentially offensive passwords. You then need to just compare hashes. This is somewhat like registering all domains which can harm your reputation yourself, before anyone else does. I am not suggesting that this is what WeChat does, but I think it is possible to have a blacklist without plaintext transmission.
- zeeZ 6y ago
  This only works if the password hashes aren't salted
- hunter2_ 6y ago
  But you just do the comparison before hashing.
- acituan 6y ago
  > They can maintain hashes of potentially offensive passwords 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.
qwertox 6y ago
Even Google transmits the password in clear text in the POST request (secured by TLS).
captainmuon 6y ago
I believe they are doing something more sinister than storing a plaintext password. Why would they even check the contents of it? 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.
bradly 6y ago
Don't most login forms do this? I assume they just scan all input coming in the same regardless of the field type.