A Few Thoughts

pomme4moi

Hi AgileBits team. I've been using 1P for a couple years now, on Mac and iOS devices. I think it's a great product, and you seem to be a great company. I hope you continue to succeed with 1P. Like any company that operates in a market economy, however, your success depends not only on your efforts, but those of your competitors. I have used LastPass and KeePass, and I thought I would offer four observations for your consideration as your product evolves.

1. User Interface: In my opinion, 1P wins hands-down in the area of user interface. This is a strength that you should continue to build on - on Mac, Windows and Android platforms. I work in the IT industry, and my experience is that users / customers often will select the product (functionality being roughly equivalent) that has the more attractive, friendly UI.

2. Integration: You will know that more and more people want software that works across multiple OS platforms. I know it requires resources to maintain multiple OS versions, but this is an area where I believe 1P can do better. I used 1P on a PC for a while and found it to be a bit clunky - no offense intended. People want solutions that offer the same user experience across platforms. Every time something works "a little differently" from one platform to another, people can get frustrated. Server-based solutions often have a bit of advantage in this area. But the ability for users to store their Agile keychain locally or in the cloud (DropBox, iCloud) is a great advantage that you have.

3. Your Blog: For users who want a look behind the scenes, your blog is great. Writing in-depth articles about security builds confidence among customers that your team has staff that know what they are talking about. And acknowledging that 1P cannot solve all security issues builds further credibility. Keep it up. It is a differentiator.

4. Dual Factor Authentication (DFA): From your blog articles, I know that the AgileBits team questions the added value that DFA would provide for 1P. You even refer to 1P as already having one-and-a-half authentication. I get it. But I suggest that DFA is becoming more common in the industry. More customers will want it, even if they do not know what it is, because they believe it is more secure. These customers will perceive your product as being less secure, and they will elect a competitor's product. They won't spent the time to learn the ins-and-outs and realities of DFA. They simply will want a product that has it. It is a question of how customers perceive your product - it's not about the realities. And perception trumps reality. As such, I suggest the AgileBits team needs to more seriously consider offering a grid or some other type of DFA.

My two cents for today, and all the best for your company's future ...

Ben

Hi there!

Thanks for the feedback. Certainly there is some great stuff there.

I did just want to thrown my own two cents in on one point (as a user of the product -- these views do not necessarily represent the company).

I'm directing my disagreement to the portion of your post that I interpreted as "you should consider adding this because people want it even if in reality it offers no benefit." That doesn't seem to me like what we're about.

If A) there were a true benefit to security, and B) it were technically feasible and the benefits outweighed the cost, I'm all for it. But, I strongly disagree in the concept of selling placebos and spending development resources on such things. I feel there are a lot more important things that could be going into 1Password (such as concentrating on your first three points, which I feel are excellent).
I'm not saying DFA is necessarily a placebo, and like I mentioned if A and B above are true, I'm all for it. What I disagree with is adding something to the product under what I essentially see as false pretenses.

If there is a misconception, to me it would be more important to educate folks instead of adding a feature that is potentially at best a placebo and at worst actually weakens security just to sell a few extra copies. From a marketing perspective maybe that makes sense, and certainly at the end of the day we want to sell software. But that isn't what we're all about. 1Password is a great example of dog food. Everyone who works at Agile works here in part because they were a passionate user of the product first. It isn't all about the money.

I look at it like this: if we were a car company, and folks were under the false impression that red cars go faster than blue cars, I'd like to think AgileBits is the kind of company that would work towards educating folks about the truth and continuing to sell blue cars, rather than taking the easy road and panting all of our cars red.

Thanks.

Ben

khad

Thanks for the post, @pomme4moi! I wholeheartedly agree with @bwoodruff: there is some great stuff there!

I would like to take a moment to expand on the reasons why 1Password does not offer DFA/2FA (dual- or two-factor authentication both themselves forms of MFA: multifactor authentication).

Our existing blog post is useful for understanding the current state of multifactor authentication in 1Password, but it doesn't really address another very important aspect.

To begin with I'd like to highlight the distinction between an authentication password and a decryption password.

Let me give a simple example. Suppose you have a file encryption program called FileEncryptionProgram.app. It encrypts a file for you and stores the encrypted file as my-secret-diary.asc.

Now the developers of FileEncryptionProgram could implement a form of multifactor authentication before the application would even begin to think about decrypting my-secret-diary.asc. That wouldn't be hard to do on the Mac.

But now imagine what happens if Mallory (an attacker) gets ahold of my-secret-diary.asc. Mallory can take that file off to his secret lair and try to attack the encryption on it. Mallory does not need to launch FileEncryptionProgram at all. Indeed, Mallory would be wise to use his own password guessing program that is built for speed and designed for the format of my-secret-diary.asc.

Mallory is trying the decrypt the data. Mallory does not need to authenticate with some particular program or service. This is the case with 1Password data as well. Anyone can write a program that decrypts the data if they can get the master password. The data is protected by the encryption and the design of our data format. An attacker doesn't need to (and typically wouldn't) go through the 1Password application itself. In fact, this is exactly what John the Ripper does, and 1Password protects your data in ways which are appropriate to its design (i.e. PBKDF2 key strengthening).

Classical approaches to MFA won't work for us because unlocking your 1Password data is not about authenticating to some service. So sure we could add an authenticator for using 1Password.app itself, but it wouldn't actually provide any real additional security. It would be just for show.

Instead we would need a key splitting approach, and it would need to work across platforms. We do have ideas of how we could do this, but it would add complexity everywhere, and to every platform. It couldn't just be an option that you use on one platform but not another. (If it were, it would mean that the data could be decrypted without the second factor.)

Again, I'm not saying that we can't do it. (We have some good ideas about how we could.) But I am saying that at the moment we are disinclined to do it for the reasons outlined above and in our blog post. Even if it is made an option, we know that there are people who will sign up to every "more secure" option available to them, even if it is the wrong choice. We've joked about presenting people with a quiz about data security before allowing them to enable such an option, and still with a flashing red sign saying "This is a bad idea. Don't enable this."

Using a second factor in the way that we would have to doesn't just double the chance of getting locked out of your data, it increases those chances dramatically. This is because your 1Password data is backed up in a variety of different ways, with robust checks that it isn't damaged. But your second factor couldn't be backed up and stored with your 1Password data. And indeed, it would typically be stored on some other device (an encrypted USB drive or smartcard). Damage to that would be unrecoverable.

Anyway, thanks for bringing this up. We should do a blog post on the distinction between authentication and encryption passwords sometime. (The distinction is relevant to more than just MFA, it is also why you should only change your Master Password if it is weak. A good Master Password should be for life.)

benfdc

On my iPhone, when I enter my password in 1P 4.5 the animation says that it is authenticating.

jpgoldberg

Well spotted, @benfdc‌!

That is a poor choice of words on our part.

benfdc

I’m not actually sure that I agree. To my mind, the fact that my password is a decryption key does not change the fact that it also serves to authenticate me as a person authorized to access the keychain. In other words, it serves as a credential.

But Decrypting would also be accurate, and more precise to boot. :-)

jpgoldberg

There is an ordinary language sense in which authenticating works, as you point out. By using the correct password, you are proving your identity.

But in a highly technical sense, "authenticating" it is wrong. Unfortunately "decrypting" is wrong, too. No real data is being decrypted at this point. This when when key derivation is happening. Unfortunately "Keeping dogs friendly with peanut butter" is both too long and too much of an inside joke.

benfdc

Confirming …?

khad

My vote was for "Verifying".

jpgoldberg

Perhaps we could just play the Jeopardy music.

benfdc

+1 for @khad #9 and @jpgoldberg #10. Although 1Password already costs enough, so I’m not sure that it would be a good idea to have to tack on royalty payments to Merv Griffin.

khad

LOL :D

benfdc

Now running 1Password 5.1 on my iPhone. Still Authenticating…

Ben

We didn't come up with a better word. :)

jpp123

Some thought on FIDO keys. One of the thinks I like and hate about 1password is auto locking. I like it because it means that even if my keychain is unlocked a bad actor seizing my laptop won't have access to my passwords by the time they get the device back to their lair. I dislike it because I have to keep entering my password (the old security usability tradeoff).

What I'd love to see is a feature still requires my password to unlock 1password but keeps it unlocked while my FIDOkey is present. Unplugging the fido key would cause 1password to require a password again. Doing this keeps the 5th amendment protections against compelled testimony gained by requiring a password but increases usability.

danco

I have just been playing with the ControlPlane utility. Haven't quite got it to work yet.

But the idea is that certain situation trigger a change of context, and that actions can be taken when the context changes. Currently I have it set up to lock 1PW on a change of context (see my post in the Lounge about Shell Scripting) but it does not change context when it is supposed to (according to my understanding of how the rules work), I currently have to force it.

Megan

Hi @jpp123,

Thanks for sharing your thoughts here! That pesky trade-off between security and convenience is always tricky, isn't it?