Not only does the credit bureau max out their password length, you have a small list of available non-alphanumeric characters you can use, and no spaces. Also you cannot used a plused email address, and it had an issue with my self hosted email alias, forcing me to use my gmail address.

Both Experian and transunion had no password length limitations, nor did they require my username be my email address.

Update: I have been unable to log into my account for the last 3 days now. Every time I try I get a page saying to call customer service. After a total of 2 hours on hold I finally found the issue, you cannot connect to Equifax using a VPN. In addition there is no option for 2FA (not even email or sms) and they will hang up on you if you push the issue of their security being lax. Their reasoning for lax security and no vpn usage is “well all of our other customers are okay with this”.

  • 𝕸𝖔𝖘𝖘@infosec.pub
    link
    fedilink
    English
    arrow-up
    16
    ·
    2 months ago

    Correct me if I’m wrong, but the only reason to limit password length, is to save carrying cost on the database. But the only reason that this would be value added, is if the passwords are encrypted in reversible encryption, instead of hashed. Isn’t this against some CISA recommendation?

    • ℍ𝕂-𝟞𝟝@sopuli.xyz
      link
      fedilink
      English
      arrow-up
      13
      ·
      2 months ago

      One other reason I could see is pure idiocy. Like I’ve seen that there is a bias to using every feature some software has, and if a max limit can be set, it will be set, to a “reasonable” value.

    • sylver_dragon@lemmy.world
      link
      fedilink
      English
      arrow-up
      3
      ·
      2 months ago

      There may also be a (very weak) reason around bounds checking and avoiding buffer overflows. By rejecting anything longer that 20 characters, the developer can be sure that there will be nothing longer sent to the back end code. While they should still be doing bounds checking in the rest of the code, if the team making the UI is not the same as the team making the back end code, the UI team may see it as a reasonable restriction to prevent a screw up, further down the stack, from being exploited. Again, it’s a very weak argument, but I can see such an argument being made in a large organization with lots of teams who don’t talk to each other. Or worse yet, different contractors standing up the front end and back end.

      • 𝕸𝖔𝖘𝖘@infosec.pub
        link
        fedilink
        English
        arrow-up
        1
        ·
        2 months ago

        They really shouldn’t be sending the password over the line at all. It should be local hashed/salted, encrypted, and then sent. So plaintext length really shouldn’t matter much, if at all. But I see your point.