No, that's not accurate. Bits of entropy are based on how many options you have for the type of password you used. The password "goodnight moon" has far less than 120 bits of entropy. A word-based password search algorithm would find it quite easily. Those are easily both in the top few thousand words in the English language, so that password probably has less than 24 bits (2*lg(4096)) of entropy.

> 12.5 ASCII characters

That assumes 8-bit ASCII. In practice, a password doesn't include characters 127-255 or 0-31, only 32-126, and probably not many symbols. One character selected randomly from characters 32-126 has ~6.6 bits of entropy. One character selected randomly from just letters and numbers, no symbols, has ~6 bits of entropy. One character selected randomly from just lowercase letters has ~4.7 bits of entropy. And if you don't choose randomly, and instead use a memorable password, then you reduce that entropy.

https://en.wikipedia.org/wiki/Entropy_%28information_theory%...

You took an uncharitable interpretation of something another person said using standard jargon you apparently don't understand, and then went off on a rant doing exactly the thing you deride.

> The whole bits thing started when people are contrasting character based passwords with other types of passwords like certificate based (as a way of showing how much more secure certificate based authentication is).

You've misunderstood the discussion around this: it's about the bits of entropy used in the generation of passwords, all of which are digital in nature (or as you put it, in "characters"), and not how many bits it takes to store the character in the password.

Talking about "bits of entropy" related to a password means a password generated by a process using that many bits of entropy, regardless of how long its output is. It's the way to talk about passwords independent of encoding, since it talks only about their information theoretical content (stemming from the manner they were generated).

Thus, talking about "a password with X bits of entropy" is standard industry jargon for "a password generated by a technique which consumes X bits of entropy", without disambiguation between binary keys, randomly chosen characters, or randomly chosen words. (They all have the same cryptographic strength, for a given number of bits of entropy.)

tl;dr: You were overly literal and seem to have misunderstood standard industry jargon, and then gone off on a nonsense rant.

To use something that's more in the middle: you'd want to use a password manager per client (for sure) and probably divide low-security and high-security credentials.

It's just that the remote SSH servers at my job are fundamentally an expediency meant for emergency situations, and often can only be used once without being reset, eg, locking the account after a single session and requiring someone from inside the network to unlock it (after setting a new, one-time password).

In this sense, their security is primarily that I must compartmentalize each emergency server, and only use it during the appropriate emergency. However, during emergencies, the nature of the emergencies overrides the risk of compromise when accessing those commands, which typically are just specific scripts run from a locked down account.

Thus the security of the system depends on my ability to keep emergency credentials compartmentalized when using a different set, so that way only a single set of emergency commands are available to an attacker at a time -- and only when they're commands related to an already failed system.

Thus the security of the system is best preserved by strategies which highly compartmentalize the credentials, since they're meant to be used on potentially unsafe systems only during emergencies.

I guess I just remember 3-4 passwords like it's my job to -- because it is.