But that's exactly my point. You can't rely on that.

The rest of this is a rambling attempt to back up my point.

We wouldn't have car accidents if everyone drove and maintained their vehicles properly.

People, including software devs, make mistakes. They end up with deadlines, ridiculous shit expectations and decrees from management, any of a countless number of reasons why any piece of software might not be designed as it should have been. And something as ridiculously back-end as password hashing functionality isn't liable to be seen by nearly anyone. Besides the other members of my team I warned about this system, no one else in tge company knew of these flaws and quirks.

From unfortunate experience, if someone can confidently bullshit to the regulatory auditors, incredibly few of the auditors have the skills to truly verify claims about whether something is actually compliant or not. Actually safe or not. So many cybersecurity "professionals" I've encountered in my career are glorified run buttons for premade vuln scanners, unable to even check the mitigating factors in the enterprise systems they are responsible for the security of.

This wasn't some in-house hacked together program, it was a piece of software created by a very large company in the financial technologies space, with a double digit number of corporations as customers just for this specific heinously insecure piece of software they sold. For decades.

I did my part and reported it to their security contact. Nothing happened. Beyond internal discussion with some of my teammates, I've not spoken about it until after the software was deprecated not only for my company, but globally.

I can't really emphasize how big this system was for having these babby's first software project level oversights. Financial transactions were initiated by this system.

Given that, and many of the other just absurdly insane things I've seen from professional, million dollar contract type pieces of software, in my decade plus in the industry... There's how things should work. The theoretical ideal. And then there's the actually implemented garbage we actually have to deal with.

You’re confusing hashing with encryption. Hashing is always fixed length, where as encryption is not. This is important because in hashing you’ll never need to know the original value. The original value is only used to generate the hash. No two (different) values should ever produce the same hash (i.e. collision). The weaker the hash (e.g. md5), the more likely you’ll get collisions.

Now with encryption, you do need to get back the original value (decryption), and as such the length of the encrypted data will vary based on the length of the original data. But encrypting passwords is bad because that means someone could potentially decrypt the encrypted data and learn your password, at which point nothing would stop them from accessing your system.

Now, that doesn’t mean that people can’t guess your password. In fact, there is a whole facet to information system security dedicated to what’s called brute force cracking; rainbow tables, password salts, etc. this is why password entropy (entropy is a term used to reflect data that will feed into a random number generator that is used in both encryption and hashing to do their black magic) is important. The more entropy (i.e. the more characters allowed, and the longer the password), the more difficult and time-consuming it is to brute force your password. Limiting password length or characters because of storage space is a myth, lazy as hell, or worse, developer inexperience/ignorance and is dangerous as hell.