Secure Yourself in iOS 12

Update, Sept. 17: iOS 12 is out today!

Apple hasn’t released iOS 12, the latest update for the iPhone and iPad, but I’m ready—and you can be, too! I’ve updated my book A Practical Guide to Networking, Privacy, & Security to cover iOS 12 based on the latest public beta releases,  which are close to the final version. You’ll receive free updates to this edition if anything changes after release or for any future changes to iOS 12.

The book offers background information, explanations, and illustrated, step-by-step instructions across a wide range of topics, from connecting securely to Wi-Fi networks to setting privacy preferences for Siri and Safari to blocking unwanted calls and Web trackers to finding your phone or tablet when it’s lost.

The 186-page is long, but not daunting. I wrote it so that you can easily find a topic you want, like Bluetooth pairing or using AirPlay, and then dip in for that information. You don’t need to read it cover to cover to get a benefit, but you’re more than welcome to!

You can read more about the book, see sample pages, read a full list of topics, updates for iOS 12, and the table of contents at the Practical Guides page. You can also order directly via the Add to Cart link on this post!

For a 25% discount, subscribe to my low-volume email list, which I use to send occasional updates about books and projects as I release them.

Protect, Secure, and Network Yourself with My New Book

I’ve just released A Practical Guide to Networking, Privacy, and Security in iOS 11, the latest version of a book about those three topics that I’ve been updating for about seven years in a couple of different versions. 

My intent is to give you everything you need to manage networking—Wi-Fi, Bluetooth, cellular, Personal Hotspot, AirPlay, AirDrop, and more—as well as all the ins and outs of what Apple does with your private data and how it controls and restricts access by third-party apps and Web sites to you while you use an iPhone or iPad. I also explain how to pick good passwords, turn on two-factor authentication, use passcodes and Touch ID, and find your missing iPhone or iPad. 

It's a reference work—you probably won't want to read it end to end! But whenever you have a question about any of these topics, it’s there to refer to you. You can purchase it directly from me via the link below, and you get a DRM-free ebook in three different formats, so you can read it anywhere you want on any device. The price includes any updates to this iOS 11 edition. 

Read more about the book here, including a downloadable excerpt and table of contents.

If you purchased any previous edition, you’re entitled to a low-cost upgrade; contact me if you didn’t receive email or other notification. If you’d like this book in print, you can purchase a print-on-demand edition via Amazon.

Sites Lie To You about What Makes a Good Password

Bad password advice from the 1990s continues to be repeated ad nauseam, even though it has been widely disproven and groups ranging from security firms to academic researchers to the National Institute of Standards and Technology (NIST) specifically advise against most of those principles. Below, I take this apart and offer you actual good advice. (My friend Joe Kissell covers this topic in depth in his excellent "Take Control of Your Passwords.")

You might also wonder why encrypted passwords stolen from breached sites can still be cracked and used against you. I can explain that, too.

Everything you’ve been told is wrong

P@ssw0rd1  could be cracked in a billionth the time it takes for you to recognize that the first P in this sentence is a letter.

P@ssw0rd1 could be cracked in a billionth the time it takes for you to recognize that the first P in this sentence is a letter.

You know the drill. You’re often told, when setting up an account or changing a password, that a good password should:

  • Be at least 8 characters long, but often no more than 12.
  • Contain at least one uppercase letter, one lowercase letter, one number, and one piece of punctuation (from an approved list).
  • Not contain any words found in a dictionary (in any language).
  • Change every few months.

If you follow that truly lousy advice — which may even be enforced by the server — you can wind up with dr0wssaP!, a password that passes all those rules with flying colors and can be cracked in seconds. Crackers also know the above rules and optimize their cracking routines to focus on variants of simple words combined with the obvious numbers and pieces of punctuation. This is what leads people to pick Apples1! for an eight-character password. 

Not really that strong, but it’s green! That’s good, right?

Not really that strong, but it’s green! That’s good, right?

As NIST’s 2017 standards report notes about memorized passwords, “Humans, however, have only a limited ability to memorize complex, arbitrary secrets, so they often choose passwords that can be easily guessed.”

All of that is bad advice. The best current recommendation is:

  • Use a password manager that creates and manages passwords for you. I rely on 1Password.
  • Use a different password on each site. A password manager makes that easy.
  • Make it longer, which I’ll discuss more below. Passwords are often 8 to 12 characters because they’re so complicated. A longer, easier to type password can be much stronger than a short impossible one.
  • For passwords you need to type regularly and can’t paste in, make up passwords from words you know, but use several of them, randomly selected; better, let your password manager do it for you.
  • Don’t change your passwords regularly. There is absolutely no reason to create and memorize or store a new password unless a breach has occurred. The only reason to avoid this rule is if you haven’t changed your password in a while and you know it’s short and weak.

You can consult my 2015 Fast Company article, “Everything You Know About Passwords Is Wrong” for more of the research background on why existing rules are bad.

You might be baffled, as I regularly am, as to why a password like Sluggy-Headache-Fedora-Man is much more more secure than KLJf@88!4=Pz9 — should a password made of words be simpler to test and match than one made of totally arbitrary characters? No, and that’s because of the brute force required. Even with crackers using techniques to walk down smarter paths for basic passwords, longer passwords just take vastly longer amounts of times through which to iterate. (I have to go and re-read the background to refresh myself on the details.)

Every character added to a password can increase the difficulty of cracking it by some factor from just a few to thousandsfold, depending on the overall set of characters chosen, repeated characters, whether words are in dictionaries, and more. Add several characters and through the power of exponents, a password could be billions or trillions of times more resistant to brute force. You can trade off a large set of characters used in a password — like mixed case, punctuation, and numbers — against a longer password that’s entirely lowercase or mixed case. (A nice variant is to use a rare punctuation character between words.)

Effectively, the choice is:

  • If you never need to type a password, and your password manager can fill it in, picking a super-complicated 20 characters long will probably survive the heat death of the universe.
  • If you ever need to type a password, especially on a mobile device, picking a longish one that's three or four words long in an unusual combination (which can be generated by 1Password and other software and algorithms) with a story that reminds you of the words gives you until the sun burns out. Or even with vastly improved computational, the rest of your life and far far beyond.

When passwords are stolen from a Web site, aren't they encrypted? Shouldn't that stop the bad guys?

Yes and no. Account databases almost always use "hashing," a one-way encryption process that transforms any input into something that can’t be reverse-engineered to discover the original information. (It performs a large number of mathematical operations that ensures that two similar pieces of starting text produce vastly different hashed outcomes. This prevents guessing and testing.)

When you log into nearly any Web site, you enter your username and password, and the password is sent through the same hashing algorithm and compared to the stored value in the site’s database. Good so far.

Since hashing is a one-way operation, the only way to crack a hashed entry is through brute force: passing a huge number of passwords through the same hashing algorithm until you find one that matches the stored value.

However, many sites long relied on an outdated hashing algorithm (SHA1) that has run afoul of Moore’s Law combined with flaws discovered later in how the algorithm was designed. Because computational power increases on exponential basis, any algorithm that has a flat level of difficulty, no matter how complex, will eventually fall to faster computers. Plus, GPUs (graphical processing units) in computers and graphics cards vastly speed up and reduce the cost of encryption and similar intensive computational tasks. As a result, criminal crackers can afford hardware that's able to perform tens of billions — maybe hundreds of billions — of passwords checks per second. Flaws in the algorithm further reduced the amount of operations required to crack passwords, providing an effective speed boost.

One simple technique could have protected even many weak passwords. Let's say your password is 123456. That's a terrible password, and could easily be broken by brute force checks that would test billions of possible password against the stored hash value. Even worse, that cracked password is now cracked across all accounts in all breaches because it's identical when passed through the hashing algorithm everywhere.

However, if you add unique random data called "salt" to the one-way hashing algorithm, as little as a couple characters of text, but which can be much longer, the hashed results of otherwise identical weak passwords end up different. Even if one salted password is cracked, others won't be, because the salt will (or at least should be) different for each one. Every password has to be cracked uniquely by combining the salt with the current guess, no matter how weak the password is.

In short, because computing power continues to both increase and drop in cost, crackers continue to break more passwords from older breaches and use them to compromise accounts whose passwords remain unchanged.

Nonetheless, we're still talking about relatively weak passwords. It also turns out that many sites had no rules for password security, and even those that did often gave bad advice for choosing passwords. As a result, a lot of people chose 135792468 or p@ssw0rd for what they thought would be a perfectly unguessable password. 

Pick a better password even as sites improve their encryption choices, and you can wind up well protected. Some sites and services that use robust protection have had major breaches and no reported cracked passwords.

I originally wrote this as part of a story where it wound up ballooning out of scale, and too tangential. I revised to share here!

What I’d Like to Hear Tim Cook Start with

At the start of the keynote tomorrow, I'd like to hear Tim Cook say this:

You've seen all the coverage about hacked accounts and stolen private images and data. We at Apple are appalled about this and as soon as we were alerted, began days of auditing, and immediately fixed problems that abetted the password cracking related to iCloud that led to some of these breaches.
You trust us with your most personal details, and we take this seriously. The possession and disclosure of private data is a crime. Make no mistake: This isn't funny and the victims should not be blamed for trusting us and others. No one should be sniggering, shaming, or pointing figures. Criminals stole people's information and then released it. We will do everything in our power to assist law enforcement to track them down for prosecution.
We have already taken some steps, and in the next two weeks will take more. We can do better.

(Spoiler: he didn't.)

Certifying Certificates in the Post-Snowden Age

The news that the NSA used various methods to weaken cryptographic algorithms and protocols has caused more of a shock than I would have thought. It's been widely believed that the NSA had already broken some methods of encryption (whether a specific kind or in the right circumstances) through discovering flaws, new math, or computation power. But I suppose the intentional insertion of weakness as well as working with some companies to install backdoors or flaws is what stuns. By making supposedly secure methods weaker, the NSA endangers us all, including America's personal, corporate, and government interests. But there's one thing you can do about secure Web connections.

Bruce Schneier, who has seen the Snowden-provided documents on which the ProPublica/Guardian/New York Times report was based, has a set of recommendations for what security methods to employ. He skips one nascent effort, though, that's easy for non-technical users to add: the Perspectives Project. This Carnegie-Mellon University project lets users consult a central database of Web site digital certificates and be informed when any of those certificates change, and manually report attacks.

Right now, the Web of trust (sorry) for digital certificates works thusly. If you want to use the industry-standard SSL/TLS protocol for establishing a secure connection between client software and a server — in this case, a Web site, but also for email and many other purposes — the Web site in question has to obtain a certificate. It creates a certificate using a proprietary or public key-generation process (the private ones may now be suspect), and then has it digitally signed by a certificate authority (CA), which is either a company you work with directly, or with which a Web hosting company interacts on your behalf. (To sign a certificate, the plain-text contents are hashed, which distills the messages through a one-way encryption algorithm into a relatively short run of characters. That hash is encrypted with the CA's private key.)

A globally acceptable CA has a certificate installed in every operating system and in many browsers that contains cryptographic information that can be used to validate any certificate that it signs. When your browser connects to a Web server, the server sends its certificate. The browser checks its own list or that of the operating system to ensure that the signature is valid. If so, the server's public key is used to encrypt a session key, a symmetrical one that both sides use. (The plain text of the certificate is hashed by the browser or OS, while its signature is decrypted using the built-in public key for the CA. If the two hashes match, great; if not, the text has been modified. If the certificate isn't signed by the CA, the key won't decrypt it, too, resulting in a failure.)

There are several hundred CAs in the world, and they have a huge number of reseller relationships which gives access to countless more groups. There is no enforceable standard by which CAs issue certificates (guidelines, yes), nor the security provisions to restrict them. This means it's trivial for a party that has access to a CA to issue certificates for domains for which they have no business doing so. These certificates are perfectly valid, but they are illegitimate. This is what happened when DigiNotar's system was compromised. DigiNotar certificates were issued for a bunch of major Internet services.

Because of the lack of global recordkeeping and standards, it's impossible to know whether a given certificate from a CA is valid. Google has promoted the notion of pinning, which they built into Chrome and use for some of their domains. A browser that supports pinning only allows a certificate for listed domains to be signed by specific CAs. If a certificate is presented signed by another CA, the browser sounds the alarm. (There's a proposal called DANE that would allow every domain owner to list the valid certificate signatures for each subdomain in DNS records, but it requires the long-in-progress DNSSEC security upgrade to be further along to work at any scale.)

Without pinning, however, it's possible for an exploited CA or one that is under the control of a government (suspected in some countries) to issue a certificate for any Web site it chooses and use it without detection. Sorry for the bold. This can then be paired with DNS poisoning, in which domain-name queries for an ISP, business, or entire country (cf., Iran et al.) are provided with a false response that directs a browser (or email client or what have you) to a different IP address. An illegitimate but valid certificate coupled with DNS poisoning allows seamless interception of supposedly secure data. It is likely happening all the time.

It's also critical to note that the NSA revelation includes successful attacks against SSL/TLS connections. There's not enough detail to know what it means. Does the NSA have a way to generate CA-signed certs? Has it figured out how to break the basic protocol? Is there a weakness in one or more server software packages that allows an https connection to be intercepted and decrypted? Hard to know.

Amazon.com's notary report. A few notary servers are currently not working. 

So where does Perspectives come in? Perspectives is a global watchdog. The idea is to have a set of notary servers that continuously retrieve certificates used by publicly available secure Web sites and store the associated signature. That total number of servers is a smaller number than one might imagine: it numbers in the millions. 

These notary servers may be run by the CMU project (as they are in this early stage), or by governments, non-profits, individuals, or companies. One could choose which notaries one trusted. But the servers need to be spread out across countries and networks in case a site's certificate or DNS is compromised only in some locations.

Ruh, roh! 

Ruh, roh! 

Whenever your browser equipped with Perspectives visits a secure site, it consults several notary servers to see if most of them agree that the signature you received matches the one they have seen most regularly. If not, you're warned. It could be that only your part of the world is getting an illegitimate certificate, or that, worldwide, it all changed at once. (Sites change certificates regularly, but not constantly. Further, some sites are configured in a fashion that different valid certificates might be used in different locations or change even for connections from the same part of the world. But it's still a small set of exceptions and can be encompassed in this model.)

Github's servers fed out a different certificate to one notary for several days; see the purple line. 

At the moment, the only real way to use Perspectives is by installing a Firefox add-on, which was just updated in late August. The plug-in lets you optionally show the results of notary checks and report an attack if you believe you're seeing something funky. (Some of the notary servers aren't responding as I write this post, which produces false negatives, and I hope it will be fixed soon.)

The use of notaries provides a useful check against governments, ideologues, and malicious individuals who want to insert themselves into our day-to-day lives. Each notary's identity is digitally signed and preloaded in whatever software you would use. The connections are secure to the notaries. The potential to distribute notaries worldwide subverts any one country or bad actor's ability to go unnoticed.

Perspectives and a few similar ideas have been kicking around for a few years. The NSA revelation make it sensible to add Perspectives if you use Firefox. It certainly doesn't solve all possible vectors, but it does effectively shut down one used by parties with many different motivations.