Suggestion for Secure Sharing

benfdc

I was unspeakably disappointed to read in the blog that AgileBits has added to 1P/iOS an option for insecurely sharing passwords without also offering an option to securely share passwords.

I am unspeakably horrified (and, truth be told, mildly enraged) that you offer an "obfuscate" option. Export > Selected > Encrypted Web Page was dropped from 1P/Mac 3.6 on the ground that it wasn't super-strong and that a false sense of security is worse than no security. You have now built a sharing option that offers your users a false sense of security.

Allow me to offer a suggestion for implementing secure password sharing.

Every 1Password item gets a new field: Sharing password. Initially there is no field into which a user can type a password, only a Generate button that produces a seven-word Diceware-ish passphrase. Once the passphrase has been generated, an edit button appears after the generate button. This procedure will make sharing secure by default but allow a user who wants diminished security to achieve it.

When a user tries to share an item, the choices offered are plaintext and secure. If secure is chosen and a sharing password already exists, it is used. If not, 1Password generates a seven-word Diceware-ish passphrase and offers the same generate and edit buttons. When the secure share is sent, the sharing password is stored into the item.

The transmitted 1PIF never contains the sharing password.

The recipient must type in the sharing password in order to import the item, and the item is saved with the sharing password.

The sharing password need only be generated and communicated the first time that an item is shared, because in subsequent exchanges 1Password already knows how to encrypt and decrypt the item.

I can think of lots of tweaks, such as an option to assign a sharing password to a folder that would be inherited by all items in that folder, but the perfect is the enemy of the good. Just do it.

Whether or not you implement a mechanism for secure sharing along these lines, please either get rid of the obfuscate button or give us back Export > Selected > Encrypted Web Page, because so far as I can see there is no conceivable justification for offering your users the one without the other.

—Ben F

benfdc

Also, how about releasing free viewers for securely-shared items on all platforms? It's win-win. I can securely share share stuff with people whether or not they already have 1Password, I'm effectively promoting your product, it may be less intrusive than asking folks to download and install a free trial, and it would keep working even if my correspondent opts not to purchase 1P. Alternatively, create free viewers for your mobile apps and allow the Windows and Mac trial versions to continue importing secured 1PIFs even after the free trial expires.

I frequently use LastPass for secure sharing with non-1Password users, but if there were free 1P viewer apps out there then I would probably use secure 1Password sharing more often than not. I'd rather evangelize 1P than LP if given the choice, but right now I feel that I don't really have the choice.

jpgoldberg

Hi Ben,

Thanks for the honesty of your remarks and for your suggestions.

The decision to offer non-encrypted sharing wasn't an easy one. And it remains to be seen whether we've given people a tool with which they will shoot themselves in the foot or something that will be used appropriately to fill a real need.

Obviously, we would like to have a quick, easy, secure method of sharing that will work for people. Your suggestion of having a secret key that both parties to sharing have access to is certainly one option that we've been looking at. A public key system is another way to go.

All of these require substantial setup by the users to do the initial key exchange. Once we find a way to make that really simple for people and actually works, then we may be in a position to replace what we have with a more secure sharing mechanism.

What we've found is that there are many problems that have been "solved" by cryptographic techniques and protocols. But getting these to work large scale for a lot of people (who don't wish to learn concepts around Certifying Authority, Certificate Signatures, Signing Certificates, etc) is much more difficult.

So cryptographically we know how to do secure exchange. But we really don't want to run a CA (or equivalent) unless we are sure that we can really get things to work well for people.

I'm sure you don't agree with the decision we've made, but I hope you understand that your misgivings were considered during the process.

Cheers,

-j

–-
Jeffrey Goldberg
Chief Defender Against the Dark Arts @ AgileBits
http://agilebits.com

benfdc

Jeff—

Thanks for the thoughtful response.

Back when 1Password included the File > Export Selected > Encrypted Web Page feature, were there serious customer support issues? If so, then I can understand why AgileBits would hesitate to offer password-protected 1PIF sharing. Otherwise, not so much. Don't let the perfect be the enemy of the good. I don't think that AgileBits needs to solve the certificate trust problem before it offers password-protected sharing.

Sharing (whether password-protected or not) from 1P/Mac is greatly facilitated by the app's tag support. I can easily tag a collection of 1Password items for sharing with one group of people or another. Tags are better than folders for this purpose because I can include the same item in several different shares. It would be great if tag support were extended to other platforms—why should 1P/Mac users have all the fun?

jpgoldberg

Don't let the perfect be the enemy of the good

This is always the difficult question, particularly when it comes to security. And each case must be looked at individually.

The conventional wisdom among cryptographers is that you should either encrypt things extremely well or not at all. Our thinking is heavily influenced by that conventional wisdom. Perhaps we should scrutinize it more carefully, but moving away from the conventional wisdom of the cryptographic community is hardly something to do lightly.

Cheers,

-j

–-
Jeffrey Goldberg
Chief Defender Against the Dark Arts @ AgileBits
http://agilebits.com

benfdc

The conventional wisdom among cryptographers is that you should either encrypt things extremely well or not at all. Our thinking is heavily influenced by that conventional wisdom. Perhaps we should scrutinize it more carefully, but moving away from the conventional wisdom of the cryptographic community is hardly something to do lightly.

The way I see it (and if I'm wrong I'm sure that I am about to learn something new, interesting, and delightful), offering an "obfuscate" option violates the "encrypt things really well or not at all" rule in spades. What is obfuscation, after all, if not ultra-weak encryption and/or ultra-weak stego?

jpgoldberg

You are absolutely correct, @benfdc when you say:

offering an "obfuscate" option violates the "encrypt things really well or not at all" rule in spades. What is obfuscation, after all, if not ultra-weak encryption and/or ultra-weak stego?

The actual encryption that we do here is good, with one enormous exception having to do with key management. Because we don't like to discuss future possibilities ("agile" is part of our name), you should only judge the actual system for what it actually does. And that does violate a sensible rule "in spades". And I cannot provide a justification for doing so at this point.

Cheers,

-j

benfdc

Thanks for the honesty of your remarks. :-)

I'm hoping to be accepted into the 1P4/Mac beta soon, and I'm hoping that I will like what I see when I get there.

My biggest worry about 1P4 at the moment is that when I search this page for the word "tag" I come up empty.