Security concern and feature request: attachments of secure notes are unencrypted


I've noticed that the attachments of "secure" notes are stored unencrypted on the file system. I think that's a misleading definition of "secure" note.

The use case: I'd like to store confidential images. Previously I set up a script which would decrypt the encrypted image, open the unencrypted image with the default application (just call open in the shell) and delete it once the preview application has loaded the file. This way the file contents would be loaded into memory and removed from the file system as soon as possible. Can you set up a similar on-the-fly encryption/decryption for attachments or support images directly?




  • chrisdjchrisdj AgileBits Support

    Team Member

    Hi @duffycola‌,

    I've asked our security chief, @jpgoldberg to look into this and update the thread after he's had a chance to look things over. One of us will be in touch soon.

  • jpgoldbergjpgoldberg Agile Customer Care

    Team Member

    Hello @duffycola‌,

    Attachments are encrypted in all 1Password data formats (except for the completely unencrypted export 1Password Interchange Format), so I would be very interested to understand what leads you to believe otherwise.

    Note that attachment metadata (including file name) is not encrypted in the Agile Keychain format. That is, the file name and type is en clair in the .def file associated with an attachment. So you should keep this in mind when the name of a file might contain sensitive information. This is specific to the Agile Keychain format.

  • Shocking if true.

  • sjksjk oversoul

    Team Member
    edited September 2014

    Hi @revenkyte,

    The Encrypting everything section of the 1Password 4 Cloud Keychain design document has an explanation about metadata (un)encryption that hopefully makes it less shocking. :)

  • jpgoldbergjpgoldberg Agile Customer Care

    Team Member

    I think it is easy for us to forget how "shocking" this legitimately is to most people. So I have full sympathy with @revenkyte‌'s reaction. Realistically, most people are not going to read the details of the data format design documents, so that fact that this is all documented (as well as frequently discussed on our forums) doesn't really help matters.

    It's easy for us to forget how shocking this can be, because we fully know that that if you want synching and/or browser integration, you've got a substantial metadata problem to solve. Different systems address the problem in different ways. We have always tried to document our data formats for a number of reasons, one of which is that this unencrypted metadata shouldn't come as a shock when people they stumble across it. We also don't use obfuscation to conceal that fact that some data is unencrypted. If we were to merely base64 encode that data (or encrypted under a fixed, obfuscated key) people looking around at the data format wouldn't notice the unencrypted data.

    With the data formats used specifically for 1Password 4, we have solved the "Title and URL" problem. (They are encrypted with an overview key, allowing us to quickly build the look up tables once 1Password 4 is unlocked.). There is an enormously wide range of ways that others have approached the problem. I will not be drawn into a discussion of how various competitors do things, but I think that if were to look around more carefully you will find that we are (among?) the best at encrypted the most data, and that we are (among?) the most open about our design. (The big exception is for systems that neither sync, nor have browser integration, as they do not face the same technical hurdles that the rest of us do.)

This discussion has been closed.