Clearly our company has set their own standards…

..this is also on top of 2FA, Zscaler, and a few other secure network requirements I haven’t fully poked around. 🤷🏻‍♂️

We regularly work with a tonne of sensitive and PII data, such that even one leak would be disastrous.

Weird, that’s just showing up as ******** to me…

Lol

Use an offline one you can store it on an encrypted usb

I’ve seen this, fucking brutal UX lol

This was Microsoft - for their online services such as Hotmail or Outlook.com or Azure - well into the 21st century. They first lifted that limit in 1999, then re-established that in 2012. They only re-reversed it back to a longer option (up to 256 characters) in 2019.

Like, morons.

Yup.

For the unaware: modern hash algorithms have character limits, but it’s nothing that would ever interfere with a regular password. Even accounting for the salt that gets appended to the end of your password before it goes into the algorithm. Most of the popular hashes have a 128 character limit, and the site will also store a salt in your user’s database entry. That salt gets appended to your password before it goes into the hash. Basically, even if two users have the same password, the hash for each will see “password{Salt1}” and “password{Salt2}”. So they won’t show as the same hash in the database, even though they’re the same password.

This salt is to prevent something called a rainbow table attack, where a hacker feeds a bunch of common passwords into a bunch of common hash algorithms, then compares with their stolen database. If they find matches, they now know which algorithm the database was using, and they only need to brute force the database once. So for instance, they feed “{common password}” into several hashing algorithms. One gives the result “1234567890”. They then check their stolen database, and find several users with the hash “1234567890”. They try using {common password} on those user accounts, and they work! Now the hacker knows which hash algorithm was used, and can brute force the entire stolen database at their leisure.

By appending a salt to each password, “{common password}” actually becomes “{common password}{Salt1}” “{common password}{Salt2}”, etc… So even if the hacker tries to brute force it, they would need to brute force each individual password instead of brute forcing the entire database all at once. It’s still important to use strong passwords, because a weak password will still be broken in only a few seconds. But that will be a few seconds per weak password, instead of a few seconds for every user at the same time. This is why sites tell you to change your password after a breach. The idea is that salting the database makes brute force attacks take a lot longer, and gives most users time to change their passwords before the attackers manage to get anything.

All of this is to say, you could have a 100 character password limit, and still have plenty of room for a 16-28 character salt. And the hashes will output the same length string regardless of what you feed into it. So longer or shorter passwords won’t matter, because they’ll all turn into a 64 character hash in the end.

So putting a low character limit on a password is a site admin tattling on themselves, because it means they’re not hashing your password at all. If they were hashing it, the only upper limit on your password would be whatever the algorithm can accept (probably 128 characters) minus 20-30 characters for a salt.

all this fuckin white space in your password keeps breaking my bespoke homegrown hashing algorithm you pleb

Look at you with the heavy security. No need for that, right on the monitor should be fine. In fact to avoid confusion you should write 'Computer PW: correcthorsebatterystaple' so you don't forget what the note is there for.

Most password managers stay open for a configurable amount of time, plus you can use hardware tokens for more convenient/secure unlocking. And having to remember the master password without it being stored anywhere but your brain is kinda the whole point