If you can login from "some random machine" that means your password is terribly weak as well. Use a password manager, generate passwords with over 100 bits of entropy, and then you can't log into anything without it present. Now start carrying around your password manager on an encrypted thumbdrive, along with your gpg key and private ssh key with the decryption password + password manager password being the only ones you remember.
Any password a human creates and remembers is a problem. The best mitigation is to only remember passwords that are only useful in conjunction with physical access (the password manager / decryption ones).
password manager on an encrypted thumbdrive, along with your gpg key and private ssh key with the decryption password + password manager password being the only ones you remember
You have to give the system both passwords to use the thumb drive, except that these passwords, rather than being compartmentalized as currently is the practice, can steal literally every key I need to have portable with me.
By contrast, if I just type in a single password to the system, it can only even potentially the system to which that password corresponds.
Your system drastically increases the failure modes of the whole system, from a single password to a known edge server, which can be locked down on the server side, to a potential compromise of every password.
The best mitigation is to only remember passwords that are only useful in conjunction with physical access (the password manager / decryption ones).
This is extremely bad advice: the best mitigation is to require two factors, not a single factor. Your strategy is inherently two single factor systems, not a two factor system. This is what gives its ability for cascades of compromise.
The correct way to do this would be to have the keys corresponding to each server represent an XOR of your password for that server with a base key stored on a physical device, combining the two pieces of information to generate the final key. This reduces the effects from the compromise of your thumb drive from "full compromise of all systems" to "reduced to password based authentication".
Please be more careful in your recommendations in the future.
I appreciate the detail in your criticism and largely agree with it excepting that I value usability.
I'll at least hold that my recommendation is significantly better than the "state of the art" for a person who talks about ssh password auth -- typical state of the art there is using the same short memorable password for every server.
You're, of course, right that it's even better to have a second factor for each entry.
However, I'm trying to give pragmatic advise.
I would argue that having to remember a unique password for every entry in your database puts too much burden on the user which will ultimately lead to them subverting it... e.g. by using the same password for every server or using very simple ones.
My point was that you had missed a key component: compartmentalization.
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.
For my human-facing passphrases, I taught my password generator to scale automatically based on the size of the password space, the capabilities of an expected attacker (default: Snowdon's "assume 1 trillion/sec"), and the length of time for an attack (default: a decade). Keeps it clear how strong or weak what I'm using should be:
-% mkpass -h
Usage: mkpass [options]
-a, --attacker [RATE] Assume an attacker capable of RATE guesses/second (default: 1000000000)
-t, --time [DAYS] Resist an attack for up to this many days (default: 3652)
-b, --bits [BITS] Generate a password with this many bits of entropy (default automatic)
-l, --length [LENGTH] Make LENGTH word/char passwords (default automatic)
-n, --number [NUM] Make NUM passwords (default 1)
-w, --wordlist [FILE | name] Use file as wordlist (default comm3000 3esl)
-v, --verbose
-% mkpass -v
Complexity 22088^5, 72 bits of entropy. 1811 centuries at 1000000000 guesses/sec
messy photo groceries stoke horse
-% mkpass -vb 100
Complexity 22088^7, 101 bits of entropy. 88357157 million years at 1000000000 guesses/sec
ungainly shopping mall dissociation turf across stridden microphone
-% mkpass -vl3
Complexity 22088^3, 43 bits of entropy. 2 hours at 1000000000 guesses/sec
Weak passphrases: estimate 43 bits of entropy. 50+ recommended (length=5)
terrace lower-class paneling
-% mkpass -vw pin
Complexity 10^18, 59 bits of entropy. 34 years at 1000000000 guesses/sec
366565907478491511
-% mkpass -vw alnum
Complexity 62^10, 59 bits of entropy. 28 years at 1000000000 guesses/sec
cTDng2KioE
Not them, but this is arbitrary, and frankly a confusing way of even defining a password's strength. A password's strength is measured by both how it was created and also its absolute length.
In this case they're simply calling anything longer than 12.5 ASCII characters or 6.25 Unicode characters secure. While those are good solid lengths for passwords (in both cases due to the larger character set of Unicode), without knowing exactly how they were calculated it is completely arbitrary.
For example for a sentence-based password, 100 bits is insecure. But for a password generated using the secure random number generator, it is absolute unbreakable e.g.
"goodnight moon": Insecure but 120 bits (16 chars) of 'entropy'
"5%ML#_rjMe": Secure but "only" 80 bits (10 chars) of 'entropy'
Now you could argue, that the word 'entropy' would discount any sentence based passwords by definition, but that's not how I've seen people [mis]use it. They call any content of a password that password's 'entropy.'
I also want to take a moment to make fun of people measuring character passwords in bits (as opposed to characters). 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). It makes absolutely no sense to use bits in a discussion about purely character based passwords, and people only do it because they witness others do it but have no concept of WHY.
For example for a sentence-based password, 100 bits is insecure. But for a password generated using the secure random number generator, it is absolute unbreakable e.g.
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.
I also want to take a moment to make fun of people measuring character passwords in bits (as opposed to characters).
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.
The implication of "generate a password with X entropy" should be that you do, in fact, generate from X entropy. They didn't say "measure your favorite password's entropy".
Comments
Good.
If you can login from "some random machine" that means your password is terribly weak as well. Use a password manager, generate passwords with over 100 bits of entropy, and then you can't log into anything without it present. Now start carrying around your password manager on an encrypted thumbdrive, along with your gpg key and private ssh key with the decryption password + password manager password being the only ones you remember.
Any password a human creates and remembers is a problem. The best mitigation is to only remember passwords that are only useful in conjunction with physical access (the password manager / decryption ones).
Your security recommendation is bad.
You have to give the system both passwords to use the thumb drive, except that these passwords, rather than being compartmentalized as currently is the practice, can steal literally every key I need to have portable with me.
By contrast, if I just type in a single password to the system, it can only even potentially the system to which that password corresponds.
Your system drastically increases the failure modes of the whole system, from a single password to a known edge server, which can be locked down on the server side, to a potential compromise of every password.
This is extremely bad advice: the best mitigation is to require two factors, not a single factor. Your strategy is inherently two single factor systems, not a two factor system. This is what gives its ability for cascades of compromise.
The correct way to do this would be to have the keys corresponding to each server represent an XOR of your password for that server with a base key stored on a physical device, combining the two pieces of information to generate the final key. This reduces the effects from the compromise of your thumb drive from "full compromise of all systems" to "reduced to password based authentication".
Please be more careful in your recommendations in the future.
I appreciate the detail in your criticism and largely agree with it excepting that I value usability.
I'll at least hold that my recommendation is significantly better than the "state of the art" for a person who talks about ssh password auth -- typical state of the art there is using the same short memorable password for every server.
You're, of course, right that it's even better to have a second factor for each entry.
However, I'm trying to give pragmatic advise.
I would argue that having to remember a unique password for every entry in your database puts too much burden on the user which will ultimately lead to them subverting it... e.g. by using the same password for every server or using very simple ones.
My point was that you had missed a key component: compartmentalization.
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.
For my human-facing passphrases, I taught my password generator to scale automatically based on the size of the password space, the capabilities of an expected attacker (default: Snowdon's "assume 1 trillion/sec"), and the length of time for an attack (default: a decade). Keeps it clear how strong or weak what I'm using should be:
>generate passwords with over 100 bits of entropy
Is this arbitrary, or is there a specific reason you recommend at least 100 bits of entropy?
It's an arbitrary number that's large enough to be safe for quite a long time.
Not them, but this is arbitrary, and frankly a confusing way of even defining a password's strength. A password's strength is measured by both how it was created and also its absolute length.
In this case they're simply calling anything longer than 12.5 ASCII characters or 6.25 Unicode characters secure. While those are good solid lengths for passwords (in both cases due to the larger character set of Unicode), without knowing exactly how they were calculated it is completely arbitrary.
For example for a sentence-based password, 100 bits is insecure. But for a password generated using the secure random number generator, it is absolute unbreakable e.g.
"goodnight moon": Insecure but 120 bits (16 chars) of 'entropy'
"5%ML#_rjMe": Secure but "only" 80 bits (10 chars) of 'entropy'
Now you could argue, that the word 'entropy' would discount any sentence based passwords by definition, but that's not how I've seen people [mis]use it. They call any content of a password that password's 'entropy.'
I also want to take a moment to make fun of people measuring character passwords in bits (as opposed to characters). 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). It makes absolutely no sense to use bits in a discussion about purely character based passwords, and people only do it because they witness others do it but have no concept of WHY.
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.
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.
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.
The implication of "generate a password with X entropy" should be that you do, in fact, generate from X entropy. They didn't say "measure your favorite password's entropy".