passwords, passphrases, public key, and tigers and bears, oh, NO!

Here's a thread from the Ubuntu user list that might be informative on the subject of passwords and passphrases:

https://lists.ubuntu.com/archives/ubuntu-users/2016-December/288591.html

Here's my take on the differences between passwords and passphrases:

https://lists.ubuntu.com/archives/ubuntu-users/2016-December/288644.html

I decided to unpack that post below:

[JMR201612302137: It has been pointed out that I have used a bit of non-standard explanation below. I'll try to make my explanation more compatible with current standard practice. While I'm at it, I'll fix my grammar and spelling, silently. (heh heh) ]

---

Passwords vs. Passphrases

I think the distinction has become fairly general in practice --

Passphrases are assumed to be used in indirect authentication, like public-key.

Passwords are assumed to be what are used when directly authenticating.

And also, there is a difference in what they look like.

Reasonably good passwords are assumed to be strings like

m0n<e4UR@Tom

and reasonably good passphrases are assumed to be more like

I have a monk{y for your atom, Kite.

Both are intended to be easy for the owner of the password or passphrase to remember, but hard for other people to guess.

Which means that, now that I have posted those two examples to the list and here, neither of them is any good for either me or the people on the Ubuntu user list. Or for you, now that someone might know you have read this post.

And here's a good question for you -- which one would you find easier to remember? Which do you think would be easier to guess?

(And I won't tell you the answer, because I would be telling you only half the truth, either way.)

Good Passphrases, Bad Passphrases

You may be wondering whether "m0n<e4UR@Tom" might actually be considered a passphrase. It's close, and because it is, it has certain relative weaknesses as a password. As a passphrase, you might think you want to use it like this:

m0n<e 4 UR @Tom

And that would be a harder passphrase than

I love my dog.

But it would also be harder to remember correctly. But, in fact, dividing it into words makes it easier to reverse-l33t-$peak. (Passphrases will tend to be attacked as strings of words, rather than as strings of characters.)

You do want a few more words and a little less easily parsed meaning in your passphrases.

One reason you should prefer to use a passphrase is that it (should be) easier than a "good password" for you to remember and harder than a "good password" for the attacker to guess or brute-force. (Did I already say that?)

Now, you might also be wondering, is "m0n<e4UR@Tom" a good password?

Is it good, aside from what I pointed out above, that it has now been seen on the internet, and it is therefore quite probable that it will find its way into the dictionaries that brute-force attacks use?

If you think you want to use it, don't use the same words. You could use the same ideas, or slightly different ones. Maybe use a different animal, a different sub-atomic particle, and a different preposition, etc.

But it is also too short for anything really valuable:

• It might be stronger than necessary for your password for the Ubuntu user mailing list. 
• It might be about the right strength for your blog. 
• But for your bank, it's a little too weak. You would want a stronger password or passphrase. 

Remembering is important, but the real value for passphrases lies in their assumed use in indirect authentication methods, and in the change in habits that the indirection allows.

Indirection?

Tokens, Keys

Before I explain that, let me explain the word "token" and the word "key", along with a few other concepts:

A token is a hard-to-guess string used as a password or passphrase, or something similar.

Tokens for humans to use tend to have some apparent meaning whereby they can be remembered.

Tokens for machines to use do not need to have any apparent meaning.

3iH$lqp9Pz"Qgf!#|]sQQ2_bAd*

might be a good token for a machine to use.

(Twenty-seven characters is an odd length, which will be wrong for many purposes.

Coming up with a lot of strings like that is actually pretty hard work for a human, but a carefully written program can do it relatively easily. Well, easy for the user, that is. The programmer/engineer has to work pretty hard on such programs to get them right.)

A key is a token used to protect, for example, a database of tokens.

A database of tokens is a folder or file with OS level protections set so that only the owner of the tokens is able to access them -- without removing the storage device from the information device or booting the device to a different OS.

It should also be encrypted, since removal and rebooting are not that hard. The key to the database of tokens is the key used to encrypt it.

Indirection:

The key in the present case is the passphrase that you use to decrypt the tokens in the database.

You probably have an agent application that actually handles the tokens, instead of decrypting them and passing them manually. You tell the agent your passphrase, and it handles the rest. That way, you only need to remember your key to the database. That key becomes, indirectly, your key for all the applications, web sites, etc., that the agent application can interface with.

Indirection is a way of managing all that stuff.

Public-key Encryption

One more thing to understand is public-key encryption. The idea is simple:

It's as if you have a physical safe with two physical keys.

One key allows you to put things in it. You protect this one carefully, maybe you keep it on your person at all times. You never lend it to someone for any reason, and you never even let someone with a camera or photographic memory get a good look at it.

The other only allows you to get things out. You can't use it to put things in the safe. You give copies of it to anyone who needs to get things out of the safe.

If you keep the first key private, everyone knows that whatever is in the safe is something you put in there.

That's the allegory. It isn't a perfect fit, but allegories rarely are.

With public key encryption, you have two keys. You absolutely must keep your private key safe from being seen or copied.

With the private key, you encrypt things. [JMR201612302155: Specifically, you encrypt things that people need to be able to satisfy themselves were encrypted by you. And you can say that your having encrypted the message is equivalent to your having signed the message.

The process is usually a little different from simple encryption, and it is usually called signing, rather than encrypting. ]

With the public key, you can decrypt what you encrypted [JMR201612302155: , or validate what you signed, ] with the private key.

[JMR201612302155: Now, if you are thinking about this, it might not make sense. Usually, as you might be thinking, you encrypt things you don't want people to read. But everyone can get the public key. That's why it's called public. So why encrypt it?

Repeating myself, because it may be a little difficult to accept as reasonable, if we think simply, we could encrypt the message with the private key and distribute both the message and the encrypted message. ] People who want to prove you encrypted, or signed the message decrypt the encrypted message. If the messages match, you must have encrypted it.

[JMR201612302247:

(Or your private key has been stolen. You need to be able to tell the world that the key has been stolen. This is called revoking a key, and I won't explain it much here, except to note that publicizing a revocation is considerably more difficult to get right than publicizing a public key.)

The public key doesn't look anything like the private key, of course. The public key and the private key will not appear to be related. ] We don't want people to be able to calculate or guess the private key from the public key.

Now, encrypting an entire known message with a private key will provide an attacker with a lot of clues about the private key, so we don't really do that.

But what we really do is somewhat similar to what I've described above. Among other things, we produce something called a checksum that serves as a short, and nearly unique summary, or fingerprint of the original. Any change to the message should change the checksum. And then we encrypt the checksum.

And there's a little more to it that that, and you should take the time to read and understand the full story at some point.

[JMR201612291328:

I should point out that the encryptions themselves are known to be vulnerable. But the vulnerabilities are assumed to be hard enough for ordinary use, at present.

]

[JMR201612311415:

Uses of the Public Key

This may feel counterintuitive as well, but having people encrypt things using the public key is an option.

Even the the keys are considered asymmetric, in many implementations the specification of one key as private over the other is arbitrary. Either key can be used to encrypt a message, and the other key used to decrypt it.

This can be useful when connecting with an external server. Think about the spoofing domain names and IP addresses. Without something more than the domain name, or even the IP address, you don't really know that the server you are trying to connect with is the server you think it is.

That means you are going to try to log in to a server that may be a bad-guy, and it's going to ask for your password or passphrase.

How do you avoid telling the bad-guy pretending to be your external server your important, secret password or passphrase?

(Even the lowest-level MAC on your network interface can be spoofed, so the MAC is no help, either.) A bad-guy server can tell you anything that it knows, and you have no way of telling who told it to you.

If your workstation and the server have exchanged public keys in the past, you can send the external server a message encrypted with its public key, and it can decrypt the message. Then it can send you an appropriate response encrypted with your public key and you can decrypt the response.

Again, there's more to the exact process, but, if the exchange is successful, you can have a fairly high level of confidence that the server you are trying to connect to is the one you think it is.

Then you can send it your login name and password or pseudo-random token or one-time-password or whatever with a fairly high degree of confidence. And, since asymmetric encryption consumes processor resources, you can exchange the encrypted symmetric session keys that will be used to encrypt the session data traffic.

]

The Value of Security in Authentication

This all sounds very cool, very technical, very much like something you might get away with depending on.

Don't be fooled. The technology is not perfect. It's good, for now, if you know what you are doing.

If you don't know what you are doing, you can make simple mistakes that render the whole thing meaningless for a set of keys you have generated.

On the other hand, if you don't know what you are doing, or, more accurately, why you are doing it, you could waste a lot of time on unnecessary security measures.

I'm not going to lay the arguments out here, but the value of both passwords and passphrases is significantly reduced for the user who refuses to try to understand the nature of the attacks that are in use, and in use by whom.

You have to know yourself, know your enemies, know your friends, and know your strangers. You need to know the streets (wires) on which you travel (communicate).

Technology is easy to collect, and it quickly turns into cruft. Developing habits that allow you to try to understand the threats you face and where they come from should have higher priority than implementing security measures that you don't really understand.

[JMR201612291328:

At some point, we, as a race, are going to have to learn that nothing we have is really all that valuable.

The truly valuable things we have are things that others can't take from us unless we agree -- not even by force.

And the most valuable things we have are strangely ordinary things that seem not to obey the laws of physics. The more we give them away, the more of them we have to give away again. Giving them away is what makes them valuable.

]

(I talk a little about security in this post, and other places in this blog, and in some of my other blogs, especially the one on freedom not being free. You might find what I say useful, or you might not. I'm not perfect, either.)

[JMR201612301549:

And I've posted a little rant that might help remember passwords and passphrases, and might help understand simple encryption, here:
http://defining-computers.blogspot.com/2016/12/how-do-you-remember-passwords-and-pins.html.

]