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”.
A place to discuss privacy and freedom in the digital world.
Privacy has become a very important issue in modern society, with companies and governments constantly abusing their power, more and more people are waking up to the importance of digital privacy.
In this community everyone is welcome to post links and discuss topics related to privacy.
Some Rules
- Posting a link to a website containing tracking isn’t great, if contents of the website are behind a paywall maybe copy them into the post
- Don’t promote proprietary software
- Try to keep things on topic
- If you have a question, please try searching for previous discussions, maybe it has already been answered
- Reposts are fine, but should have at least a couple of weeks in between so that the post can reach a new audience
- Be nice :)
Related communities
Chat rooms
-
[Matrix/Element]Dead
much thanks to @gary_host_laptop for the logo design :)
- 0 users online
- 57 users / day
- 383 users / week
- 1.5K users / month
- 5.7K users / 6 months
- 1 subscriber
- 2.97K Posts
- 74.6K Comments
- Modlog
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.
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.