Or a fake phishing company email that asked employees to log in. That would expose employees who were a high security risk as well.

My guesses would be that either:

• They conducted an employee survey where someone admitted the company name being a substring of a password they use.
• They used some rudimentary bruteforce methods which matched salted registers or logins (say "Company name123456".)
• Instead they meant that it is possible to create passwords with the company name in it, but transmitted it poorly.
• Some of the passwords are unsalted.
• The passwords are logged somewhere else.

It goes without saying that if they found a vulnerability with the hashing or salting, it should be highlighted on its own, and in any case it wouldn't do damage to ask them directly.

Can I take the opportunity to ask a question?

I work at multinational EU company, we run windows/office for the enduser. There are many parallel systems, some running linux or whatever but that’s besides the point

But there was this audit, performed by an external company, at request of the holding (mother company) that revealed unsafe passwords that contained company name in it. According to the auditors that’s a big no no

My question is: how tf do they even find out that the passwords have some specific string in it? Is it not being salted? That would surprise as our IT/network management team is very capable, and relies on windows tools that should be safe to begin

Just how?

My guess is that it is a vulnerability because it was probably vibe coded

lol seriously, that is wild. Basically asking to be exploited.

Seems like they're advertising a vulnerability pretty loud there

Unfortunately there's a huge number of MySQL servers that are using latin1 charset and collation, even when storing Unicode data. Surprisingly it "works" as long as your DB client treats the data as raw bytes (ie you don't do any sort of string manipulation in MySQL), the same way that UTF-8 "works" in PHP even though native strings are just raw bytes.

,Obviously sorting and filtering won't take any sort of case insensitivity / case folding into account though, which is an issue.

I hit issues with this recently at work, because for some reason all our MySQL servers still use latin1 by default. Unicode characters were getting corrupted in JSON columns, because MySQL forces them to use utf8mb4 as per the JSON spec (JSON sent between multiple systems should always be encoded as UTF-8), and mixing "real UTF-8" with "fake UTF-8" (UTF-8 in latin1) doesnt end well.

My guess would be that they are sanitizing them, but their WAF blocks requests with particular characters in these fields in order to try and block SQL injection or something.

One of the big four banks in Australia (Westpac) used to limit you to a password of EXACTLY 6 characters, case insensitive. Another one (NAB) required 6 to 8 characters, case insensitive, with NO special characters.

Thankfully they've both changed these limits.

NAB no longer has a length limit, and they're actually planning on completely removing passwords in favour of passkeys. Westpac allow up to 30 characters now.

Ȟ̵̯͉͖̼̝͓͔̗̬͇̜̜̜̽̄̅͐̅̃̊̀͆̆͌̅̍̈̅̾̄͛̍͆̓͑͌͆̒̊̂̈̋̍̐̐̾̀̀̉̓̓̕͘̕͝ṵ̸̧̧̡̢̢̧͇͇̙͇̬̳̣̺͇̳̖̗̪̖̤͇͇̙̗̜͈̫̠̖̻͖͙̗̘͍̠͓̫̯̳̦̼̩͈͇̑̂̑̈̈̈́̓͗̈́̍̀̑̐̀͂͒͐̓̽́͛̏̈́̈͒̀̎̆̂̍͐̚͘̚͜͝ͅͅn̸͙͔̮̝̭̅̓̏͝ţ̵̧̧̡̟̯̭͔̼̖͉͔͍̟̞͎̰̪̼̤͈̝̠̜̗̩̬̤̺̗̥̖̽̿̑͂̉̿̓̆̕͠ͅȇ̷̡̢̞̣̪̼̮̖̟̝̼̤͚͍̰͉͉̥̟̹̱̼̮͚̂̂́́͛̆̊̆̀̂̂̄̔͐̆͌̾̌̓͆̇̽͒͘͘̕͜͝͠ͅr̶̨̛͚̳̗̮̟͉̤͎̺̺̮̤̯͇̹̖̮̯̣͔̺͉̝̠̞͇̖̗̮̪͕̗͇̱̣̪̤͎̰̤̻̘̱͈̀̀̄͐̀̊̀͗͑̃̈́̉̈́͋̑̀̇̓̉́̈́͋͑̉̓̏̏̕̕͠ͅ4̷̢̛̰̗͕̻̭͎͚̟̤̥̗̙̭͙̎́͊̎͆̍̂̑̄͐̂̈́̋̃͝2̶̢̢̢̛̭̘͍̮̪͇̙̪̠͖̗̟̮͚̙̼̹͈͙̥͓̘̗̾̿̉͌̂͌̽̔̾̿̏̈̿̋̈́͐̔̇͋̏͊̎̒́̏̌́̎͐͘͘̚̕͜͠͠

My guess is that it's not a vulnerability but their WAF still flags/blocks it so they don't want people using those characters.

"Tell me you're not sanitizing your inputs without telling me you're not sanitizing your inputs."

Btw, does E-bay now support "special" characters in the password? Is it still 1990?

One of the most egregious cases of password length requirements I’ve ever experienced was for the Shinkansen booking website. Now, I acknowledge that it was probably possible to enter hiragana, katakana, or kanji, but for everyone that depends on the Latin alphabet the possible entropy for the password would be abysmal. The maximum password length is

It’s also possible those are historically grown requirements they implemented over time without reviewing if older requirements still make sense.

Even more concerning if the validation is being done client side.

So we're calling it a flute case now...

Wonder if the username Bobby Tables is taken.

If the password is hashed (it should), it'd always be the same length, and original's length would only impact how long hashing would take

How large is the file a password is stored on? Can't be more than a few kB. You could probably store the plaintext passwords of literally every Facebook account on one reasonably sized hard disk. There's no reason we couldn't use 500-character passwords if we wanted. A handful of my passwords are over 1,000 characters.

I'd reckon extreme length is much more effective for security than special characters. I'd reckon

1TimewhenIwasatBandCamp,Istuckafluteinmyflutecase

is significantly more secure than any password 8 characters in length for any aspiring flautist.

Here to say sanitize your inputs Bobby, but you got it covered fam. Cheers.

The fact its specifically "" and ";" makes it seem really likely they're worried about SQL injections, meaning they must be using a super insecure SQL library and also sticking the password directly in the SQL query (so definitely no hashing)

it's worse. they're not even using query binding, they're just sticking the password into sql. a bound query would escape these characters properly, a raw query will just accept them as-is. they have a couple steps before they even get to hashing.

What's worse is when they allow the backslash but you have to escape the backslash when you actually enter your password to log in.

That and maximum character limits of 12-20 are insane to me