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.]

People Can Write Pretty Much Anything in an E-mail Message

Remember that it doesn't take a lot of effort to write all sorts of lies in an e-mail message.

For example, I just got this e-mail message:

Molly Angel has shared OneDrive files with you. To view them, click the links or images below. 

My thoughts went something like this: 

OneDrive. Oh, yeah. Google's file sharing stuff that allows you to store thinggs on their servers and say who gets to look at them and download them. (Pushing the security feelings button.)

Cool. No, wait. Onedrive is not Google, Google's service is Google Drive.

Look up Onedrive. Onedrive is Microsoft's wannabee service.

And wait a minute. I don't know any Molly Angel. I know a song called "Johnny Angel" that Shelley Fabares made a hit record with. (Pushing the good feelings buttons, there.) But why would a Molly Angel be sharing files with me? (Very likely intending to push the prurient interest button, there.)

The first thing you should do when you receive a message from someone you don't know is doubt it. Doubt everything about it. Even if it gets through your mail filters, doubt it.

Especially if it seems to be trying to push your buttons, doubt it.

Look at the return address. mollyangel24@hotmail.com? Other than that I do not recognize the address, and the potential button pushing, not a lot of clues there.

Look at the subject. No subject. Unfortunately, a lot of my good friends fail to use the subject line any more. Sometimes I even forget. Not a lot of clues there.

Look at the "To:" line. Ah hah! Lots of addresses in there, several that have my first name in them. I know none of them. Several red flags here:

• Sending to more than one address is convenient, but it exposes potentially private information.
• Especially when it is people you don't know, it's exposing addresses people may not want you to know. Breech of internet courtesy.
• Some of those have names in common with me. (icardjoel@something.2ld, etc.) 

Spammers used to put ten or twenty variations of one name in the To: field, to save money or time as they tried to find addresses of suckers, I suppose. Now it may be more of a ploy to fool your filters.

There are images in this. You don't allow images to be automatically displayed, do you?

• First, if the images are naked or near-naked images, that's more button pushing. Get you excited enough that you forget your caution. 
• Second, if the images are included in the message, sometimes (especially Microsoft's) mail browsers can get fooled into executing bad programs hidden in them -- virus, backdoor, trojan, keylogger, etc.
• Third, if the image is a link to an image on some private server, the image can be monitored and, with clever tricks in the link, tell the sender that you looked at the image. If they were just guessing, they now know they have a live address that someone (you) might look at. And you didn't even click anything. (And then they send you more of this stuff.)

You can always enable images on a per-message basis if you know who sent them to you. Keep them disabled.

Unless you like to have people send you such things.

Are you that desperate for attention? That is not a good thing. If you are desperate for attention, you are going to do stupid and dangerous things.

Join a club, service organization, or even a church, where you can get face time with real people.

People you know can also do bad things to you, but they are less likely to do so. Getting to know people is an investment that they don't want to casually waste. Making new friends when they have a bad reputation gets hard for them, too.

Moving on, showing the source text for the message reveals more red flags.

The "To:" field actually does have something like fifty addresses in it.

You can see where the spammers are spoofing the dkim, spf, dmarc that are supposed to reassure you that the sender is valid.

(Of course that stuff is easy to spoof. You can write what you want in a header if you control the sending server.)

It also reveals some weaknesses in Microsoft's OneDrive.

The key to remember is that computers are just fancy paper and fancy pens. They person who controls the pen can write pretty much anything. Doubt first. Check.

Don't automatically display images.

Don't click on links unless you know the sender and are expecting him or her to send you a link, and then only if it's the kind of link you're expecting.

Other posts I've put up demonstrating the ways people try to fool you:

• Pretended legal attacks
• General explanation of links
• Fake warnings about your account 

2809 Pageviews!

Complete coincidence, not meaningful at all, but interesting to me, nonetheless.

Some of my (too many) other blogs are also approaching interesting numbers.

Why is 2809 an interesting number to me?

I am a fan of the M6809 processor.

And you say, "So?"

Motorola could have jumped years into the future, if they had been willing to refrain from going head-to-head with the wrong-headed Intel engineers in their pursuit of featuritis.

The 68000 did not need all the fancy address modes from the 68020 on. For most of them, there was very little, if any, time advantage. The only real advantage was in maybe reducing register usage. Sometimes the fancy modes even took more instruction space than doing it with a few less fancy instructions. And getting a compiler to use fancy modes is always rather a headache.

What it needed was the full 32-bit branches and other things it got with the 68010 and the CPU32 parts.

And the other thing it really wanted was separate spill/fill caching on the A7 (return address) stack, to cut subroutine overhead to almost zero and push people to use run-times that split the return address and parameter stacks.

Oh, and, of course, on-chip memory management.

Those three things with the rest of what the 68K had would have basically eliminated all the competition. There would have been no need for the industry side-tour through riscville.

The 6809 could have benefited from a similar treatment: spill-fill caching on the return address stack, extending the indexes to 32 bits and running the integer math at 16 bits wide instead of 8+8, adding memory management.

I want to build a software simulator that would have those features. If I do, I'm thinking of calling it the 2809, "2" for two stacks instead of "6" for the 6800 ancestor.

Speaking of the 6800, even the 6800 (well, the 6801) with a spill-fill cached return address stack separate from the (S register) parameter stack would have cleared a lot of bottleneck code in function calls and made it easier to support high-level language run-times. (That is, made it easier to do high-level runtimes that wouldn't fight with the engineers for precious on-chip resources.)

2809.

And some other ideas for a stripped-down CPU capable of behaving itself cleanly in a multi-processing 32-bit and 64-bit address space run-time.

Daydreams.

Drowning in daydreams brought on by a coincidence in the number of page views for this blog, which will soon be 2810 or so.

No wonder I have a hard time making a living.

Multiple Login Methods for One User (Person)

I've ranted about this before, I'm not sure where all.

My docomo cellphones have several "passwords". They don't properly explain them, and they don't give me a good reason to remember which does what, and (the real killer), they are all "PIN" in format -- "Personal Identifying Number".

• One is for logging in to the phone to use it as a phone, if you choose to have a PIN for that. 
• Another is for getting into the settings like your e-mail address or the phone number you are using. 
• Another is for accessing e-mails you have decided to save in a "secret place". (I think. I don't use it, so maybe I'm remembering wrong.) 
• Another is for getting onto the Internet if you want to pay through the nose to do that.
• Etc.

(I ranted about using PINs at banks a little bit once, here: http://defining-computers.blogspot.jp/2015/10/why-personal-information-in-e-mail-is.html.)

<sarcasm level="alert" />

Sure. Right. I'm sure the number 7738 identifies me. And about ten thousand slightly technical types who sometimes amuse themselves by looking at numbers upside-down. And 7734 uniquely identifies about a hundred thousand guys who get amused at getting to say naughty words where "no one will know".

<sarcasm level="off" />

4-column PINs are so weak that, if I could try your bank account once a minute for a week, I'd get in.

The gory details:

0000 to 9999 is 10,000 possible PINs to choose from.

One try a minute, 60 minutes an hour, 24 hours a day, 7 days a week is

1 × 60 × 24 × 7

or 10,080.

You can't do that at an ATM, of course. The guards would get suspicious. (And that's also why the ATM eats your card on the third bad try.)

But you could do that from the network, if the bank didn't disable your account on the third bad try.

8-digit PINs are a bit better. It takes at most 10,000 weeks, which is what, (10,000/52) about a hundred ninety years?

ATMs now use full touch-sensitive raster screens with on-screen keypads. They could easily shift from using hard-to-remember, mostly-meaningless PINs to using relatively easy to remember words for the shared secret function that allows you to use your ATM card.

Words. Or even full pass-phrases that you could change regularly and still have a chance to remember. Like:

• "cherry ice cream" in the summer. 
• Change it to "roast turkey wings" in the fall.
• And, for the week of your anniversary, "loves them skooks" (for a reference to an ancient Popeye episode).

The cell phone? Well, choosing a mnemonic 4-digit PIN reduces the number of tries, actually. The math gets a little esoteric, but that's one of the reasons I don't use the secret store on my cellphone.

Microsoft Windows 8 has a place to disable password login, but it seems to entirely disable passwords when you do that.

What-The-Foulup?

I looked for an auto-login setting like you can get on Macs and Linux OSses, but I sure couldn't find it. Maybe I'm missing something, but Why-The-Friendly isn't that option right out in front?

Why entirely disable passwords ever? Isn't that a major SNAFU?

(Situation Normal, All Fouled Up. Normal for Microsoft, just like the money-magnet bureaucracy it started as and still is. Money is like pus -- it collects where the festering wounds in society are, right?)

Some people still talk knowingly about getting rid of passwords entirely. They don't seem to understand the difference between a passphrase and a password. Zero, except the user isn't as surprised that a passphrase is long. And you collect all your really long esoteric, unguessable keys into a keystore protected by a single passphrase.

("cherry ice cream" is a passphrase, if you must. Not a really good one, but better than "7738".)

Any secret token system is a secret token system -- sort-of equivalent to when the guys on your block agreed that you had to say, "The north wind blows foul." to get into the clubhouse.

Religious tokens are different, by the way. If you understand the theology well enough to be able to remember words used in certain contexts, they are definitely not hard to guess. But they are not really designed to be hard-to-guess. They aren't (supposed to be) used by some mystical system to identify/authenticate believers. They are supposed to have meaning. Lots of meaning. Deep, important meaning. Meaning that helps the believer to find his or her own way into the system of belief -- although not entirely unguided.

Kind-of-like the how password to the boys clubhouse being "Girls have cooties!" would self-identify boys to a certain extent, but later lead them (through reverse psychology) to a greater truth.

Heh.

The password you use to log in to your computer should have just enough meaning to allow you to remember it, and not enough meaning for someone else to guess it. Plus-or-minus a bit, depending on whether you want your spouse/partner/sibling/co-worker to be able to remember it, too, and so forth.

Many banks are resorting to one-time-pads stored in a little device that looks a little bit like a cheap calculator. These are almost useful. Except that the user doesn't have a lot of choice.

A one-time-pad is a list, like on a pad of paper, of a lot of hard passwords, and the user is supposed to know which to use when. Maybe you cross out the ones you've used in the past and always use the next one. The bank also has a copy, and crosses the used passwords out on its copy, too.

If I could generate my own list and give it to the bank, that could be very good.

The current state of the art, however, is to depend on the (third-party) one-time-pad manufacturer to produce said lists. I do not like bringing third parties into the transaction.

Anyway. Back to the title of this rant that went too far afield --

I want to be able to log in from the keyboard via a short password, kind of like the gesture you use on some smartphones.

And when I plug my phone into some sort of network for some maintenance, I want to have a more difficult password for it, or maybe some automated key token exchange. 

In the one case, I'm just a phone user.

In the other, I'm an administrator.

Different roles. different stuff going one. Different ways to log in.

With the phone, this could be done with basic user ids and passwords, to a certain extent.

Yes, my phone runs whatever they call the LIMO distribution of Linux now. I'm not motivated enough to get in, so they things they do to discourage me from getting in so far have kept me out. That's not quite fighting fair with the GPL.

When my desktop PC screen saver locks the screen, I don't want to use the password I use on the Internet.

Slightly different roles, different login, is what I want.

I should get motivated enough to start working out a way to do that, to set up multiple ways to log in to Linux, depending on the device or access path I'm using to log in.

SPAM: ROFL (Computer Memory iIs Fancy Paper, the CPU a Fancy Pen)

Clearing out my Unsolicited folder always gives me a few chuckles.

This one was a bit more than a chuckle:

Your Mailbox (debian-user@lists.debian.org) usage is above 100MB, prior to the general system update, CLICK HERE to Upgrade your E-mail account to avoid any blockage or deactivation.

NMSU Help desk
Copyright  2016 © New Mexico State University. All rights Reserved.

Why? you ask. What is so interesting about it? 

Here are the headers that Google shows for it when you ask for the simple display of the headers (the triangle beside the from name):

---

from:		helpdesk@nmsu.edu <[****P]@csufresno.edu> via lists.debian.org
to:		debian-user@lists.debian.org
date:		Thu, Jul 28, 2016 at 1:14 AM
subject:		Mailbox is almost full
mailing list:		debian-user@lists.debian.org Filter messages from this mailing list
mailed-by:		lists.debian.org
encryption:		Standard (TLS) Learn more

---

Wow! The general user mailing list for the Debian/Linux family of computer operating systems has a mailbox at New Mexico State University!

Oh, but wait. The "from" address is deliberately miss-labeled (spoofed). It claims to be the helpdesk at NMSU, but it's really a professor at Fresno State (California State University, Fresno)!

Why would a professor at Fresno State be working the help desk at NMSU? Or even pretending to be?

Beginning to see the humor here?

Let's get a better look at the headers. Over to the right of the upper reply button, there's another triangle for a pop-up menu. Click that, and select "Show original":

---

                                                                                                                                                                                                                                                              
Delivered-To: [****B]@gmail.com
Received: by 10.36.98.147 with SMTP id d141csp352457itc;
        Wed, 27 Jul 2016 08:36:20 -0700 (PDT)
X-Received: by 10.28.194.195 with SMTP id s186mr34931549wmf.48.1469633777622;
        Wed, 27 Jul 2016 08:36:17 -0700 (PDT)
[...]
Received-SPF: pass (google.com: manual fallback record for domain of bounce-debian-user=[****B]=gmail.com@lists.debian.org designates 2001:41b8:202:deb:216:36ff:fe40:4002 as permitted sender) client-ip=2001:41b8:202:deb:216:36ff:fe40:4002;
Authentication-Results: mx.google.com;
       spf=pass (google.com: manual fallback record for domain of bounce-debian-user=[****B]=gmail.com@lists.debian.org designates 2001:41b8:202:deb:216:36ff:fe40:4002 as permitted sender) smtp.mailfrom=bounce-debian-user=[****B]=gmail.com@lists.debian.org
[...]
Received: from [10.32.215.48] (unknown [197.211.57.1])
    by fresno-p02.merit.edu (Postfix) with ESMTPSA id AA5C670072A1
    for <debian-user@lists.debian.org>; Wed, 27 Jul 2016 11:13:22 -0400 (EDT)
Content-Type: multipart/alternative; boundary="===============1054991032=="
[...]
Resent-Date: Wed, 27 Jul 2016 15:36:11 +0000 (UTC)

You will not see this in a MIME-aware mail reader.
--===============1054991032==
Content-Type: text/plain; charset="iso-8859-1"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Description: Mail message body

Your Mailbox (debian-user@lists.debian.org) usage is above 100MB, prior to =
the general system update, CLICK HERE to Upgrade your E-mail account to avo=
id any blockage or deactivation.

 NMSU Help desk
Copyright  2016 =A9 New Mexico State University. All rights Reserved.

--===============1054991032==
Content-Type: text/html; charset="iso-8859-1"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Description: Mail message body

<HTML><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=
=3Diso-8859-1"/></head><BODY><P style=3D"WHITE-SPACE: normal; WORD-SPACING:=
 0px; TEXT-TRANSFORM: none; COLOR: rgb(34,34,34); FONT: small arial, sans-s=
erif; WIDOWS: 1; LETTER-SPACING: normal; TEXT-INDENT: 0px; -webkit-text-str=
oke-width: 0px"><SPAN style=3D"FONT-SIZE: 16px; FONT-FAMILY: calibri, arial=
, helvetica, sans-serif; COLOR: rgb(0,0,0); font-stretch: normal">Your&nbsp=
;Mailbox (debian-user@lists.debian.org) usage is above 100MB, prior to the =
general system update,&nbsp;</SPAN><A style=3D"FONT-SIZE: 16px; TEXT-DECORA=
TION: none; FONT-FAMILY: calibri, arial, helvetica, sans-serif; COLOR: rgb(=
17,85,204); font-stretch: normal" href=3D"http://akkartec.com/images/upgrad=
e/" target=3D_blank>CLICK HERE</A><SPAN style=3D"FONT-SIZE: 16px; FONT-FAMI=
LY: calibri, arial, helvetica, sans-serif; COLOR: rgb(0,0,0); font-stretch:=
 normal">&nbsp;to Upgrade your E-mail account to avoid any blockage or deac=
tivation.</SPAN><BR style=3D"FONT-SIZE: 16px; FONT-FAMILY: calibri, arial, =
helvetica, sans-serif; COLOR: rgb(0,0,0); font-stretch: normal"></P>
<P style=3D"WHITE-SPACE: normal; WORD-SPACING: 0px; TEXT-TRANSFORM: none; C=
OLOR: rgb(34,34,34); FONT: small arial, sans-serif; WIDOWS: 1; LETTER-SPACI=
NG: normal; TEXT-INDENT: 0px; -webkit-text-stroke-width: 0px"><SPAN style=
=3D"FONT-SIZE: 16px; FONT-FAMILY: calibri, arial, helvetica, sans-serif; CO=
LOR: rgb(0,0,0); font-stretch: normal">NMSU Help desk<BR>Copyright &nbsp;</=
SPAN><SPAN style=3D"FONT-SIZE: 16px; FONT-FAMILY: calibri, arial, helvetica=
, sans-serif; COLOR: rgb(0,0,0)">2016</SPAN><SPAN style=3D"FONT-SIZE: 16px;=
 FONT-FAMILY: calibri, arial, helvetica, sans-serif; COLOR: rgb(0,0,0)">&nb=
sp;</SPAN><SPAN style=3D"FONT-SIZE: 16px; FONT-FAMILY: calibri, arial, helv=
etica, sans-serif; COLOR: rgb(0,0,0)">=A9 New Mexico State University. All =
rights Reserved.</SPAN></P></BODY></HTML>
--===============1054991032==--

---

I ripped out a bunch of stuff that gets in the way of seeing the interesting stuff, but it looks like (maybe) an open mail relay somewhere on merit.edu networks is picking up stuff from a bot or zombie-ized PC somewhere in the same network.

And the headers are very carefully crafted to sneak this through the SPF pseudo-validation system, but I clipped most of that. (You did know that SPF leaks like a sieve, right?)

I highlighted what appears to be the business end of this, a link to an "image" (probably not a benign image, at any rate) on akkartec.com.

Anyway, hi, Professor [Name Elided]. I am sure you are not working at NMSU's help desk. (I didn't really quite Roll On the Floor Laughing.) But it does raise an eyebrow.

And it allows me to show one example of why you should never trust e-mail without some good external reason to do so. (And maybe not even then.)

Rule for Safe Mail Use -- Don't Click the Linkies-linkies

This is the first rule that should be taught everyone using e-mail:

NEVER CLICK THE LINKS!

Who knows where that link leads to?

You want to believe it leads to where the mail message text says it does. Like, maybe to your bank or workplace.

The way links work, unless you know how to take precautions, you may never know where it took you to.

Here is a link to a Visible Link.

Here's what the above link looks like when you look at the HTML source:

<a href="http://real-link.bad/">Visible Link</a>

(I hope there is never a ".bad" top-level-domain. But then, your browser might decide to add ".com" to it, too. Browsers really should not do that. Oh, yeah, I left out the target declaration, so it is a little easier to look at.)

That link could take your web browser to they guys who want to steal your money from your bank. 

Or it could take you to a rogue server put together by your worst nightmare competitors to steal your company secrets.

Did you click the links?

Did you look at the error messages and the URLs in your browser window? (You haven't given your browser permission to hide the URL, have you?)

Not that rogue html code isn't able to overwrite what's in the URL field, anyway. (What? it can? Woops. That's right. It can. Oh, dear.)

I guess you should never let anyone you don't trust write you an e-mail message in anything but plain text.

 

======

Yes, it's an inconvenient rule. 

Wearing clothes when you leave the house may sometimes feel like an inconvenient rule, too. Or refraining from sex with complete strangers, if you want a better metaphor.

======

There was a time when it was a rule for banks and financial institutions to never put links in e-mail. Unfortunately, convenience won out and practically "everybody" is doing it these days.

So, what should you do?

One thing that might help, if you are not into trying to read e-mail raw source text:

1. Right-click the link and copy it. (Select "copy URL" or "copy link" from the pop-up menu.)
2. Launch a text editor.
3. Paste the URL into the text editor and look at it. 
4. Does it looks like it should? 
5. If you don't know what the URL should look like, look up the company or bank with your favorite search engine (google, or whatever).
6. If it looks like a valid URL, paste it into the URL field in your web browser, and hit enter.

Here are some typical URLs, for reference:

• web.mit.edu  Massachusetts Institute of Technolgy's main pages
• home.byu.edu/home  Brigham Young University's front door
• www.citi.com  Citibank's primary pages
• www.paypal.com  Pay Pal's primary pages

But you shouldn't take my word for it. (My information might become old. Or, hey, unless you know me, you have no guarantee that I am not deliberately lying about those.)

Look up the companies you work with. Pay attention to their URLs.

And never directly click the links in e-mail.

[JMR201704211122: addendum]

There are other problems with URLS that I didn't discuss above. You will want to read this, as well:

http://defining-computers.blogspot.com/2017/04/the-problem-with-full-unicode-domain.html

[JMR201704211122: addendum]