Before we begin, let me preface this by saying... I actually quite like Steve Gibson. For all his faults, he often raises very salient points on a variety of topics, typically surrounding security products & services.

During the latest "Security Now / TWiT" episode on 20/10/2015, Steve & Leo Laporte featured a piece of 1Password news regarding Dale Myer's "1Password leaks your data" article.

It's a little over 10 minutes long...

It's no secret that Steve's a huge fan of LastPass and for that, I can't fault him. LastPass is a remarkable product; one which I've recommended to many people in the past. I on the other hand, prefer 1Password.

However, my personal preferences do not preclude me from criticising 1Password when it's necessary. Avid followers may have already spotted that Dale's news isn't new at all... it's something I mentioned during an article 2.5 years ago (and I wasn't the first!) (https://paul.reviews/1password-forgot-your-password-youre-doing-it-wrong/) and despite this, I've remained a supporter of 1Password and until recently, still relied heavily upon the agilekeychain format.

Before we dive in to the specifics, first... a minor correction. Dale Myers is not (nor does he claim to be) a security engineer, but a software engineer. I say this not to diminish the validity of his article at all, but to clarify that his viewpoint is that of a developer, not someone who understands the logistics of solid cryptography.

What's the problem with Agilekeychain?

The "location" (the actual URL) and "title" (the name of the site) fields (so-called metadata) are stored in plain text, such that anyone in possession of the keychain can identify any sites you use.

Although it's entertaining to listen to Steve wax lyrical about how this "represents a fundamental, crucial failure of judgement" while Leo sneers in the background, there is sound reasoning behind the decision.

The main focus of an application of this nature is not security, nor privacy... but usability. A naive & amateurish approach would be to encrypt everything, regardless of the consequences; an unfortunate result of which is a poor user experience which ultimately leads to the user reverting back to old ways.

Why isn't the metadata encrypted with your master password?

In reality, none of the data (including your username/passwords) is encrypted with your master password.

Your master password is used to derive a cryptographic key, which in turn is used to encrypt something else.

OK, why isn't the metadata encrypted with your master "key"?

It may come as a surprise, but this key isn't used to directly encrypt your data either. Instead, a unique, entry-specific key is generated by 1Password.

This unique key is encrypted with your master key, which itself is derived from your master password.

Consider the environment...

Now we understand a little about how 1Password is put together, we can begin to understand why "performance reasons" is not an argument in response to a bug, but a valid & reasonable design decision taken by experts who fundamentally understand the problem.

When Agilekeychain launched in 2008, Android was still in its infancy and Apple users were rocking the iPhone 3G. In terms of technology at that time, an HTC G1 had just a 528Mhz CPU and a measly 192MB RAM.

If 1Password was to be truly cross-platform compatible, it needed to provide a reasonable defense against attacks from modern PCs but accommodate the performance constraints of a mobile phone. As any developer will tell you, it's incredibly difficult to strike that balance and unfortunately, sacrifices have to be made.

Think for a moment about what 1Password needs to do in order to display a list of entries.

First, it must stretch your master password through the use of PBKDF2 (itself a considerable demand for a mobile device). With the master key, it must iterate through every single site (of which there could be hundreds), decrypt the entry-specific key and then decrypt the data.

In reality, it just wouldn't work on a mobile device at that time. It'd either hang completely, or slow the experience to the point where the user reverts back to "password1234" and writes 1Password off.

Remember, it's usable security we're after...

Could it be made to work?

Sure... dropping multiple derived keys would help with performance, but to the detriment of security. It's safer to assess the risks involved in storing metadata in plain text, than undermine the entire foundation in an effort to increase performance.

Take it slow...

When it comes to deriving keys from passwords, speed (or performance) is our enemy. If your environment can generated keys rapidly, such that plain-text storage wouldn't need to be considered, so can an attacker.

But not too slow...

It needs to be slow enough to trouble a would-be attacker, but not so slow as to interfere with the user experience. Again, this is a balancing act which every developer struggles with at some point.

The problem? The lack of consistency across platforms! A PBKDF2 library on iOS will respond differently to an Android equivalent; something which must also be taken into consideration at the design stage. If you expect a record to decrypt in 100 milliseconds, but it actually takes 200 milliseconds... you've doubled the time on one particular platform.

Of course, they could write their own library... but they're sensible enough not to go down that route too.

What's 100 milliseconds? Big deal!

If you have a couple of entries, sure... it seems like a nominal difference. If, like me, you have 200+ entries, instead of opening in 2 seconds, it takes a yawn-inducing 4 seconds. Would you be happy with a 4 second delay each time you searched/listed all entries?

What happens if the device is busy, or near its resource limit? Will it crash, fail gracefully, dump decrypted data to storage or take 8 seconds instead?

These are all considerations which require plenty of forethought.

Who was the information exposed to?

Anyone in possession of the keychain, or perhaps more accurately... nobody in the overwhelming majority of cases.

Agilebits have never recommended uploading your agilekeychain to a publicly-accessible location. In truth, they actively dissuade users from doing so... but I completely understand why someone would.

If your keychain is stored on your PC/mobile device, it's incredibly unlikely that anyone has seen it. Likewise with Dropbox; unless you've specifically shared the keychain with others or made it public, it's highly unlikely that your privacy or data has been leaked.

What's crucial here, is that it was not exposed to Agilebits. They don't want it, need it nor have the infrastructure necessary to store it.

Couldn't Agilebits move to OPVault sooner?

If this article has been pro-1Password thus far, it's about to take a turn for the worse.

The drawbacks of agilekeychain and added benefits of OPVault have not been communicated well at all; even a minimal risk is worth mentioning to allow users to make an informed decision. Although I discovered these issues during my investigation in 2013, I still opted for agilekeychain as the associated risks didn't affect me.

Each use case is different, so please don't consider that a recommendation either!

The inevitable comparison with LastPass

It was only a matter of time before Steve made a comparison with LastPass, so here it is.

Unfortunately, it's comments like these which place Steve in my "entertainment" bookmarks folder, not security.

You see, LastPass doesn't encrypt metadata either! It's stored, by LastPass, in plain text.

At first glance, the URL looks like an encrypted string. In fact, it's encoded in Hex!

Again, this isn't new information... it was first mentioned by a fellow researcher in 2012, coincidentally around the same time Agilebits moved away from such techniques.

Why do LastPass store metadata in plain text?

"to provide favicon support", LastPass Support.

You know, these things...

Of course, they couldn't possibly leak anything of importance could they?!

Frankly, I don't buy that. You can't build an application as good as LastPass without knowing there are other, more efficient ways to grab a favicon without leaking metadata and storing it on your own servers.

Oh dear, where do I start with that?

Firstly, his risk assessment is way, way off. If the suggestion is "I'll never give them my data, neither should you", I'm afraid Steve/TWiT no longer belongs in the entertainment/comedy folder either.

I suppose it'd be prudent to reiterate that it's impossible to give Agilebits your data. It's not cloud-based and has no requirement to be so.

I'll also take a moment to chuckle, Leo-style, at the fact he's unwittingly leaking his own metadata to LastPass during each and every login. The file "loglogin.php" should be all the indication necessary to question why (or more importantly, how) a company with no personal, private data can possibly create meaningful logs/reports unless their applications share such information.

Should Steve close his LastPass account?

Well, yes and no.

There are two options...

  1. Admit that with hindsight, it's was a ridiculous overreaction to write off an application because of a measured, reasoned set of decisions based on technology constraints from 7 years ago
    or
  2. Stand by his comments, admit LastPass leaks substantially more metadata, shares his activities in plain text with the server and close his account immediately.

I asked Steve to comment, but I'm yet to receive a reply.

Summary

As I've said countless times before, 1Password is designed & written by experts who understand the subtle nuances of deploying a scalable, secure application; to whom the term "security" means more than wrapping AES around everything in sight.

Trust is everything.