They're probably also not escaping/sanitizing input at all which is also super concerning.

My bank doesn't support any special characters in the password, and letters are case-insensitive. At least the limit is 30 characters, so that's still good enough. Though I really wonder what kind of system doesn't differentiate uppercase and lowercase letters.

Yet, somehow, they did implement OpenPGP for e-mail signing and encryption.

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.

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.

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.

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

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

Neither sanitizing nor even hashing. Hashes don't care what you put in.

I'm no guru, but I know enough SQL Server to know this shouldn't be a big deal to work around.

You get this sort of thing as lesson one in a cyber security course. This is so weak sauce that if they had this on the final exam it would be a joke.

"Programs must sanitize inputs before returning to work."

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

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.

Related: Our security auditor is an idiot.

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.

They could have cracked the password hashes, most likely collected NetNTLMv2 hashes, using a generated list of weak passwords using the company name + a possible ruleset with hashcat.

Some audits still do it against all NTLM hashes stored on the AD DC, but it fell a bit out of fashion because most orgs don't feel comfortable giving out that data for a pentest.

NetNTLMv2 and NTLM hashes are also still notoriously easy to run dictionary and combo bruteforce attacks on with GPUs.

You can see the benchmark for an RTX 5090 here: https://gist.github.com/Chick3nman/09bac0775e6393468c2925c1e1363d5c

It can do a whopping 340.1 GH/s for NTLM and 16017.9 MH/s for NetNTLMv2

Compare that to a Linux's default yescrypt which didn't even have official support in hashcat until this year because the hashrate would be a measly 70-200 H/s.

Is there using Windows active directory tools than there is no way an auditor can have any possible idea what anyone has set their password to. Of course they might have simply asked the question and maybe some people would dumb enough to provide the answer but there's no way they can technologically find out.

The only thing I can think of is that active directory will sync the password to other systems so if those are the systems were insecure perhaps that way you could access the data? I'm not really sure how AD handles SSO

I get unreasonably angry when a program only says "Something went wrong."

Bitch, tell me WHAT went wrong then. I can probably fix it on my end, or at least know what to tell someone who does!

Etc!? Shit, this guy know about the secret fourth umlaut.

Shows just ******* to me.