Please encrypt or make rich icons deniable on disk

Lucent
Lucent
Community Member
edited September 2019 in 1Password 7 for Windows

I really don't like rich icons sitting totally unencrypted on disk. Is this only for performance reasons, or is it also to mitigate the risk of a single key encrypting several known blobs exposing the key to future unknown weaknesses or new cracking methods?

Rich icons map so precisely to URLs that having them all sitting there is equivalent to having almost every account URL exposed. I'd like to at least see some kind of deniability built into this. It looks like currently icons are in a separate table in the 1Password10.sqlite format and there's an id that corresponds to an item. Provided each icon's id is encrypted and not easily tied to its encrypted item without decryption, this could be easily extended to be completely deniable by doubling the size of the rich icons table and pulling down one extra random rich icon for each one that's used.

At an average of 3KB each, I'd happily sync an extra megabyte and a half for every 500 items with icons if it meant someone who compromised my cached encrypted database had no knowledge of which icons had corresponding accounts.


1Password Version: 7.3
Extension Version: Not Provided
OS Version: Windows 10
Sync Type: 1Password

Comments

  • jpgoldberg
    jpgoldberg
    1Password Alumni

    Thanks @lucent. We know that rich icons don't fully conform to our privacy model. You don't like the fact that in principle we can learned who has log ins for what and we don't like that fact either. It would be much nicer if we could set up a system in which it was provable that we don't retain or use the request IP address information. (Other than at outer layers of load balancing and DoS mitigation.) We've got some ideas about how we might be able to bring the rich icon service more in line with what we'd all like to see for user privacy, but there is nothing being actively worked on now.

    But your concern is different. Your concern is that someone can see what services you have logins for by inspecting your local disk. You are correct that the cached rich icons do make that possible, and perhaps there is a way better protect that. But I should say that I'm more inclined to work on the first problem. I'm not saying "no" to your suggestion, but I am saying that it isn't going to be a particularly high priority when there are other places where we can make more substantial advances in protecting user privacy.

  • You're correct that someone with access to your local machine could use these to determine what sites you've stored in 1Password. It is worth keeping in mind, however, that this is local data. Someone with the access to exploit it likely has access to more obvious paths to discovering the sites you visit and is capable of initiating much more damaging attacks to boot. Your best defense against any local threat is always to protect your machine from compromise in the first place, and based upon other discussions you've started here, I'd wager you've already given that quite a lot of thought and have a strong system in place.

    You can always turn rich icons off, but my advice generally mirrors what's noted in our guide covering rich icons and privacy:

    https://support.1password.com/privacy-rich-icons/

    Specifically:

    One thing to keep in mind when you make your decision is that someone in a position to capture information from your use of Rich Icons is almost certainly in a position to capture what websites you visit (including when you do so) without enabling Rich Icons.

    If you're concerned about this being on disk, absolutely disable it, but given the nature of the threat, it's reasonable to temper concerns in light of what an attacker in a position to exploit this would be capable of regardless of your rich icon choices.

  • Lucent
    Lucent
    Community Member

    I remember this point being made during the controversy about memory not being scrubbed, and it makes sense in that context, but we're talking about plain text on disks where credential data was never entered. 1Password advertises itself as better than a text file with passwords on your computer, and it needs to live up to that. Any backups of the %APPDATA% folder or backups of Android app data (correct me if I'm wrong on this) will contain unencrypted rich icons for every site you have saved. Backups of my computer/phone that have no actual 1Password installation and which the master password has never been entered should not have a list of most logins simply because a user chose to view icons. This is a real chance to get ahead of a problem before headlines come out saying, "Your Windows/Android backup has a list of every website you saved in 1Password."

  • With some hesitation because I feel like there's a risk I'm not understanding your more specific concerns here, @Lucent, I think we may have been a bit unclear in how we framed this. If you've never set up 1Password on a given device there will be no rich icon data on that device. You mention,

    Backups of my computer/phone that have no actual 1Password installation and which the master password has never been entered should not have a list of most logins simply because a user chose to view icons.

    That won't ever be the case. The only way rich icons are ever fetched is if you install 1Password and sign in on that device. I asked one of our web app developers just to be sure that remained true if you use the web app and he said that the web app doesn't cache rich icon data at all so even if you sign in on the web on a device that doesn't have 1Password installed, rich icon data shouldn't stick around. And, regardless, signing in to the web app (or any 1Password app) would require you enter your Master Password. If you've never installed 1Password, there won't be any rich icon data on that device. Even if you've installed 1Password but have never set it up with your data, there will still be no rich icon data there – without any URLs to check, there's no data to fetch. Unless I'm missing something, I can't imagine a scenario where you'd have a backup of any device where you'd never entered your Master Password that contained such data, so my instinct is that you are wrong on that front, but perhaps there's something I'm missing here so feel free to expound if you think I'm overlooking something.

  • Lucent
    Lucent
    Community Member

    Kate, thanks for taking my issue seriously and reaching out to others. I'll be more specific. I use the Windows 10 desktop standalone client which stores its database, 1Password10.sqlite in the %AppData% folder of my computer. That database contains individual encrypted items that the client decrypts as needed, but the rich icons for each item are not encrypted. They're just blobs that can be viewed in the clear if that file is moved or backed up to another machine. Most backup software grabs %AppData% by default, so if I run a backup, an interested party can open that sqlite file in the backup, and while they won't be able to read the text of my items, they will see hundreds or thousands of images, one for each entry with a corresponding rich icon. I think this is more exposure than most people imagine 1Password is giving them.

    Pulling down double the icons into that table and leaving the extras with links to nonexistent items seems like a great stopgap solution that provides deniability without altering the database design at all, which I'm sure is a major hassle with clients across so many platforms.

  • It's no trouble at all, @Lucent! While I may not be the one to make these sorts of decisions in the end, I consider it important to have an understanding of every concern. I see ensuring those who do make those decisions know about and understand those concerns as a fundamental part of my role, and as G.I. Joe said during my childhood, knowing is half the battle, right? :wink:

    So it's the backup itself that concerns you, gotcha. That makes sense and it's an interesting scenario too. Your concern likely isn't shared by many, but the reason for that isn't that it's unreasonable in itself and more the sad reality that backups are paid little mind by a large portion of the public. That doesn't mean we shouldn't – we consider a lot of threats a subset of our customers likely won't to the extent that some design choices made to combat those threats are viewed by some as bugs. Rejecting automatic autofill comes to mind, just to give one example. I can't personally promise any specific change, but I'll be sure to pass your feedback along to our security team so we can consider what might be done. As Jeff mentioned above, the system surrounding rich icons generally isn't quite meeting the standards we'd like it to, so it's something we do have an interest in improving for sure.

    Partially for my own curiosity, but also in hopes it will help me present this better – would you mind sharing more detail about the actual threat you envision here? Specifically, are you assuming this interested party has easy access to that sqlite file or are your concerns the same if your backup itself is encrypted? My backup system is fairly simplistic and mostly local – everything goes on an NAS, save a few "disaster recovery" type files that live in 1Password itself – so my familiarity with options available is somewhat limited so I am curious as to what sort of environment makes this a concern for you.

    Thanks again for taking the time to lay out your concerns and for bringing it up in the first place. We're definitely not perfect, but it's these sorts of conversations that help us improve in the ways that most matter to our customers so your feedback is invaluable and I really appreciate it. :chuffed:

  • Lucent
    Lucent
    Community Member

    We have a lot of devices and make a lot of backups. Assuming what happens on Windows is also how the data format and storage work on Mac and Android, every backup drive (Time Machine), cloud backup (Carbonite, CrashPlan, Backblaze, iCloud), and Android app data backup (Google, Samsung) now have an unencrypted list of most every site you store a login for. If anyone gets their hands on any of these through any method, they now have that list as well. If you're a political dissident in Hong Kong and your Google Android backup or just a backup drive lying around your home is snatched up, 1Password exposes icons for forum.hongkongfreedom.com, you're toast. If you're involved in cryptocurrency and a thief grabs a backup drive from your home and sees a ProtonMail icon in that file along with icons for Coinbase, Livecoin, and cryptocurrencywhales.com, maybe he's coming back to get those actual passwords.

    This is not the same concern as "if they have access to your live device, they can get your password anyway." This is residue left behind by 1Password everywhere that's just in the clear on backups and devices that have never had the master password or key entered. You advertise stuff like travel mode for crossing international borders, so I know you take these issues seriously and understand the implications of the data being on the device, even if it's not locked.

    I have the expectation that 1Password isn't just protecting the actual passwords, but the list of specific places I have accounts. A lot of our dissatisfaction in general with online advertising and data protection is that lists of what we frequently visit, even without personally identifiable information, is highly correlated and tells a detailed story about us as a person. Someone else in another comment long ago made a great list of the kinds of sites that aren't illegal but one still would not want exposed to an adversary or government, regardless of whether our specific password is known.

    IRenounceMyGovernment.com
    IThinkIMightBeGay.com
    IBelieveAnUnpopularIdea.net
    HowToOverthrowATotalitarianRegime.com
    ImAnAttorneyForPoliticalDissidents.com
    IWantADivorce.org
    ProtectionForBatteredSpouses.org
    ImAdoptedWhereAreMyBirthParents.org
    IHaveASociallyUnacceptableFetish.net
    IThinkIMightBeAnAlcoholic.uk

  • AGKyle
    AGKyle
    1Password Alumni

    Hi @Lucent

    We've agreed that we'd like to see improvements and your feedback on how we could make those improvements has been read and will be taken into consideration. But we can't make promises on when, or even if, changes will be made at this time.

    1Password goes through cycles of development. We are in the middle of a cycle at the moment and the changes, bug fixes and new features for that cycle are already planned and outlined and are well in progress. Due to the intensity of this cycle we are not going to look at changing our plans, but we can look to consider this in the future, probably not the next cycle either but I've asked Kate to summarize everything in a place we can look at for future changes.

    I'm sorry if it doesn't meet your needs now, but we have provided a workaround for you to disable rich icons in the application and that will prevent future concerns around what you're backing up and potential access to local devices giving information away. I'm sorry that's the best we can do at the moment but it's what we have available right now.

    I do appreciate the time and consideration you've put into this discussion though. You've certainly brought attention to your concerns and that's the best thing you can do, at this point it's on us to try to figure out what changes, if any, and when we may make to this.

    Kyle
    1Password Security Team

  • Lucent
    Lucent
    Community Member

    Thanks for acknowledging it is an issue worth considering, even if it is not currently a high priority. Perhaps until then it's worth putting a note in the interface or an alert when turning on rich icons saying "there are security implications of enabling this feature."

  • That, or having them disabled by default (or both) were sort of my initial inclinations with this, too, @Lucent, so it'll definitely be part of the discussion. In the meantime, I should also thank you for prompting me to revisit our rich icons documentation on the support site. While it was still technically accurate, it hadn't been revisited in quite some time and needed some love it should be getting soon. Hopefully that will, at the least, be out there to keep folks better informed in the not-too-distant future. :chuffed:

This discussion has been closed.