Think back to the web of fifteen years ago. Most of the web sites of the time consisted of a few pages of content along with a contact page (and maybe even a guestbook.) Most often that contact page was backed by a script that mailed the results to a fixed e-mail address. Is anyone willing to admit to using formmail.pl? In the least, we can admit that we didn’t move data around in the most secure way.
How does a one-time password work?
Some months ago, I wrote about using PGP and S/MIME to keep e-mail private. As much as I love the idea of keeping my e-mail private, I rarely use PGP or S/MIME. This is because the people with whom I communicate don’t use PGP or S/MIME. To improve this situation, I’ve been looking at ways I can help my friends and family try securing their e-mail.
I can’t think of anyone who would argue that keeping e‐mail private is of little import or an easy task. I use e‐mail as storage for personal information, for authentication, and for communicating when I want the communications to be private. Such private information should be well‐protected. Unfortunately, this is rarely the case.
My current e‐mail service provider uses machine learning techniques to read my messages and display frighteningly‐relevant advertisements to me. (This is part of the bargain of free e‐mail service.) It also does a good job providing reasonable security against most parties who would like to read my e‐mail.
So, how would I go about keeping my messages private to those whose names are on the To and From lines of the message? There are some solutions to this challenge. Two common solutions are PGP and S/MIME. Each of these solutions uses public-key encryption.
Public‐key encryption is a type of encryption that requires separate, related keys for encryption and decryption. I control a keypair—a public key and a private key. My friend John also controls a keypair. When I send John a message, I use his public key (which is publically-available) to encrypt the message. He can then use his private key to decrypt and read the message. When he sends me a response, he uses my public key to encrypt the message and I use my private key to decrypt the message.
PGP (Pretty Good Privacy) provides a means of encrypting messages and files (but not the recipients or the Subject of a message.) It is easy to use as encryption goes and relatively secure when used properly. Identities in PGP are built on the notion of a web of trust. The web of trust is a very important part of PGP. What good is encryption if you don’t encrypt the message for only the correct recipient?
The web of trust system works on the idea that you are willing to trust your friends. If you and I meet and exchange keys, you know that when you encrypt a message with my public key, I am the one who can receive that message. If I introduce you to my friend Alan, you might be willing to accept that a public key he provides you is in his control. However, with PGP, I can send you a file that proves to you that I believe that a certain public key is controlled by Alan. You can then trust that Alan is in control of that public key because you trust that I have verified Alan’s public key.
S/MIME (Secure/Multipurpose Internet Mail Extensions) also provides a means of means of securing the body of a message. It is built on the notion that central authorities should verify your identity. This makes it popular in larger companies that need to secure e‐mail. (It can also be used as the basis for single sign‐on implementations.)
The public key infrastructure system uses central authorities like companies or governments to verify identities. You (or, more accurately, your software) may trust one of these authorities to verify that Troy at Art & Logic is really Troy at Art & Logic. This is useful for companies that want their employees to communicate privately. Each company can verify the identities of the employees to the other company. This works less well when you want to communicate privately with your friends from college.
There are some drawbacks to encrypting your e‐mail.
If you want your messages to be scanned for malware, you must do that after decrypting the message. Alternatively, you or your IT team may keep a copy of your private key and use that to decrypt the message and scan it for malware. This makes your messages less private, but may save you some pain. Alternately, you may decide that you don’t need to worry about it if you trust the sender and PGP and S/MIME allow you to verify the identity of the sender.
Searching encrypted messages is not easily done if your software is not built for it. You can search Subjects, but the Subject of each message is not encrypted, so you need to find the balance of what you are willing to leave unencrypted.
In all, e‐mail encryption provides usable privacy for your messages. It does not secure the Subject line or the sender or recipients of a message. It provides some challenges for defending against malware and searching your messages in the future. If you must have privacy for your communications, I suggest you evaluate one of these options.
If you’ve read Andrew’s posts on web security (and if you haven’t go read them now – they’re great) you’ll love this Ars Technica article by Dan Goodin, “Why passwords have never been weaker – and crackers have never been stronger” about the state of the art in password cracking, the psychology behind how users select passwords, and the mistakes that services make while storing passwords.
The articles references 1Password which is a great password manager for the Mac, Windows, iOS, and Android. It can generate secure passwords up to 50 characters in length and store them securely as well. It also allows you to easily see where you’re reusing passwords (I’m sure you’re not doing this) and sort your various login passwords by strength so you can see which ones you should update first.