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
[–] [S] 26 points 2 days 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.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 27 points 2 days 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.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 5 points 1 day 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.

  • source
  • parent