208
"TIP: You can use special characters..." "Wait, no, not those, they would break our software." (i.ibb.co)
submitted 23 hours ago by to c/softwaregore@lemmy.world
40 comments fedilink hide all child comments
 

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.

you are viewing a single comment's thread
view the rest of the comments
[–] 81 points 23 hours ago (11 children)

When they don't allow certain characters in the password, it makes you wonder if they are not hashing the passwords.

  • permalink
  • fedilink
  • source
  • hideshow 11 child comments
    •
  • [–] 64 points 23 hours ago (5 children)

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

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 5 child comments
    •
  • [–] 5 points 14 hours ago

    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.

  • permalink
  • fedilink
  • source
  • parent
  • [–] [S] 24 points 23 hours ago (2 children)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 24 points 22 hours ago (1 child)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 5 points 14 hours ago*

    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.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 19 points 20 hours ago*

    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.

  • permalink
  • fedilink
  • source
  • parent