Private I: When security products don’t actually make you safer

I hate to poke holes in good-faith efforts to improve the integrity and security of individuals’ and businesses’ data, but in just the last week, I’ve seen three separate efforts that each attempt to fix a problem, but only solve a top layer. The underlying defects remain, and they’re not at all the fault of those companies.

However, the road to hell is built on good intentions, and the best way to get off that highway is to examine all efforts with a steely glint.

No, look over there

In April, Google released the Password Alert extension for its Chrome browser. The extension captures and transforms your password when you log in to any Google site, storing it in a non-recoverable format against which other password entries may be checked. (See its FAQ for storage details.)

Then, whenever you use your browser to enter that password at any non-Google site, the extension warns you that you’ve been phished, and recommends immediately changing your password for the Google account. This requires that you use a unique password for any Google account. Otherwise, you’ll see this warning on any site into which you submit a login with the same password.

It’s a clever idea, although it has the cow’s-out-of-the-barn problem of warning you post submission rather than saying, “Whoa—you’re sure you want to submit this?” (It would require rather more vigilance and CPU cycles to do that.)

But it’s false security. While it can aid both naive and sophisticated users, even the savviest are fooled when they’re presented with phishing pages (PDF) that are expertly made to resemble legitimate sites. Researchers quickly found workarounds—many workarounds—to Password Alert. Some bypasses may be impossible to prevent, thus providing a subtle false positive signal to users that everything’s ok.

A warning is better than none, but false security can lull people into letting their guard down, too. Google will continue to improve the extension, but they may be unable to make it robust enough to rely upon.

Security through assurances?

I received a flurry of email last week about Soverin, a new email service that was going to be revolutionary around customer data and privacy.

What’s different? Nothing technical. They’ve founded their enterprise in opposition to Gmail, more or less, pledging through contract and privacy agreements to retain and use as little of its customers’ personal information as possible, and definitely not examine to sell details (even in aggregate) to marketers or display advertising. It’s a paid service at a moderate price.

While their privacy policy is exhaustive and welcome, they’re using standard encrypted IMAP service for retrieving email. This is effective in protecting data in transit if implemented well, but mail residing on its servers will be available to anyone at the company and any law-enforcement agents or crackers who gain access. (They encrypt email backups with a unique user code, which is smart, but email in IMAP storage has to be unencrypted.)

The firm is based in the Netherlands and has located its servers there, too, so Soverin is taking advantage of more stringent laws found in Europe related to data privacy than are present in almost any other part of the world. Still, I’ve been subscribing to Fastmail for many years, and the difference between the paid Fastmail service and Soverin appears to be a marketing approach based on server geography.

Remind me again of that code?

The folks at MacPaw make a variety of useful utilities, including disk degunkers that find and remove unneeded files and duplicates, some of which may affect system performance in the right circumstances. (It’s more rare that a file slows your computer down, and more likely that a drive that’s approaching full reduces performance as OS X moves parts of files around and writes temporary or swap files to disk.)

But I have mixed feelings about its just-released, free, OS X/Windows cross-platform compatibility file-encryption software, Encrypto. There’s nothing wrong with the approach, the interface, compatibility, or its simplicity. Rather that it’s trying to solve the wrong problem in the right way.

The software lets you pick a password of any complexity and then also provide a hint that can be publicly viewed by anyone with the Encrypto software on either platform. The hint is supposed to provide a jog to memory that a recipient can use to decrypt a file.

There is a dearth of simple, powerful file-encryption software, so I want to like Encrypto. But the hint part is highly problematic. Providing a hint, however obscure, reduces the universe of potential passwords, because the hint has to be a clue that a recipient can transform into something meaningful.

I can guarantee you that if my hint to an old friend is “that terrible joke about Greek clothing” they would come up with “Euripdes, Eumenides.” But so, too, would many others—it’s an old, old joke—and it would provide the cues for a small universe of combinations of words to be tried, should another party get ahold of the file.

If the file isn’t important enough to worry about a malicious third-party hacking into it, then why use encryption? If it is, then why use a method that’s guaranteed to have a highly exposed attack surface?

This problem has been solved in many ways by many parties, but it almost always involves an ecosystem. Kudos to MacPaw for trying to avoid having a public-key or other encryption infrastructure as a requirement. It’s dead simple, and I love that.

But they need to figure out a method to allow people to use strong passwords that are associated with simple hints that no third party could ever associate—like a code book, in which a word like maryjane meant to use password vjvkv4iQu2sZ[u0. Having a local component that allowed two parties to generate a code list that would be encrypted and stored local, and could be shared in some very careful way would offer the best of both worlds.

Even a shared secret used for the purposes of increasing entropy—making it vastly hard to use brute force to find a password match—would turn this nifty idea into something that truly improved security.

Right direction, wrong approach

For users to achieve an end to fear of routine or unimpeded interception, the tools provided have to be strong enough by default—no additional management should be required. That’s why iMessage has done so well: the end-to-end encryption is strong and effortless. But iMessage isn’t appropriate for all kinds of data transmission, and some people would prefer not to rely on Apple’s technology and assurances.

This is all the right direction, but more pragmatism about what’s truly being offered and how it’s being described is required as well.