How do you remember passwords and PINs (and passphrases)?

This thread in the Ubuntu user list:


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

that inspired this blog post of mine:

http://defining-computers.blogspot.com/2016/12/passwords-passphrases-public-key-and.html

inspired another blog post.

I've talked about this before in this blog:

http://defining-computers.blogspot.jp/2012/01/good-password-bad-password.html mentions it in trying to lay out some basic approaches to choosing good passwords and remembering them.

http://defining-computers.blogspot.jp/2016/08/multiple-login-methods-for-one-user.html goes on at some length about memorability, while trying to explain why you really don't want to log in the same way every time you use a computer or other information device. (And maybe ending up missing the point for the general case.)

http://defining-computers.blogspot.jp/2015/10/why-personal-information-in-e-mail-is.html mentions the problems, and tries (not very successfully) to talk about a few ways to send a PIN to someone else without damaging your finances.

But I decided I'd lay out some processes for remembering things here.

First, you may read somewhere that experts strongly advise against writing PINs and passwords down. Your bank is probably required by the insurance company to say that.

This is a prime example of simple rules just simply not being enough. If you don't understand why you shouldn't write it down, read the post about sending PINs that I linked above.

If you don't understand why you need to write it down somewhere safe, read the other two posts, then think about why it's easy to remember a friend's phone number:

• Regular use, 
• Positive re-inforcement, 
• The fact that three mistakes in a row doesn't send you back to the bank to get the number changed, 
• Etc. 
• And -- drumroll, please -- you write that phone number down anyway. The first several times you use it, you are reading it out of your phone book.

There's another little thing here that the guys who designed the PIN concept conveniently ignored:

Short numbers are easy to remember. They are also easy to misremember.

It's actually easier to remember a seven-digit or twelve-digit number that you regularly use than a four-digit or less number.

Why?

Because you use so many of them, for one thing. (There are several other important reasons, but that should be enough for the purposes of this post.)

Conclusion?

Banks really should start putting on-screen keyboards in the ATMs and allowing letters with the numbers, and longer passcodes instead of PINs. (And still keep the ATM passcode separate from the on-line banking login.)

But that's too easy, so banks are trying to get you to use hardware tokens, which introduce the manufacturer of the token as a new attack vector. Which I have blogged about somewhere, also. I mentioned it in passing in a general post about computer security. I think I went into more detail somewhere, but I don't remember where right now. I'm getting sidetracked again. :)

Back to remembering these tokens.

Lots of people used to write passwords down on sticky notes and attach them to the screen of the workstation or terminal where they used them. (You never did, right? :-/) It's hard to imagine they didn't understand the blatant irony in doing so, but they didn't want to believe they couldn't trust the people around them.

Trust is an important concept here. I've tried to approach it in my freedom is not free blog and other places. It's pretty much an undercurrent in most of the posts in this blog. I think I talk about it a bit in the security rants I posted in February 2013. I talked about it in my rant about trust certificates and certificate authorities and my rant about entrepreneurship, trust, and crowdfunding in my main blog. I need to post something dealing more directly with it here or in the freedom--is-not-free blog, sometime.

People have an innate need to trust.

My sister had a friend who wanted, very much, to tell my sister her PIN and let her borrow her ATM card. I shouldn't mention this except that it illustrates that trust is something we tend to develop blind spots about. That friend knew better, she just also needed someone she could trust. Which means that my sister's telling her to keep it to herself was the only right thing to do -- for all reasons.

We are all irrational about trust, because not trusting is too hard. But passwords and other cryptographic tokens are important. We can't leave our bank PIN stuck to our ATM card in our purse or backpack.

No passwords on stickies, or even any scrap of paper that you will not be controlling until you destroy it. No passwords in your daily planner or phone book.

No book of passwords unless it is under lock and key whenever it is not in your hand or in your pocket.

Lately, we are beginning to see password managers for your computers and for your portable information device (cell phone, etc.) They are convenient. They are sold as the software equivalent of a little book of passwords in a locked drawer.

There are two problems with password managers.

One, they are made by someone you don't know that you can trust. (Or, to put it in a positive phrase, if you want to use a password manager app, get to know the author and make sure the author is someone you can trust. Make sure the author has more to lose by a hidden breach of trust than he or she has to gain, etc.)

You might build your own, and I might try to show how on my programming fun blog, sometime, but that is definitely not a small project.

The other is that they can become a single point of failure. Someone gets in to your password manager, and they have access to every account or whatever that the password manager manages.

But whether you trust the author or build your own, you definitely need a really strong password that you can remember for the manager.

So. Let's talk about remembering these cryptographic tokens without a password manager app.

We'll start with clues for PINs.

Remembering a PIN is more a question of choosing a PIN you can remember. I've tried a variety of things, things like the following list:

• The address of a girl I had a terrible crush on in junior high school, reversed, of course,
• Two consecutive two-digit prime numbers that I had a certain mathematical interest in,
• 10,000 minus the model number of a bicycle that I no longer have,
• The next four-digit prime number after that model number,
• The ascii codes for my favorite cousin's initials,
• My dog's name, as I would punch it in on my cell phone,
• The sum of George Washington and Abraham Lincoln's birthdays.

I had trouble remembering those, can you believe? And they still aren't all that safe, especially now that I've listed them up there like that.

If I had a note in my pocket planner:

First Tokyo Bank -- yellow bike 10's comp.

you might easily guess that PIN and know which bank it might work on.

So, I might write that I took 10's complement, but reverse the order instead. Or note it as the combination to my sports club locker instead of writing the bank's name.

So I list it with some fake stuff, like a fake mail box at work, the name of a bank I don't have an account with, etc. And mix it with some real numbers that I don't care if people know:

• George's cell phone -- 313-843-2112
• Second Bank of the Northeast -- that beauty's initials
• Sports club combo -- yellow bike 10's comp.
• Work phone extension -- 6732
• Book club membership -- zerostone and the moon

So an important key is to be devious. Write something misleading, along with something that helps you remember the number.

But then you have to remember how it was different from what you wrote. If you use the PIN regularly, it will be easier to remember, of course. But after a month or two of not using the ATM, not so easy.

So, here's another suggestion -- use the ATM once or twice a month. Stop by and check your balance, even if you already know what it is.

Okay. So far, so good. But, you're worried that the yellow racer 2626 is too obvious, and, after trying 8484 and 7374, the attacker might try 6262, which is what you set it to.

Ciphers are good for making passwords, too. Let's try a few more simple rotation and arithmetic ciphers:

• rot 1: 3737
  2 + 1 = 3,
  6 + 1 = 7
• rot 9: 1515
  2 + 9 = 11 -- drop the carry: 1,
  6 + 9 + 15 -- drop the carry: 5
• rot 1234: 3850
  2 + 1 = 3,
  6 + 2 = 8,
  2 + 3 = 5,
  6 + 4 = 10 -- drop the carry
• add 9876: 2502
  2626 + 9876 = 1,2502 -- keep the carries except the last
• sub 5432: 2806
  2626 - 5432 = -2806 -- ignore the negative sign

Of course, if February 25th is your son's birthday, or June 28th is your daughter's, 2502 or 2806 would be out. Choose a different cipher this time.

Saying this once again, what we are doing here is using the cipher for the PIN instead of encrypting the number we remember, because we can write the number we remember in words, but writing the cipher in words is not so easy, and may draw attention to what we are doing.

So, you write the note about the PIN on one page, and on another page, you write a note about what you did to it, but it has to be someplace that doesn't stick out. Maybe it would be in a pocket address book, instead. Or on a slip of paper in your wallet (which you could rip to shreds and throw away in multiple trash cans, once you are confident you'll remember it).

Owe 12.34 to George

might mean that you subtracted 1234 from the model number to get the PIN you are currently using.

Going to all this work, you still need to keep that pocket planner where people won't start thumbing through it. Don't leave it lying around in the office or on the living room sofa. If you keep it in your bag, make sure your bag is not where co-workers, customers, students, or random strangers might pick it up and rifle through it and walk away with it because it looks interesting.

Walking away: Keep a copy of the actual PINs in a locked drawer somewhere or maybe an extra copy of the obfuscation. Then if your pocket planner walks away, you have the PINs when you go to the bank to change them.

And you can mark out the ones you remember as you remember them, or rip the page out and rip it up, throwing the pieces away in different trash cans.

Again, the problem with being devious is that someone else might decide to be devious the same way.

Now let's get some ideas for passwords.

Simple ciphers like I've described above are not good against someone with a computer. On the other hand, a simple cipher on your password is better than keeping the bare naked password in your little book of passwords, as long as you protect your little book of passwords carefully.

The discussion of PINs lays the groundwork and motivation, but passwords and passphrases have more than numbers. There are two ways to deal with that. We can cycle through the numbers, letters, and punctuation separately, or all together. (And there are some variations, which I will leave to you to figure out.)

We've looked at cycling through the numbers, but it may be easier to understand if we put a list of the numbers, letters, and punctuation in front of us. First, let's just list the whole "printable" ascii chart:

 32:  !"#$%&'()*+,-./
 48: 0123456789:;<=>?
 64: @ABCDEFGHIJKLMNO
 80: PQRSTUVWXYZ[\]^_
 96: `abcdefghijklmno
112: pqrstuvwxyz{|}

Notice the space character at code point 32.

But the code point ranks might get in the way. Let's look at that without them:

 !"#$%&'()*+,-./
0123456789:;<=>?
@ABCDEFGHIJKLMNO
PQRSTUVWXYZ[\]^_
`abcdefghijklmno
pqrstuvwxyz{|}

Using this chart, a rot 1 cipher just uses the next character in the list. And if the character you are encrypting is "}", wrap around to the first character.

Which gives us a question, do we encrypt blanks or not? With pass phrases, it's an important question. Here we will encrypt blanks because I don't think it's a good idea to leave too many clues.

Let's pick a nice phrase to start with:

Bob's your uncle.

That's too common, let's make it a little less common:

Bobbette's your aunt.

Well, okay that isn't really that much less common. If I were doing this for real, I'd probably want to muck things up a bit further, like this:

Bobbin's my aunt Friday.

Okay, now we l33t-$pe@k it:

80bBIn'5 m4 ant phRYd@y.

And, because our server doesn't allow space, we'll remove the spaces:

80bBIn'5m4antphRYd@y.

That's a twenty-one character password. But you can remember it because of the phrase it's based on. But you can't remember it all the time, so let's encrypt it with rot 2 before we write it down. Bring that clot of ascii back:

 !"#$%&'()*+,-./
0123456789:;<=>?
@ABCDEFGHIJKLMNO
PQRSTUVWXYZ[\]^_
`abcdefghijklmno
pqrstuvwxyz{|}

and refer to it while we work. Slide everything over two characters:

80bBIn'5m4antphRYd@y.  (original)
:2dDKp)7o6cpvrjT[fB{0  (encrypted, if I made no mistakes)

The only problem with this is that if

Google mail: :2dDKp)7o6cpvrjT[fB{0

is in your pocket planner, the attacker is going to think,

That's not plaintext. No way is someone who makes up a password like this going to just leave it there for me to grab.

And she will proceed to do the reverse of what we just did, trying with 1 and minus 1, then 2 and -2:

91cCJo(6n5bouqiSZeAz/ (rot -1)
;3eELq*8p7dqwskU\gC|1 (rot 1)
80bBIn'5m4antphRYd@y. (rot -2)
<4fFMr+9q8erxtlV]hD}2 (rot 2)

and, because she's interested in l33t$pe@K, too, she notices that rot -2 gives something that looks suspiciously meaningful. And she thinks,

"Bobbin's my aunt, uhm Friday." Could be a mnemonic password.

And, not only does she have your password, but if you used rot 2 anywhere else, she has those passwords, too.

Okay, so the encryption probably discourages the average junior high school student, but it only attracts the attention of the determined attacker with a bit of free time.

We could use an alternating rotation and still be within range of what we can do in our heads. We could start with rot 1 and rot -1 and rot 2 and rot -2 and then back to rot 1:

 !"#$%&'()*+,-./
0123456789:;<=>?
@ABCDEFGHIJKLMNO
PQRSTUVWXYZ[\]^_
`abcdefghijklmno
pqrstuvwxyz{|}

80bBIn'5m4antphRYd@y.  (original)
9/d@Jm)3n3cluojPZcBw/  (encrypted, if I made no mistakes)

Another option that might make it easier to work on without an ascii chart is to rotate numbers, letters, and the punctuation ranges separately:

0123456789
ABCDEFGHIJKLMNOPQRSTUVWXYZ
abcdefghijklmnopqrztuvwxyz
[SP]!"#$%&'()*+,-./
:;<=>?@
[\]^_`
{|}

But that means the punctuation in the phrase remains punctuation, which gives the attacker information that you may not want to give.

Anyway, the problem is that the password looks like a password. In fact, it looks like a hard password.

Wait. How about if we take a note we made to ourselves in our pocket planner --

Milk and eggs, no bread.

and do a rot 2 on that?

Oknm"cpf"giiu."pq"dtgcf0

That might make a sort of nice password, except for the spaces being turned into quotes.


Remove most of the spaces and the period, and l33t$pe@k it a little, add "today":

mIlk&egg5, 0Bread2d@y

but we don't actually write that anywhere. Maybe we can remember that much. Rot2:

oKnm(gii7."2Dtgcf4fB{

and there's a nice password. (And a longer string for a passphrase.)

See how that works? The encrypted form looks like an innocuous phrase. It doesn't catch anyone's attention. Maybe you never actually write it in your pocket planner.

It takes a little time to do the decryption in your head, but you'll remember that password pretty soon.

(I'm working on a little tool to do that on my computer or tablet. I'll blog about that in my programming fun blog sometime.)

Don't try to use exactly what I have demonstrated here. Pick and choose, use what you can understand and work with.

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.

]

Ospreys and Complexity

The radio is full of talk about the Osprey that came down the other day.

Yesterday, the US military told us that the refueling hose got caught in the blades. Blown into the blades by turbulence.

It was over the ocean, at least, not over populated areas. Of course, the wounded bird needs a place to land, and Okinawa doesn't have any non-populated places to land a wounded bird.

What were they doing practicing refueling in bad weather? Hmm. Practicing refueling in bad weather, I suppose. You can't guarantee good weather for military operations, you see.

My wife's radio talk show host points out this morning that, even though the crash was operator error rather than machine malfunction, the Osprey has more than its share of crashes.

The Osprey is an example of designing beyond the edge of the envelope. We think we need a machine like the Osprey (to maintain our military advantage, I suppose), so we accept that part of its operational profile includes stuff that is not safe. (Look at the Osprey taking off or landing, then ask yourself whether you want to practice refueling that bird in good weather. Heh.)

If you accept the logic of military activity in self-defense, eventually you have to accept the logic of using dangerous machines in military activity.

(While I was listening to the radio, I was thinking about the tendency we have, these days, of accepting dangerous behavior as commonplace, thinking about poorly designed embedded controls programs, and the ascendance of the x86 CPU.

Thinking about a LISP programmer who re-wrote a Forth interpreter in LISP for the space program because he didn't understand how Forth works, and couldn't read 6809 assembly language. And the irony of this was that he was lamenting the move from LISP to C.

Trading a Forth controller on 6809 for a LISP controller on 80x86. For the space program. And not understanding that the reason that C gets the new designs is precisely that Forth and LISP are too easy to customize, and that the programmers fail to be able to communicate their customizations in standard jargon.

[Woops. Having just posted this, I decided to try find the anecdote again.]

He couldn't read the Forth because learning Forth was not in his priorities. [Actually, he really did not have time.] -- Forth is not hard, you just have to re-think things. -- He would have had to recognize that there are other ways to process lists than the LISP way. [Specious conjecture on my part, there.]

The next engineer to read that programmer's LISP is going to have an even worse time, unless he is someone like me, interested in both Forth and LISP, in addition to C and the C standard run-time, etc.

[I didn't find the anecdote I had read, but I found a related one. (Link here. Some of the links in that post might take you to the anecdote I am thinking about. I need to do some real work, today.) It wasn't NASA, it was JPL. And some other irrelevant details, including that the engineer I am referring to did, too, understand the larger problems. He just couldn't figure out a way to communicate them to management. Mea culpa. I was wrong in the details, but it doesn't change my conclusions, whatever they are.]

Thinking about how scary it would be to fly a rocket being controlled by x86 CPUs. :-<

Thinking about how everybody is a slave to the arbitrary deadline, how we give up things of real value because of that deadline.

There is a lesson in here somewhere, but it got lost in the details. And the Osprey example is a good example, but not strictly because of the hardware in the controls circuitry. We must quit teaching engineers in every field, including economics, that engineering is a field where morality can safely be ignored.

Yes the problem is not the Osprey itself. It's the mindset that requires it.

The arbitrary deadline.

Who is going to be the first to back down when brinksmanship puts other people's jobs and lives in danger?)

What Is Computer Security? (Short Version)

The detailed version of this, where I plan to talk about different kinds of complexity and intransigent (NP-complete) problems and such has gotten side-tracked and mired in details.

There's a bit of irony there.

But "cybersecurity" and similar nonsense is getting bandied about in the information stream again, so I'm thinking I should try writing the short version anyway.

That means I make a bunch of assertions and fail to back them up. And leave out a bunch of references to automata and algebrae and ideal machines, etc. And, at the end, I really can't make certain of the strong arguments here.

But things need to be said, even if only ten or twenty people out of the billions in the world will ever read this rant.

First, something I use as a siggie when I post from my tablet:

(I've done the first part of this rant before.)

A CPU is just a fancy pen.

Computer memory is just fancy paper.

The network is just a fancy backyard fence.

What's fancy about the paper? 

It can be erased and written over and over, very quickly.

It has a built-in structure, so that the pen can (must) specify where it reads and writes.

It has a regular granularity, too, but I'll skip talking about that here. It isn't unimportant, but I don't have simple ways to talk about that today. And there is plenty to talk about without it.

Now, when we talk about computer memory in this way, we include the high-speed RAM, hard disks, flash and other non-volatile semiconductor storage (USB drives, SD, etc.), and such.

In the extreme, a printer that can scan what it printed can be used as a kind of memory.

And here's another hard-to-understand bit -- the network is, in a sense, a storage device. But it is different enough that we need to treat it someone somewhat separately.

What's fancy about the pen?

It can read as well as write.

It can't understand much about what it reads and writes, but it can read.

It can perform simple arithmetic between reading and writing.

Some people don't understand that the logic that CPUs perform is actually a simpler kind of arithmetic than even addition, subtraction, multiplication, division, and copying, but it is. Reading an address and using that address to access a specific part of memory is also not, I repeat, not hard math.

Everything a computer does is built on simple arithmetic.

Which leads to one more thing. A computer can read a list of pre-defined simple mathematical operations off of that fancy paper and perform that list. It can follow a list of simple instructions.

Haven't you always, secretly, wished you could find someone who would do exactly what you told them and nothing more, nothing less, and not complain?

Heh. When we start programming computers, there's a certain thrill in finding that computers follow the instructions we give them blindly and exactly. And then we discover that we often (usually?) don't really understand the instructions we are giving them until the computer has complained at us at length.

And until we and the computer have wasted a lot of time and other resources doing what we said instead of what we meant. And then we get our backs up. "Who gave this stupid computer permission to talk back?" And we get stubborn. And proud.

Hubris was once considered a necessary attribute in computer programmers.

Bill Gates demonstrates quite a bit of hubris.

Steve Jobs sometimes demonstrated hubris, but he moderated his megalomania with a sense of what the limits of technology were, and with a sense of the limits of general human ability to make good use of the technology at the time.

What's fancy about the backyard fence?

Somebody used to say that the Internet was just a fancy telephone directory. I think I even said that a few times.

There is part of the Internet that is, in fact, very similar to a telephone directory, and web sites can look very much like extended function advertisements in telephone directories, but there's more to the Internet than just that.

It's fun to talk to our neighbor across the backyard fence. It can also be useful. And sometimes several of your neighbors can gather at the fence.

Networks can be big. The Internet is really big. Lots of people can get together and talk.

And you can use things like "social networking" to select just a part of the big neighborhood to talk to.

(The telephone directories, yes, they are the basis of the social networking organizations. I'm giving a lot of control to my life to Google by using their products. LinkedIn is a little more up front about this and a lot less reaching, but then they let Google do a lot of the reaching for them.)

In addition to the directory, the Internet is composed of billions of host machines. The concept that each computing device attached to the Internet is actually a host has been watered down and swept under the rug by a whole host of interested parties who think they can't profit if they can't pipe everyone through their application. But without those hosts, there is nothing to put in the directories.

The Internet is often described as a highway. More accurately, it would be a large system of interconnected highways and byways and sometimes the local roads. (Oh, you take the highroad and I'll take the low road. ...) More correctly, the Internet is the set of rules by which traffic on the highways and the byways and the local roads gets routed. That includes a stripped-down directory service called the domain name system (DNS), which most users of the Internet only work with indirectly.

Access to the various hosts is at best only as reliable as the directory.

When we humans want to go somewhere, we use a higher-level directory for a variety of reasons. Mostly, we don't want to remain remember details like those complicated-looking URLs and URIs and IP addresses that the domain name system deals with.

Even the name of the DNS causes us to block. What is a domain and why should we be worried? (I should expand on that in this rant, (but I evidently didn't).)

So we rely on Google and Bing and Yahoo and (if you are a certain type of geek) Duck Duck Go, and so forth.

Bing. You do understand that Microsoft wants to get you to use Bing for everything without realizing you are using their search engine, exactly as Bill Gates and Co. wanted to get you to use Internet Explorer for everything without realizing you were using their universal browser?

And Google's end-play becomes more understandable, right?

The high-level web is at best only as reliable as the search engine we let guide us around it.

All of this talk about the "semantic web" is little more than a ruse to get us to let other people do the work we should be doing for ourselves (in finding meaning in things). Search engines are good, but we should not turn all our maps over to one or two or even just a few institutions, even if those institutions are privately held companies rather than government or para-governmental entities.

We have to take a certain amount of responsibility for what we do, or why even bother doing it? -- much less bother doing it right?

Security --

Computers are just fancy pens and paper and a fancy backyard fence ...

From here, lets use a different metaphor for the backyard fence.

Computers are just fancy pens and paper and a fancy bulletin board ...

Well, that metaphor is not quite complete, either. Highway system? Getting closer, but the metaphor gets more mixed than it was originally. Let's imagine a very large backyard fence with cats walking along the top, taking messages up and down the fence, and fancy bulletin board that can be copied from and to any particular place on the fence.

Getting closer, if your mind hasn't imploded.

Anybody who can get access to your pen can write anything on your paper. And read what has been written. Anyone who can get direct access to your paper doesn't need your pen.

And anyone who can get access to your piece of fence can write whatever they want on your phone book -- uhm -- directory.

That fence is a highway. Are you going to put your company safe out on the highway? Are you going to put your internal-use-only phone book out on the highway?

There are precisely two ways to protect your paper, including your directory.

One is to keep your computer away from the backyard fence, but then it can't access the neighborhood.

The other is to use encryption, but you have to use that correctly.

How does encryption help us stay somewhat secure?

If your paper is encrypted, and only you know the key to the encryption, what happens when someone else writes something on your paper?

It's not encrypted with your key.

If it's written on your paper and it's not encrypted with your key, you can guess you didn't write it. (Well, maybe you wrote it when you were too sleepy to use your key and encryption system.)

Now you know why the OS companies lately seem to be encouraging you to use encrypted file systems, whatever those are. This is what they are trying to help you deal with. Otherwise, you will rightly blame them for telling you the OS is secure when it isn't.

But someone sneaky could guess your key. Or they could find some way to watch you using it and copy it. (Think of the guy behind you at the ATM, watching you punch in your PIN out of the corner of his eye, as one example. Good thing your bank shuffles the keypad around, isn't it? Or did you not realize that was why they were doing that?)

This is why everyone has been telling you to make up "hard" passwords. Don't use easy-to-guess or easy-to-read-over-your-shoulder passwords, PINs, and so forth.

 Oh, wait. You don't encrypt that stuff. Encryption is hard work. You let your computer do all the work.

But if you computer does all the encryption for you, nothing is gained. It will also do the encryption for the neighbor who sneaks up to the fence while you aren't watching.

Even if you do it right, access with knowledge of the password you use allows the unauthorized neighbor the ability to write what he or she wants and read what he or she wants. (That's why you protect your password, right?)

There is also an implication about knowing where to read and write, but that is not as hard as we would wish. The CPU can help the nosy neighbor with that pretty much as easily as it can help us, the rightful owners of the data. (I'll have to rant about that in more detail sometime, too.)

Okay, now you are beginning to see how important passwords and PINs are. (PINs are short passwords that can't be made hard to guess. I've tried to discuss their use elsewhere in this blog, but the simple but incomplete explanation is this:

A PIN is what the bank has you use when it's okay for the bank to shut down access to your bank account on the third bad try.

So PINs are really just another kind of password, going the other direction from pass-phrases and cryptographic keys.

How can you avoid the problems of people guessing your password?

As I explained in the rant about PINs and passwords that I linked above, you make the passwords long and avoid memes and other things everyone (including you) talks about all day long. Or you let the computer generate long streams of nonsense.

How do you remember those?

You let the computer keep them in one of its notebooks -- your "wallet" or "database of tokens" or whatever. And, so that the sneaky guy can't use your database of tokens, you encrypt it and protect it with a master password, and your master pass phrase is long and something that you think about a lot but don't talk about much.

(Please don't write your master password on a sticky note and leave it in your physical wallet or somewhere on or in your desk. At least, not unencrypted, but that's back to the encryption problem.)

Have you heard about one-time-pads (OTP)?

These are kind of cool. A one-time-pad is a list of passwords or other such tokens for a specific use. Only you and the bank (or whoever the other guy is) have the list. (You don't keep it where people can read it, okay?)

And each time you use a password, you throw it away. The next time will be the next password. So even if the sneaky guys take a movie of you using one of the passwords, that password doesn't do them any good. You can't use it again and neither can they.

You can see that you want a computer to handle OTPs, right? That's computer is the that little device that looks like a calculator, that the bank wants you to start using.

The only problem is that the bank lets a third party build those. So it's not just the bank and you. That is a problem with the way things are done now.

What the banks should do instead is basically build the devices in-house and have your local branch program yours when you go to the branch to pick it up, but that is the subject for another rant.

Actually, one of the devices I want to build is a personal OTP/password manager. That is, I want to make a design that you could look at, and then you could build it yourself. It would look something like a calculator. In fact, it might include calculator functions. But it does not hook up to the Internet.

(Or, at least, the connections is physical-wire-only, and it reminds you to take it off-line after a minute on-line. But this option really isn't good, and I only mention it to help the non-tech salescrew who will want, oh, so very much, to have that "feature" to sell theirs with.)

It could generate a list of one-time-passwords that you encrypt and take to the bank. It could copy the list to a SD card, and the bank could provide a terminal for you to plug that SD card into, to make the bank's copy. Then you and the bank can be pretty sure that only you and the bank have a copy.

And, just to be sure, the bank erases the card for you after it makes the copy, and you plug the card back into your token manager and write noise where the list used to be. (Some SD cards won't let you really erase files permanently, so the device has to use special-purpose SD cards. Forget USB flash for this.)

The idea still has problems, but it separates your passcode management from the devices that are constantly on the Internet.

Uhmm, No.

You really can't make things perfectly secure. You can just try to make getting in harder than it's worth.

Real Security

This kind of security is hard. It's doubly hard to keep in it meaningful.

Constantly checking who is looking over your shoulder is not real security, so you really should not want to be doing this kind of thing too much.

Here is the basic key to real security:

Don't be valuable.

If you have to do or be something that other people think is valuable enough to steal or kill you for, give that value away as fast as you can.

Maybe you can find time to choose worthy recipients of the value. That is commendable. But, even when you can't find worthy recipients, don't wait. Give it away.

How can this be a good thing?

YOU END UP NO RICHER THAN ANYONE ELSE!

Oh!!! Horrors!!!

If you give away the value you create, others see you doing it and some of them decide to do the same thing, too. This eventually results in a world where the things people need are available. Who is going to be motivated to kill or steal when they don't have to?

It also changes your attitude, and that is the most important protection you can get. Real security is when you know that your most valuable asset is you, yourself, and you are busy putting that asset to good use for other people.

(I rant a little about this in my freedom is not free blog (for instance, here and there, too.), but I'm not the only one who can tell you about it. Look around. It may be where you least expect it.)

[JMR201612200823: Fixed a bunch of typos and added just a little to clarify a few points.]