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”.
Yeah well, if you’re so smart let’s see you write a website in COBOL.
no spaces in a string is a dead giveaway that theres Cobol in there somewhere meow
You joke, but…
- https://www.microfocus.com/documentation/visual-cobol/vc70/VS2017/GUID-78091B18-A9B3-4212-BE5F-3E28C7196413.html
- https://github.com/loveOSS/awesome-cobol
(No, I will never forgive the college I went to for undergrad for forcing us to take two semesters of COBOL. Why do you ask?)
I actually clicked on all the web-related Awesome Cobol links yesterday. Each one is either a broken link or golang code.
This implies they’re storing the plaintext password.
Ideally the password would be hashed with a salt and then stored. Then it’s a fixed length field and it shouldn’t matter how long the password is.
Or a very very old database system, possibly DB2, where you can’t change the column limits or data types after the fact.
If they’re hashing, the column size should be irrelevant. Ideally the database should never see the plaintext password in the first place (though I could understand calculating the hash in the query itself). If they’re not hashing, they should really be rewriting their database anyway.
Salted passwords are not recommended anymore. Better to use a memory hard key derivation function designed for passwords, like Argon.
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)
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?
Credit bureaus are not for your protection, they’re for the protection of their clients, the banks.
Banks aren’t much better. Up until just a couple years ago, the Treasury Direct website (to buy bonds/etc from the US Treasury) forced you to use a god damned on-screen keyboard to input your password and the passwords were not case sensitive. I’m pretty sure it also only read the first X number of characters of your input because I recall that people tried typing extra characters after their passwords and it would still accept it as valid, though I could be conflating this with some other archaic site.
You are unable to paste your password into the “confirm password” field. I thought I was going to have to type it in, but Bitwarden’s autofill worked.
Financial institution security is quite frankly a freaking joke. My bank only has the options for 11 character passwords at maximum. It’s like oh come on that is way too easy these days
Honestly, that’s a sign to me that your bank doesn’t take cybersecurity seriously and would possibly consider switching. Mine has amazing security as well as fraud detection. Sometimes it’ll even send me a text to verify a purchase if their software thinks it’s weird I got across town too quickly, though that’s pretty rare so it isn’t overly aggressive/inconvenient.
In Germany at least, I hear that banks have weird law requirements for these weird security things, like photoTAN.
I’d be much happier if they’d just let me do my usual setup with password, totp and my hardware token.
In the US the FDIC sets security requirements for banks and audits annually, and they keeps raising requirements every year or so. At this point its just easier for a bank to invest in following current best practices and keep updating to the current best practices than to keep chasing every new finding on the FDIC audits each year
Source: I worked in IT at a bank for a while
A 20 character password of case insensitive letters and numbers is quite unbreakable (taking billions of years to brute force). Still, what a strange way to announce your database is old and you probably aren’t hashing your password with anything stronger than MD5. Or worse.
My default is to generate a 32 character password and store it in a password manager. Doesn’t matter to me how many characters it has since I’m just going to copy and paste it anyway.
Pretty surprising how many places enforce shorter passwords though… I had a bank that had a maximum character limit of 12. I don’t bank with them anymore. Short password limits is definitely is an indicator of bad underlying security practices.
A hash has a fixed length, including MD5. There’s no reason to cap password (input) Iength. You can hash the whole bible and still get the same length hash. So either they don’t even hash it, they’re idiots, or they try to be unnecessarily cautious to avoid some other limit / overflow, like POST max size (which would still be counted in at least KB, not several characters). The limit on what special characters you can use is also highly suspicious - that’s not how you deal with injections / escaping your inputs.
