https://konto.zssk.sk/zk/new#step1
Also, it only seems to show “Strong password” if any of these characters is used: !@, and not other special characters.
Yep. I’ve even seen a German federal system croaking on German umlauts (äöü, etc), without being more specific that “something went wrong”.
Etc!? Shit, this guy know about the secret fourth umlaut.
In Swedish we use å. We’re Germanic, so that’s pretty close.
ß
I used a website, (the USCIS), which pointed out that they accepted emojis in the password.
Edit: remembered which site it was. It’s mentioned here, although they may have switched to id.me now, so the rules may have changed.
https://www.aila.org/aila-files/83E22577-0F60-4BBA-AF2B-4AECC7F28F5E/23021709.pdf
“Tell me you’re not sanitizing your inputs without telling me you’re not sanitizing your inputs.”
Neither sanitizing nor even hashing. Hashes don’t care what you put in.
That depends on how you are hashing. If you are doing something like ‘os.shell(“echo {password} | sha512sum”)’, you still have to be worried about special characters.
I don’t know whether to be more scared of the fact that people would do this or that people probably have done this.
I’ve had to clean up from people doing that. As a bonus, that echo shoved a newline to the end every password.
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.
I’m no guru, but I know enough SQL Server to know this shouldn’t be a big deal to work around.
lol seriously, that is wild. Basically asking to be exploited.
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?
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.
How feasible is it to attack argon2id with that method?
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
Related: Our security auditor is an idiot.
I would bypass anyone trying to agree and go straight to the CEO or president. How does this person have “security” in their title?!
That may very well be the case
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.
Thanks, it’s probably a combination of the above or even all of them
And like another user shared, they may just be idiots
I just wanted to confirm, there must be plain text databases, they got access to, maybe from some of the less secure systems, on the shop floor or wherever that may have unsecured protocols (they’re inside the corporate network, not directly connected to the internet)
But I’m going with idiots
Or a fake phishing company email that asked employees to log in. That would expose employees who were a high security risk as well.
Ooh, that’s evil… I like it
When they don’t allow certain characters in the password, it makes you wonder if they are not hashing the passwords.
They’re probably also not escaping/sanitizing input at all which is also super concerning.
Even more concerning if the validation is being done client side.
In this case it would only show the error after submitting the password, though I didn’t check the network logs.
Wonder if the username Bobby Tables is taken.
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.
Here to say sanitize your inputs Bobby, but you got it covered fam. Cheers.
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.
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.
Most MySQL/MariaDB collations are explicitly case insensitive (and optionally but very commonly blind to diacritics and accent marks). Your bank is obviously doing queries against a plain text database column.
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.
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.
W H A T
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 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.
My guess is that it is a vulnerability because it was probably vibe coded
I think even an AI implementation would be smart enough to escape special characters. It’s like one line of code, it’s not difficult.
That and maximum character limits of 12-20 are insane to me
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
Tap for spoiler
8
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.
Haha, exactly 6 is crazy! I can’t imagine how that even works. Banks in the US also have been lacking on that front.
I suspect they just carried over the length limit from PIN numbers, which can be 4-6 digits with most (maybe all?) Aussie banks.
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,Istuckafluteinmyflutecaseis significantly more secure than any password 8 characters in length for any aspiring flautist.
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
Exactly that’s why these limits are so stupid. Companies that limit passwords to only a few characters almost certainly have bad security practices.
Limiting can make sense to avoid letting password attempts dos the server through hasing them for comparison. If you look at the extreme end, sha 512 hashing runs in quadratic time. There doubling the password length quadruples the compute needed to hash it l. So at some point you reach a reasonable cuttoff in a hashing-efficiency and password entropy tradeoff.
In the real world you could see that in the context of the recent *sshhole bug: The libc library musl cuts off sha512 hashing at 256 byte inputs (could be as low as 64 chars in UTF8) for that exact purpose.
Correct, said the horse while stapling its battery.
So we’re calling it a flute case now…
AKA, here are the characters you can use to do a form injection on our website.
Little Bobby Drop Tables has a difficult life.
Ȟ̵̯͉͖̼̝͓͔̗̬͇̜̜̜̽̄̅͐̅̃̊̀͆̆͌̅̍̈̅̾̄͛̍͆̓͑͌͆̒̊̂̈̋̍̐̐̾̀̀̉̓̓̕͘̕͝ṵ̸̧̧̡̢̢̧͇͇̙͇̬̳̣̺͇̳̖̗̪̖̤͇͇̙̗̜͈̫̠̖̻͖͙̗̘͍̠͓̫̯̳̦̼̩͈͇̑̂̑̈̈̈́̓͗̈́̍̀̑̐̀͂͒͐̓̽́͛̏̈́̈͒̀̎̆̂̍͐̚͘̚͜͝ͅͅn̸͙͔̮̝̭̅̓̏͝ţ̵̧̧̡̟̯̭͔̼̖͉͔͍̟̞͎̰̪̼̤͈̝̠̜̗̩̬̤̺̗̥̖̽̿̑͂̉̿̓̆̕͠ͅȇ̷̡̢̞̣̪̼̮̖̟̝̼̤͚͍̰͉͉̥̟̹̱̼̮͚̂̂́́͛̆̊̆̀̂̂̄̔͐̆͌̾̌̓͆̇̽͒͘͘̕͜͝͠ͅr̶̨̛͚̳̗̮̟͉̤͎̺̺̮̤̯͇̹̖̮̯̣͔̺͉̝̠̞͇̖̗̮̪͕̗͇̱̣̪̤͎̰̤̻̘̱͈̀̀̄͐̀̊̀͗͑̃̈́̉̈́͋̑̀̇̓̉́̈́͋͑̉̓̏̏̕̕͠ͅ4̷̢̛̰̗͕̻̭͎͚̟̤̥̗̙̭͙̎́͊̎͆̍̂̑̄͐̂̈́̋̃͝2̶̢̢̢̛̭̘͍̮̪͇̙̪̠͖̗̟̮͚̙̼̹͈͙̥͓̘̗̾̿̉͌̂͌̽̔̾̿̏̈̿̋̈́͐̔̇͋̏͊̎̒́̏̌́̎͐͘͘̚̕͜͠͠
Shows just ******* to me.
I just don’t get this. Is it lazy programming? I don’t really program anymore and was never much if one, but I though at least some languages ad a concept of taking an input literally allowing special characters without injection or something. Forget what it’s called…
Extremely, the password should not even appear anywhere in a comparison or query. It should be hashed with a salt before being checked. What is even worse is this suggests that they are also using a SQL query via string substitution instead of it being parameterised. Considered a no no with user input.
I guess their JS, to tell you that your password is
insecurenot long enough?
Seems like they’re advertising a vulnerability pretty loud there
Btw, does E-bay now support “special” characters in the password? Is it still 1990?
