51–60 of 254 posts
All five words are also common English words found in any major dictionary. If you're not actually doing anything stupid with the passwords, all you have to do is use that same diagnostic for that situation: "password may not contain dictionary words". Then you don't have a diagnostic which raises red flags. That the developer is not aware that their diagnostic raises a red flag itself raises a red flag. It doesn't o…
Phew. They’ll never catch me. My password is ${jndi:ldap://hunter2.com/totallylegit}
Nope - that's not a valid ldap URL - or even a valid domain, for that matter. Domains can only contain the ascii leters a-z and the digits 0-9 -- asterisks are not permitted; the only symbol permitted is a hyphen (and it cannot start or end with one).
I hacked a big social platform in my early teens (Nettby.no), since they just did a removal of all banned words, including . I instead wrote ipt> in my profile bio, and after their removal I had a valid html tag injected into the webpage and full control of anyone visiting my page..
Earlier quoted context omitted.
Actually they do sanitization by blacklisting "Blacklist sanitizing cleans the input by removing unwelcomed characters such as line breaks, extra white spaces, tabs, &, and tags." But still this is not a way, input sanitization is bullshit. Using query parameters, thus inserting raw input into already built abstract syntax tree of SQL query is the correct solution since SQL injection is about affecting tree compositi…
You don't even have to do that, just escape single quotes and you've defeated everything but homomorphic attacks as far as I can tell.
The funniest part of this is that they don't even check for all of the banned strings. Source: I'm a student there and tried it out of curiosity.
They'll probably use the disclamer as an excuse to blame you if something breaks.
Seriously though, I doubt there would be any consequences even if some BOFH tried to blame you
Earlier quoted context omitted.
> Also not storing hashes of passwords, because then it wouldn't matter what the input is. That only tells you they don't hash the passwords in the client. Likely the protection ("protection") is for the input validation layer, not the password backend itself.
Is it a slow sunday for me or... If you hash the password on the client and send the hash then hash is the password. And if you then have, for example, a DB leak with username and hashes, you don't need the password anyway because you can just send the hash and log in? (but then it's sunday and I need more coffee so I may be wrong)
The client sends the encrypted (via HTTPS) but not hashed password to the server, both for changing your password and checking your password. So the server receives the password in plaintext but shouldn't store it.
Whatever the client sends to the server, an attacker can send too.
(most fundamental rule of handling passwords is to never store them anywhere, never log them either, b etc. they should go straight to the hashing function and no where else)