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”.

  • xthexder@l.sw0.com
    6·
    3 months ago

    I’d rather see a paper explaining the flaws with salted passwords rather than “just use this instead”.

    My initial reaction is that this overcomplicates things for the majority of use-cases, and has way more to configure correctly compared to something basic like a salted sha256/sha512 hash that you can write in any language’s standard library.

    If the database of everyone’s salted password hashes gets leaked, this still gives everyone plenty of time to change passwords before anything has a chance of cracking them. (Unless you’re about to drop some news on me about long time standard practices being fundamentally flawed)

    • delirious_owl
      1·
      3 months ago

      Wut. Is the competition not enough data for you? This is how we got AES.

      Can you name a single popular language where Argon2 isn’t implemented in a stamdard library?

      • xthexder@l.sw0.com
        1·
        3 months ago

        I think you’re missing the point of what I’m asking. In what way are regular salted passwords insecure? Sure you can keep adding extra steps to encryption, but at a certain point you’re just wasting CPU cycles.

        I have no doubts about Argon2 being secure, I just think the extra steps are unnecessary for anything I would build (i.e. not touching financial transactions or people’s SSNs). By design argon2 uses a lot of memory and CPU time to make bruteforce attacks much harder, but that’s more of a downside when you’re just doing basic account logins on a low end server.

        I’ll happily retract my point about external dependencies. It’s available in most languages, and notably std C++ contains neither argon2 or sha256/512 hashing, so that kind of makes my original point invalid anyway.