5 ms·

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 pl

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?
nmca 6y ago
Plaintext post over https is quite common no?
- hunter2_ 6y ago
  Yes. Don't let anyone make you believe otherwise.
hunter2_ 6y ago
Plenty of very secure identity providers allow for a list of banned words. Typically you populate the list with things like the name of the app/website/business, the user's name, etc. (rather than vulgarity/dissent as seen here). There is nothing insecure about doing a dictionary comparison right before hashing for storage or regexing for strength constraints.
- rhacker 6y ago
  And these banned words somehow do not stop registration immediately? And these VERY secure identity providers then later show the admin what password was attempted? I would say that's extremely insecure if not a huge privacy violation for something to be considered "very secure", and would definitely not have any form of sign-off from anyone that keeps up to date with OWASP security practices.
  - hunter2_ 6y ago
    Each of those is putting words in mouth and I am on your side for each. Yikes.

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?

nmca 6y ago

Plaintext post over https is quite common no?

hunter2_ 6y ago
Yes. Don't let anyone make you believe otherwise.

hunter2_ 6y ago

Plenty of very secure identity providers allow for a list of banned words. Typically you populate the list with things like the name of the app/website/business, the user's name, etc. (rather than vulgarity/dissent as seen here). There is nothing insecure about doing a dictionary comparison right before hashing for storage or regexing for strength constraints.

rhacker 6y ago
And these banned words somehow do not stop registration immediately? And these VERY secure identity providers then later show the admin what password was attempted? I would say that's extremely insecure if not a huge privacy violation for something to be considered "very secure", and would definitely not have any form of sign-off from anyone that keeps up to date with OWASP security practices.
- hunter2_ 6y ago
  Each of those is putting words in mouth and I am on your side for each. Yikes.