The security of Documents

[Deleted User]

The new Documents feature in 1Password for Teams raises an interesting question…

My understanding of traditional 1Password vaults is that files that are attached to a note or item are cryptographically protected at all times, unless one expressly exports them out of 1Password. I may be completely wrong on that count, and unaware of limitations, so please do let me know if that assumption is wrong.

The new Documents feature is very promising but it appears to expose all files by default…

After setting up 1Password for Teams from scratch on an OS X machine, I started browsing the Documents category. By "browsing," I mean clicking on entries but not doing anything special to the documents they contain: no double-clicking, Quick-Looking or anything of the sort. Imagine my surprise when I discovered that each Quick Look menu had an option named "Show in Finder" that revealed the file in its naked glory, immodestly exposed to the file system.

It appears that 1Password had, silently and by default, decided to download all my Documents to an unencrypted location of the filesystem, where they can be harvested not only by malicious apps but, quite simply, by backup software…

Is this expected behaviour and, if so, how can 1Password pretend to offer secure storage while automatically downloading files in the clear? If this is expected behaviour, is this new or has my understanding of attachments within 1Password always been deficient?

Since the docs recommend using Documents to safeguard GPG private keys and other such important trinkets, it appears that automatically downloading items in the clear is a somewhat suicidal idea. I must be missing something, mustn't I?

admdly

@Deleted User I've had a look but unfortunately this isn't yet addressed in the Teams whitepaper. Out of curiosity; what directory is the file in on your local system? It could be doing decryption on demand.

[Deleted User]

Hello, @admdly! :) The files are all stored in what look to be randomly-named sub-directories of the 2BUA8C4S2C.com.agilebits Group Container. I agree with you that "decryption on-demand" appears to be the operative idea, but, if so, it seems it is currently way too sensitive and pretty much results in everything being, at some point or other, stored in the clear without a warning…

roustem

@Deleted User All documents are stored encrypted and decrypted on demand. The decrypted files will be securely deleted when you lock 1Password app.

[Deleted User]

I appreciate your kind note, @roustem. It's an honour! :)

The behaviour you describe is not good news, though. Anything that gets stored in the clear on the filesystem for an unknown duration is liable to being snapped up by a process, malicious or otherwise.

Indeed the whole point of 1Password is that it offers encrypted storage. Storing data in the clear, especially sensitive data like private keys, negates the whole point of using the application. Even a plain text document in an encrypted disk image would offer better on-disk protection than the current system.

The decryption currently happens by default. I could understand files being decrypted when double-clicked or exported but, when viewing an entry is enough to trigger the decryption, "on demand" is a euphemism.

I appreciate all the hard work and thought that goes into 1Password, and this is the first time I bump into a real blunder — let alone a blunder large enough to be legitimately called a security hole.

Remember how AgileBits got roasted for leaking out metadata? You even wrote a blog post to defend your position. (A blog post with which I agreed 100% at the time.) This is oh-so-much-worse… :'(

roustem

Hi @Deleted User,

Thank you for following up. I tested it just now and you are right, the decryption happens by default without requiring any additional clicks.

Thank you for discovering this issue. I will let @rickfillion and the team know about this and we will get it fixed asap.

[Deleted User]

Thank you, @roustem! :)

I hate to say this, but I think now would be a good time to demonstrate a rigorous disclosure policy for security issues affecting 1Password in general, and 1Password for Teams in particular.

This is the second legitimate issue I have seen reported in the forum (the first being here) and I am a little uncomfortable at the thought that these two known issues have not been brought to the attention of your user base yet. This is not worthy of a company whose hard-earned reputation is built on top-notch security and accountability.

It would also be good to discuss QA with your engineers… I understand there is a lot happening at AgileBits right now, what with Android, Windows, and an entire new environment on the web, but such bugs should not make it past the design phase, let alone into a downloadable product. :(

ntimo

@Deleted User Do you have a guide to reproduce this? Issue I would like to see it for myself.

[Deleted User]

Hello, @ntimo! :) As far as I can see, all you need is a Document entry in 1Password. No special steps are involved, but here goes… Anything attached to a Secure Note in "classic" 1Password will have been turned into a Document for you, so you need not have created one manually.

1. Click on Documents to display that particular category.
2. Click on any entry.
3. Hover over the document area, whether a preview is shown, or simply an icon.
4. Click the little downwards arrow within the Quick Look button that appears on top of the document.
5. Select "Show in Finder."

On my machines, the document is automatically shown in the Finder (which is brought to the front), in a thinly veiled location in your Library's Group Containers. (I say thinly veiled because of the apparently random directory name and .noindex extension of the parent directory, but these are hardly security measures.)

Notice that at no point were you shown anything that either asked you to download the document or even implied that it would be downloaded and stored on disk in the clear.

roustem

@Deleted User I agree with you that documents should require an additional action to perform the decryption.

However, I can see the alternative point of view as well -- if you selected the item, it means that you want to see the contents of the document and the app shows it you. To show the document using QuickView, it must be decrypted into a temporary location.

[Deleted User]

@roustem — I do see your point. However, there are three reasons why I still consider this behaviour to be a bona-fide security issue and not just a "feature."

The first is that it is extremely inconsistent. Whenever I "reveal" a password in 1Password, or look at a Secure Note, I wish to see the item but I do not want it to be decrypted to disk. In fact, the whole point of 1Password is that it protects data both at rest and in memory using a wide array of techniques. There is no valid reason why a user clicking on a Document should be construed to request that it be decrypted and saved to disk. Otherwise, why doesn't 1Password just dump a cleartext database every time it unlocks a vault?

The second is that this could be implemented securely: the current design was not forced on you by some tricky edge case. For example, the documents could be written to a temporary secure disk image, which would be mounted invisibly. This would enable you to offer Quick Look functionality, and generally perform open and save operations, without ever writing things to disk in cleartext. (And I shall forego discussing whether Quick Look belongs inside 1Password in the first place, making this whole caching thing even less of a necessity.)

Finally, I would disagree with your analysis of the user's intent. In a list-based application like 1Password, selecting an item implies nothing of significance. Clicking a button within an item's view does mean something — which is why your Copy, Reveal, etc. controls are tucked there. Clicking an entry may be the result of an error, an attempt at bringing the window back into focus, etc.

Sorry, but I really don't think this one can be called a "feature"…

jpgoldberg

[Oops. I hadn't read through and tested everything before replying. I've edited some of what follows to correct for this.]

Hi @Deleted User.

I am sincerely sorry if we and 1Password are giving you the wrong impression of when things are getting decrypted and when decrypted instances of the data exit on your system. We need to take a look at how we are wording and presenting things.

On the whole, you should assume that once it is unlocked everything is decrypted and then all decrypted data is removed when it is locked. It's actually more complicated than that, as not everything gets decrypted at that time.

Some things only get decrypted when needed, and attachments and documents have been among these. But they will, in general, remain decrypted until 1Password is locked.

The actual details differ by platform. On mobile platforms, 1Password will first only decrypt the overview information about items when it is unlocked, and will not decrypt the details of an item until those items are requested, but they will remain decrypted in memory until locked.

Participles and adjectives

We've got a slight linguistic problem here. When we say, "a document is decrypted when you first open it" we mean that that is when the actual decryption process takes place. It gets decrypted [participle] at that time. But a decrypted [adjective] copy of it may remain in memory or, in the case of documents, on disk. The linguistic difficulty we face is that pretty much every passive participle in English can be used as an adjective.

I had not considered this ambiguity until this discussion. Saying a “a document is only decrypted when you view it” was never meant to mislead. But I see that it has, and so we need to be more careful in our wording and presentation.

Documents are special

1. Decrypted documents are written to disk (unlike other decrypted data), and removed when 1Password exits or is locked.

Because decrypted documents are written to disk, we do as you suggest, need to take a closer look at returning to the older practice of only decrypting them as needed.

Because documents are large and their contents are not needed for searching and sorting your items, we use to defer decrypting them until they are specifically called upon. Non-document data may get decrypted before it is explicitly requested because it is useful for searching and sorting. On the desktops, where we have more processing power and memory, 1Password will typically decrypt most of the data shortly after unlock. But even on the desktops, 1Password will defer decrypting documents until needed.

As @roustem said, we will take a look at the policy of now decrypting documents upon unlock.

On mobile devices, 1Password may only decrypt overview data (useful for sorting and displaying in an index) and defer decrypting item details. But this isn't a behavior you should count on. Once you have unlocked 1Password, you should consider that data exposed to anyone acting as you on that device until 1Password locks or exits.

So even though some things will have their decryption deferred, you should pretty much think in terms of the vault metaphor. When the vault is open, everything in the vault is available (even if sometimes we defer decrypting some items.)

[Deleted User]

Hello, @jpgoldberg! Thank you for taking the time to reply in such detail. :)

On the whole, you should assume that once it is unlocked everything is decrypted […] It's actually more complicated than that […]

If such is the case, could you point me to the actual plain-text file or database where 1Password dumps all my passwords every time it is unlocked? I should love to take a butcher's at it.

Documents are written to disk in cleartext, where they could be snapped up by any backup process. You cannot compare the decryption of Documents with the decryption of Passwords unless you also happen to write a cleartext copy of the passwords to disk…

[T]hey will remain decrypted in memory until locked.

There is no doubt that things must be decrypted to be accessible. Nevertheless, there is a big difference between decrypting in memory and decrypting on disk.

But a decrypted [adjective] copy of it may remain in memory or, in the case of documents, on disk.

Your said it yourself: "in the case of documents." There is no earthly reason (from a data security standpoint) why Documents should be treated differently from Logins, Passwords or Secure Notes, especially when the UI makes no distinction between various kinds of entries. (Remember that it is not necessary to click on the Quick Look button for an item to be downloaded, decrypted, and written to disk. The action cannot be stopped or cancelled.)

Saying a “a document is only decrypted when you view it” was never meant to mislead.

Oh, I would never accuse you of trying to mislead everyone. We are amongst friends here.

However, I do think you are mis-reading the semantic issue. The problem, as I see it, is that you mix up "viewing the entry" and "viewing the document." The current UI makes the assumption that viewing a Document means that the user wants to download the document, decrypt it, and save it to disk. This would be akin to Apple decrypting FileVault disks every time they are mounted in Finder.

As @roustem said, we will take a look at the policy of now decrypting documents upon unlock.

Let me put it this way. I am a friendly, very average user posting in a semi-private forum and we are splitting semantic hair about whether you decrypt data too soon or the user's intent is what it is.

Given what happened when it was "discovered" that your keychain format could, under certain circumstances, leak a small amount of non-essential metadata, I am pretty sure that the security community will not take too kindly to your spewing documents on the hard drive.

I have an exceedingly low profile and I do not wish to cause any trouble to anyone, let alone a company I have had tremendous respect for for many years. In fact I really doubt that I could cause trouble to anybody — nor do I want to.

However, I do not take kindly to AgileBits selling a secure storage product that fails to store something securely and slipping it under the rug as a UI issue. This is what Apple does and we love them for it but this is also why we don't use iCloud Keychain.

If 1Password were merely an exercice in nice GUIs, we would all be stashing our passwords in TextEdit documents and pretending it was fine, since our hard drives are encrypted by FileVault. (Which is, in essence, what you are saying.)

I must therefore ask you to do more than "take a look at your policies." This will not cut it. You are putting user data at risk, have been informed of the fact, and it is now up to you to take corrective action. I am very sorry I have to say so so disagreeably, but I fail to see what else can be done at this point.

rickfillion

Hi @Deleted User,

I want to start by thanking you for reporting the other flaw (conceal passwords on the iOS app). That one's very cut and dry, and will get fixed really soon. I also want to thank you for starting this conversation here.

Reading through this thread, I'm seeing some incorrect information that I'd like to clear up, then we can talk about what we could do to make things better.

My understanding of traditional 1Password vaults is that files that are attached to a note or item are cryptographically protected at all times, unless one expressly exports them out of 1Password. I may be completely wrong on that count, and unaware of limitations, so please do let me know if that assumption is wrong.

That assumption is incorrect. QuickLooking an attachment (not document) behaves much as you're seeing with Documents. The file is decrypted to disk, and the file url is handed off to QuickLook. Upon lock we delete the files decrypted files.

It appears that 1Password had, silently and by default, decided to download all my Documents to an unencrypted location of the filesystem, where they can be harvested not only by malicious apps but, quite simply, by backup software…

Not really. If the backup software listens to the extended attributes that get set by the CSBackupSetItemExcluded API then this directory should never get backed up. This API was originally added for TimeMachine, but I would hope that all backup apps make use of the xattrs that it sets by now. We specifically ask that any directories where we decrypt attachments and document files get excluded from backups via CSBackupSetItemExcluded.

There's a similar concern here with Spotlight indexing. Obviously you don't want the spotlight indexer to start indexing sensitive files we put on disk. We protect against that as well, which is as simple as using a directory name that ends in noindex.

The current UI makes the assumption that viewing a Document means that the user wants to download the document, decrypt it, and save it to disk.

This is incorrect. I don't want to split hairs, but this is an important split... Viewing a Document item does not mean that the user wants to download the document file. We never download the file without having you explicitly request it. Here's how it's supposed to work:

Video showing downloading item

When you select a Document item, we look to see if you have an encrypted copy of it downloaded locally. If you don't, then you should see what I show in this video, which is a Download button. Downloading it triggers: download, decrypt, view.

When selecting an item, and you DO have an encrypted copy of it downloaded... we assume that you're going to want to view the file itself. So we decrypt it and view it. This is what you're seeing in the video when I switch back to Documents in the sidebar.

Locking the app deletes all decrypted versions of the document files, but it does not delete the encrypted versions. I consider the encrypted versions to be a cache of what's on the server.

Let's Talk Future

So... let's make this better. I'm actually going to refrain from creating the tickets on our side that defines the changes we need to do until I've heard back from you. You clearly care very much about this, and I want to make sure your voice is heard before we rush to implement anything.

I think there are multiple issues at play here. The first is that the UI doesn't match your mental model of how the app should function. Selecting an item should not imply decryption. I think it would make sense for us to make the user explicitly decide to decrypt the file. Our thinking here was that if you're going to a Document item, there's a really high probability that you're wanting access to the file data. But I can see how that could be an incorrect assumption on our part.

The second issue is where we're decrypting the files to. You've raised concerns about what could happen to those decrypted files even outside of the context of malicious intentions. I hope that I've relieved some of those concerns, but we're always looking to do better... so let's discuss how this could be better.

To discuss how we could do better, we first need to talk about our requirements as they should inform our decision making process.

The first requirement is simple: Sandboxing. Whatever we build has to function equally well in a sandboxed environment since we sell the app on the Mac App Store.

The next requirement is that we can't be expected to provide a viewer for all file types ourselves. Right now we're using QuickLook, which is provided by the system and it can preview a lot of things. Even things for which the system doesn't understand, thanks to its plugin architecture. There's just too many file types out there, and we don't have the development resources to make viewers for them all. This means we have to be willing to provide this responsibility to another component of the system. Even QuickLook fails in some cases though. So this means we have to provide a facility for the user to get access to the unencrypted file in such a way that they can do whatever they want with it (right now this is accomplished via the Show in Finder button).

The next requirement ties in with the previous, but goes one step further. I need whatever we design to allow an external editor to work on an encrypted copy of the file. Maybe that means taking it out of the quarantined area and putting it in the wild west at the user's request during editing. We haven't defined this part yet, we just need to make sure we're not closing the door to it.

You had some ideas here that I'd love to learn more about. Specifically I'd like to hear more about this:

For example, the documents could be written to a temporary secure disk image, which would be mounted invisibly...

I assume by "secure disk image" you mean an encrypted sparse bundle. Is that right? Could you tell me what you mean by mounted invisibly? I see that hdiutil has a -nobrowse option which says "render any volumes invisible in applications such as the OS X Finder." But as far as I can tell, this would still end up broadcasting NSWorkspaceDidMountNotification which contains the path that was mounted (which would mean anyone looking to do anything malicious would still have full access). I suspect that this is only protected as a UI mechanism in Finder itself. Can you tell me what this would end up protecting against beyond what I've mentioned we already do? I'll admit that I like the idea that the bits that get written to the disk platters itself wouldn't be cleartext, so there's some value there.

I'm looking forward to hearing from you.

Rick

[Deleted User]

Hello, @rickfillion! :)

I'm afraid I cannot take any credit for the iOS display flaw… That would be @GeoTrove's baby! :+1:

QuickLooking an attachment (not document) behaves much as you're seeing with Documents.

Oops, yes. This does not surprise me. I am sorry I forgot to mention it. My excuse would be that I never use Quick Look from within 1Password, but it is indeed perfectly natural for items to be made accessible before they are handed off to Quick Look for processing.

If the backup software listens to the extended attributes that get set by the CSBackupSetItemExcluded API then this directory should never get backed up.

Pardon me, but this is like saying that trespassers and pickpockets will heed public notices about rules and regulations, or that a robots.txt file on a website constitutes adequate protection against malicious robots.

More to the point, there are many legitimate tools that know nothing about the APIs you mention, including nearly all UNIX-based tools, disk cloning utilities, cross-platform backup solutions (which are likely to be used by your enterprise customers), etc. If 100% of the tools that legitimately run on an OS X machine could be expected to skip these directories, the issue would not be so dire, but we both know that too many applications to count will blithely ignore platform conventions, whether on purpose or by accident.

I don't want to split hairs, but this is an important split...

Please do, I enjoy splitting hair. All kidding aside, I enjoy understanding the thought and processes that underpin 1Password.

If you don't, then you should see what I show in this video, which is a Download button.

What you show in the video would be (almost) acceptable to me and, I believe, to most users. I still think you should pop up a warning stating, at least once, that clicking on the icon will download the document in the clear and make it available to third-party Quick Look plugins, but I would not be making such a fuss if 1Password always behaved in the way your video describes.

Alas, that icon was nowhere to be seen for me: the items just downloaded right away. In fact, I have been keeping an eye on the cache directory and, while most items have been cleaned up at some point, they were once nearly all downloaded without my having clicked on anything remotely looking like a Download button.

This seems to imply that, somehow, 1Password had downloaded all my documents in encrypted form at some point, and was displaying them as you do in the video when returning to the Documents. I fail to see how this could have happened since I installed 1Password for Teams from scratch, after having removed all traces of "classic" data.

When selecting an item, and you do have an encrypted copy of it downloaded... we assume that you're going to want to view the file itself.

Since it is apparently possible for a user to have such an encrypted copy on disk without being aware of it (see above), this policy appears to be dangerous. The application makes an assumption that it simply should not.

Furthermore, even if I had downloaded the encrypted document on purpose, Documents would still be the only category that is dumped to disk silently when viewed. That, in itself, would still be an genuine issue.

1Password offers a box that must be explicitly checked before third-party applications such as Alfred and Quicksilver can access its data. I believe it was implemented both because of the "holes" that must be punched in your protections for the integration to work and because you know that you cannot trust third-party apps. Why should it suddenly be acceptable to trust the filesystem and Quick Look, whose plug-in architecture opens oh-too-many doors to contemplate?

Locking the app deletes all decrypted versions of the document files, but it does not delete the encrypted versions.

That makes perfect sense.

The first is that the UI doesn't match your mental model of how the app should function.

More to the point, the UI is inconsistent. All items but Documents, when selected (or when the vault is unlocked) are decrypted to memory. Documents are decrypted to disk. My mental model is neither here nor there: if 1Password actually dumped every single password to a text file every time I view it, I would not be using it, but I would not be calling you out on this, either.

Our thinking here was that if you're going to a Document item, there's a really high probability that you're wanting access to the file data.

I feel this is true when the action required to display an item is different from what is required to select its container. For example, in "classic" 1Password, opening a Secure Note does not appear to open or decrypt its attached files. In the new setup, the Document and its containing entry have suddenly become one and the same.

The next requirement is that we can't be expected to provide a viewer for all file types ourselves.

This is not something for me to say and it is obviously outside of the scope of this discussion but why the sudden passion for Quick Look? Do people really store movies in 1Password and expect to watch them from within their secure database?

I have read your colleagues repeatedly state in the forum that you were not interested in entering the secure storage business (which I regret but well understand) and yet we are discussing ways to preview files of exotic types from within 1Password.

I would argue that such a feature is totally unnecessary, especially given the kind of things that are most likely to be stored in 1Password: license files, GPG keys, revocation certificates, blobs with little, if anything, to be seen. Still, I assume you have a good reason to be intent on enabling Quick Look in the application, so this is something of a moot point.

Can you tell me what this would end up protecting against beyond what I've mentioned we already do?

We are entering an area where I bow to your much superior knowledge.

My understanding is that if the document must be made accessible to the file system (for Quick Look to parse it, for example) it could at least be made available in a way that does not cause it to be written to disk unencrypted. This, at least, means that any backup process (or malicious app) swiping the disk itself while the document is cached in unencrypted form would only be able to snap up the encrypted source file. It would also prevent "un-deletion" utilities from recovering the cached copies, since Secure Erase is notoriously unreliable on SSDs — so unreliable that Apple is in the process of removing it.

Encrypting the image with a random password, to be kept in memory but never written to disk, would prevent data recovery after the fact. Furthermore, mounting the disk image as a read-only volume would prevent tempering with the evidence (so to speak), for example to trip Quick Look into loading a booby-trapped file.

Of course, if the document is made available to Quick Look, it will be made available to other processes that do not honour the sandbox, including malicious processes. I assume it could be read from memory easily, and it can, of course, be read from a randomly-named mounted volume. However, it cannot be snapped up by accident and it cannot be snapped up by a process that only looks at the boot volume, which limits the attack surface. (Would a Trojan Horse scan all mounted volumes? Possibly… But given the performance penalty they may be reluctant to do so.)

Coupling this with a warning that states that the document will be unencrypted temporarily would, I believe, provide an acceptable balance between convenience and security. Even better, Quick Look integration could be a checkbox (even if ticked by default) in the Advanced preferences, so that those of us who want to "seal" 1Password off from third-party interference could do so. (Hey, you just added Secure Keyboard entry to the application, so third party interference is a real threat.)

This is what we do when we fill our passwords into websites: we know they could be snatched from the pasteboard or from the web browser (when auto-filling) or even while in transit from the extension (in one of the recently demonstrated attacks, against which I believe you have implemented protections) but we know they won't be snatched from the disk itself.

I may well be missing the obvious. Again, far from me the thought of pretending I know of a perfect solution. My key concern is about the automatic decryption of the Documents, my experience of the feature being radically different from yours.

rickfillion

Hi @Deleted User,

Thanks for the reply. :)

This seems to imply that, somehow, 1Password had downloaded all my documents in encrypted form at some point, and was displaying them as you do in the video when returning to the Documents. I fail to see how this could have happened since I installed 1Password for Teams from scratch, after having removed all traces of "classic" data.

Did you the conversion of your "classic" data on this Mac? If so, what did you do to "remove all traces" of the classic data? When converting an attachment to a Document, we re-encrypt the attachment data to put it in Document form and it gets placed into the download cache. And so on the device that did the conversion they're in downloaded state already. Is it possible that this is what you're seeing?

This is not something for me to say and it is obviously outside of the scope of this discussion but why the sudden passion for Quick Look? Do people really store movies in 1Password and expect to watch them from within their secure database?

QuickLook has been a part of 1Password for a long time. It's nice because can allow you to view the file within the context of 1Password. Oddly enough, one of the first things we did with Documents during development was to throw a movie in there. Mostly for the "will it blend?" fun of it. Right now use cases are limited by the 5MB limitation which is imposed simply because it matches the attachments feature. We'd like to open up documents to larger files one day.

I have read your colleagues repeatedly state in the forum that you were not interested in entering the secure storage business (which I regret but well understand) and yet we are discussing ways to preview files of exotic types from within 1Password.

There's a difference between wanting to get into the secure storage business, and wanting to make sure we don't limit what our users can do. There are plenty of non-exotic types that would give us grief... we just like to jump to the exotic ones to illustrate the point. :)

Going Forward

Thanks for elaborating on your thoughts about what we could do to make the decryption process better. I like where you're going with this.

So here's what I'm going to do...

Shorter term:

• Decryption of Document files needs to be explicit. Before decrypting it to load it into the QuickLook preview we'll require that the user click a button stating their intention.
• We'll try to find a good way of informing the user about what's going on here. Maybe that's an alert when they decrypt the file, maybe that's something else. I'll work with our designer to think of something good here.

Longer term:

• I'm going to take time to do more research into where we could write the unencrypted files. I say that this is "longer term" not because I want to kick the can down the road, but because this is something that's going to take some time and I don't want to set the expectation that this will be taken care of next week. You'll have to trust me that I'm taking this seriously and would like to see us do better if possible.

How does this sound to you?

Rick

ntimo

@rickfillion I just wanted to give my +1 for the short and long term plans. And also thank you for the explaination about how the documents feature works. I will have to try the movie think somehow lets try to get a 4 mb movie :unamused:

[Deleted User]

Thanks for your kind and detailed reply, @rickfillion! :)

On the device that did the conversion they're in downloaded state already. Is it possible that this is what you're seeing?

That is not only possible, that must be it. Touché !

I installed a fresh copy of 1Password on an account from which I had removed all the files and directories used by 1Password or 1Password Mini, which I had located previously by running searches for "onepassword" and "agilebits" on the whole drive. I don't trust Spotlight, especially not in Libraries, so I used DevonTechnologies' excellent EasyFind, and I am pretty certain that I had caught everything. I realise this was not required, but I had been fighting intermittent issues with 1Password Mini, so the time seemed ripe to do a clean-install.

Of course, I then had to import my data from backups after having signed into 1Password for Teams, so the files were probably cached locally at this point. This explains why I never saw a download button and never got a chance to oppose the decryption.

By the way, rem acu tetigisti, Rick: there is no warning anywhere about the new behaviour of Documents and, regardless of all security issues, this is sprung on users as a surprise. (I think @stmontgomery would agree with me on that particular point.)

In any case, it strikes me that keeping a local encrypted copy of all the Documents is pretty desirable anyway, but that is a discussion for another thread. (You saw my post on the backup thread and I thank you for your kind reply in there as well.)

QuickLook has been a part of 1Password for a long time.

This is true, of course. But then it seems that it could be ignored safely, as long as one did not play with it, which is no longer the case.

There's a difference between wanting to get into the secure storage business, and wanting to make sure we don't limit what our users can do.

This is also true, of course. It seems that my usage of 1Password is unbearably dull, as it would never occur to me to stash anything worthy of being Quick Looked in there, but of course it takes all kinds to make a large user base.

Before decrypting it to load it into the QuickLook preview we'll require that the user click a button stating their intention.

That sounds like it would solve a good 80% of the issue. And please keep the idea of a preference in mind, as I can foresee it being a very welcome Team control down the line. For example, administrators may want to make sure that GPG Keys and revocation certificates stay protected until they are purposefully exported. Something along the lines of "Never integrate with third-party apps and services except for the official extensions."

I say that this is "longer term" not because I want to kick the can down the road, but because this is something that's going to take some time and I don't want to set the expectation that this will be taken care of next week.

Oh, of course not. No worries on that count.

How does this sound to you?

I appreciate your time and your looking into this, and we both know I have no choice but to sit tight and wait. So it sounds, in effect, like the only possible outcome of this situation. Still, I do appreciate the time you took to look into it, which I know you were by no means compelled to take, and I am grateful for it. :)

Nevertheless, at the moment, countless documents are being stored on users' hard drives with no warning of that fact. Whatever your security disclosure policies are, I believe action should be taken to alert administrators to this fact and give them a chance to clean up their backups and/or move documents back into secure notes or outside of 1Password until this is fixed. I understand that the fix will take time, and I understand the thoughts that led to this situation, but in no way do any of these things negate the very real existence of an issue en ce moment.

rickfillion

Hi @Deleted User,

OK so it sounds like we figured out why you've got your Document files in a downloaded state already. Good good.

I've created these cases on our side:

• OPM-3795 : To require an explicit click from user before decrypting a Document file to disk
• OPM-3797 : To work with our designer to come up with a good way of telling the user what's going on with the decrypted files
• OPM-3798 : To research alternative ways to write unencrypted files to disk to see if we can do better

Thanks for bringing this concern to us. Please don't hesitate to bring others. :)

Cheers.

Rick

ref: OPM-3795, OPM-3797, OPM-3798

rickfillion

@ntimo : the movie thing was more fun before we put the size limit in place. :)

peja

After digging through the document download issues I am also concerned about the security of my documents stored/attached to 1Password. As an example I attach a scanned TAN list as PDF (PIN codes for banking transactions in Germany) to my bank login item which I download/view when I am logged into my banking account and make a money transaction.

1Password desktop-app:

• what if the app crashes before it gets a chance to delete the temporary unencrypded document?
• deleted files can be recovered very easily - what about secure delete (overwrite with zeroes)?

1Password web-app:

• documents are downloaded (on click) to my browser download directory - but I have to remember to delete them manually
• my current workaround: I point the browser download directory to a RAMDisk which I use for critical stuff

How about 1Password automatically creating a RAMDisk to temporarily store unencrypded documents which is guaranteed to be discarded at least upon reboot? Or give the user a chance to configure a download directory within 1Password so I can point it to a RAMDisk?

Thanks and regards,
Peter

Ben

Hi @peja,

Thanks for your continued feedback on this functionality. Unfortunately your suggestion of using a RAMDisk will not (currently) work due to sandboxing restrictions. Sandboxed apps, such as 1Password for Mac from the Mac App Store, are specifically prevented by Apple from manipulating disk images. We also would not be able to do such a thing from the web app.

We are still hopeful that we may be able to improve this in the future, but it doesn't appear any change will be possible until at least macOS 10.12.

Ben

ignacioj

Hi
When you open a document with "quick look", it remains open even after 1Password automatically locks when the mac goes into sleep mode. I would have expected that the file was closed when 1Password locks.

Great application anyway.
Thanks

Ignacio

AGAlumB

@ignacioj: Correct. I'm sorry for the confusion here! Keep in mind that QuickLook is just another external app. So this is no different than if you open an image in Preview and then delete it: it's already loaded in the app and resident in memory, and 1Password cannot (and frankly should not, for both security and stability reasons) be allowed to mess with another app's (or the OS's) memory space.

More to the point, in order for any app to read a file stored in your 1Password vault, it needs to be decrypted to a temporary file. 1Password can (and does) remove this afterward, but again, if the app still has it in memory, it will remain there until closed and purged by either the app itself or the OS. I hope this helps clarify things. Let me know if you have any other questions! :)

ignacioj

Thanks @brenty

AGAlumB

Any time! :) :+1: