1Password doesn't encrypt all data

Green

Hi 1Password Team,



I recently was going through the 1Password .sqlite file to see what information a potential theif could get (My IPhone was stolen recently <img src='http://forum.agilebits.com/public/style_emoticons/<#EMO_DIR#>/skype_sadsmile.png' class='bbc_emoticon' alt=':-(' /> with the 1Password app on it). I was not pleased to find out all the header/title information in a 1Password file is completely not encrypted. This means that anyone with a text editor could mount the IPhone, open that file, even if the IPhone has Data Protection Enabled AND a passcode, and get access to 1Password contents.



This includes:[list]

[*]All the note headers (The title of what the note is about)

[*]All the site headers (All the sites you go to)

[*]All your application licenses (All the applications you have on your computer)

[*]etc

[/list]

For other readers, the *contents* are encrypted, but the titles and header information are not. I still consider this sensitive information (in particular, because one is under the complete impression through your marketing that ALL information in your 1Password app vault is encrypted 'safe and secure') and unhappy that now all my the information is 'out in the wild'. If I had known that part of the contents of 1Password would not be safe, I would have structured my notes differently to not include confidential information in the title and removed more sensitive websites (yes, they get a list of all your 1Password sites).



This clearly makes the 1Password IPhone vault not entirely effective - I'm not impressed.

khad

Welcome to the forums, Green! Thanks for asking about this. We try to be as open as possible about what data is encrypted and what is stored in the clear for indexing and searching.



[color=#333333]The Agile Keychain is nearly identical to the Mac OS X keychain in terms of what is kept encrypted and what is left open in plain text. The distinction is an important trade-off between security and convenience. The more that is encrypted, the less a would-be thief can access, but it is also necessary to leave enough open to allow applications to freely access certain items without needing to decrypt every single entry each time. The Mac OS X keychain nicely balances security and convenience, so the Agile Keychain follows suit.[/color]



[color=#333333]Here is an example entry from the Agile Keychain:[/color]



[CODE]{

"title" : "dave @ AWS login",

"locationKey" : "perfora.net",

"encrypted" : "...",

"typeName" : "webforms.WebForm",

"securityLevel" : "SL5",

"openContents" : {

"createdAt" : 1216012929,

"updatedAt" : 1216012929,

"usernameHash" : "...",

},

"location" : "https://webmailcluster.perfora.net:443/xml/webmail/Login",

"uuid" : "0A522DFCAE6442D991145BC76E55D343",

"folderUuid" : "A90D66D1A4E34481BDF03DDEA9F511AC"

}[/CODE]



[color=#333333]As you can see, not all the information is encrypted. Most notably, the name/title of each entry (i.e. dave @ AWS login) and the location/URL are open. Having these open allows 1Password to organize your data and display it without suffering the performance hit of needing to decrypt every single item.[/color] All the truly confidential information is stored in the encrypted section of the file.



The original form of the Agile Keychain left its assessment of password strength among the unencrypted data. This was [url="http://blog.agilebits.com/2011/12/staying-ahead-with-security/"]removed in 2011[/url].



There were great [url="http://help.agile.ws/1Password3/os_x_keychain_history.html"]advantages[/url] to moving to our current data format, the [url="http://help.agile.ws/1Password3/agile_keychain_design.html"]Agile Keychain format[/url]. It is far more scalable than what preceded it, and syncing is far easier and more reliable. It also encrypts everything except what is needed for indexing and sorting items and finding potential matches for websites. It was in this move from to the Agile Format that moved from using 3DES to the more modern AES-128 for our encryption. More importantly this is when we protected your master password with PBKDF2, which makes it much harder for automated password guessing systems to discover your master password. A full explanation of this is in our document on [url="http://help.agile.ws/1Password3/cloud_storage_security.html"]cloud storage security[/url]. It has also been much discussed in here in these community forums.



When we introduced [url="http://help.agile.ws/1Password3/cloud_syncing_with_dropbox.html"]Dropbox syncing[/url] for iOS and 1Password for Windows, it was so awesome that everyone wanted to use it. It was then that we renewed discussing what we can do to give your data more privacy protection.



We like to be agile and never (well…, hardly ever) announce features before they are delivered. There are two aspects of our next data format that we are willing to announce. It will have even more of your data fully encrypted, with the remainder well obfuscated.



Another security enhancement that is already available is an increased number of [url="http://blog.agilebits.com/2011/05/05/defending-against-crackers-peanut-butter-keeps-dogs-friendly-too/"]PBKDF2 iterations[/url] used when processing your master password. This will make it even harder for anyone to try to run software that would automatically guess master passwords.



1Password has always been designed with the security feature of only decrypting the smallest amount of information needed at any one time. That has meant that decryption happens frequently instead of just decrypting all of the data when you enter your master password. With improvements in computer processing power over the past few years, we will now be able to switch from AES-128 to AES-256 and encrypt even more of the data (and obfuscate what little is not encrypted) without having to compromise on performance.



Please let me know if you have any other questions or concerns. I am more than happy to help.



Cheers,

Green

Hi khad and thanks for your thorough and timely reply.



Everything you have described makes sense from a technical and seamless user experience perspective. Frankly, I don't mind have a portion unencrypted as may be technically required to balance speed and security as you describe. My gripe comes from two things:



1. The user interface with the open and closed 'vault' is misleading as it leads the end user to believe everything in the 'vault' is secure. Similar to a physical vault, I don't put items in the vault thinking only a few of the items in the vault are secure, I think [b]everything [/b]in the vault is secure. I recognize in your website documentation you might describe somewhere in more detail exactly how your encryption works, but for the vast majority of users, myself included, the symbol of putting things into a vault leads one to believe the items in the vault are safe. I've used this product for several years and not once have I seen readily available notification that would lead me to believe otherwise.

2. There is no notification once the vault is open as to what items are secure and what are not secure. When I open a website, I clearly can see what site is secure by looking at the https: and looking for the little lock sign or different highlighted URL bar to determine when I am on an ecrypted site. The distinction of what is encrypted and what is open is not made at all in the application and leads one to a false sense of security - or perhaps, confusion as to what is secure and what is not.



Clearly changing what is encrypted is not beneficial for the reasons you have mentioned. Might I recommend then a user interface change to clearly inform users what is and is not secure. For example, a "lock" icon beside the contents of the notepad or highlighting it in yellow with the title in white to denote what is and is not safe? As of right now, everything 'in the vault' is quite misleading.

khad

[quote]Clearly changing what is encrypted is not beneficial for the reasons you have mentioned.[/quote]

The reasons I mentioned above were for the original design. We always believed that a day would come when processing power made it feasible to make the changes we are now working on. As I also mentioned, improvements in computer processing power over the past few years have now made that feasible. Therefore, the solution we are working on is to encrypt all the data (or nearly all of it, with the little bits that are not technically [i]encrypted[/i] very well obfuscated).



The easiest way to see at a glance what is not currently encrypted in your data file is to look at the [b]View > Columns[/b] menu. Everything in that menu is used for sorting your data. The only exception is the aforementioned password strength. We changed that very recently, so it is still listed in the [b]View > Columns[/b] menu but is now calculated on the fly. More details are available in the blog post to which I also linked above:



[url="http://blog.agilebits.com/2011/12/staying-ahead-with-security/"]http://blog.agilebit...-with-security/[/url]



The [url="http://help.agilebits.com/1Password3/agile_keychain_design.html"]keychain design document[/url] makes it clear that some data is not encrypted. But to better understand what information is and isn’t encrypted in your 1Password data some background is required. This will involve a change of metaphor for how to think about what it means when your data is locked or unlocked.



For your security, 1Password decrypts as little information as possible at any given moment. 1Password presents itself to the user as either “locked” or “unlocked.” The impression someone might get from this is that when 1Password is unlocked, all of the information is suddenly decrypted. This, however, is not how 1Password really works. A system like that would suffer from having far too much of your sensitive information decrypted in computer memory or worse written to disk. 1Password gets around this problem by [i]only decrypting the particular item you need at any given time[/i] and then forgetting that information when it is no longer needed. So instead of thinking of an unlocked state as a vault with all of your information being open, it is better to think of things differently.



Imagine, instead of a vault that is locked or unlocked, a room full of locked boxes. Each box requires a key to open it, the same key. When you have entered your master password, that key is available although all of the boxes still remain locked. At various times 1Password will select a box and unlock that particular one. When it is done with the contents of that box, it will lock it again.



When you go to a login page, say [url="http://www.example.com/Login.php"]http://www.example.com/Login.php[/url], 1Password needs to find all of the boxes that could potentially be a Login for that location. It also needs to present you with a list of those potential Logins so that you can choose among them. Conceivably (but incorrectly), 1Password could go and unlock each box in the room looking through their contents to determine which ones are potential matches. But that would take a very long time. Opening a single box doesn’t take any noticeable time, but opening all of them would be prohibitively slow.



What we have done is put labels on the outside of each box. The labels contain, most importantly, the web location associated with that Login and the title that you gave to that Login. This way 1Password can scan the locations quickly without having to unlock any boxes. It can then present you with the titles of the ones that are potential matches. Once you select to fill with a particular login will 1Password unlock the particular box.



The downside of this is that 1Password must keep the titles and the web locations unencrypted in your data. The good part of this strategy is that 1Password can still be used to match individual web pages and it does not have to keep all of your username and password information decrypted, which would be far worse from a security point of view. As we develop 1Password further, we are exploring ways to have it work with all data encrypted. We expect to have a new data format in which all data are encrypted prior to the release of 1Password 4.



The information which 1Password keeps decrypted in your data is very similar to what you may have in a browser bookmarks file. In addition to the location and title are tags, Folder, password strength, creation time, and last modify time. Any of the fields that can be used for sorting or arranging the display of your items in the 1Password app are not encrypted. Everything else is.



It is important to remember that even [i]that[/i] information is only available if someone captures your 1Password data file. That would mean either Dropbox becoming compromised if you are syncing via Dropbox, your own computer becoming compromised, or the SSL communication between your computer and Dropbox becoming compromised. The first and the last of those are the least likely. 1Password was designed with the knowledge that some users would have their computers stolen and we are always working to [url="http://blog.agilebits.com/2011/12/01/staying-ahead-with-security/"]stay ahead with security[/url] because [url="http://blog.agilebits.com/2011/04/23/looking-ahead-in-security/"]keeping 1Password secure is an ongoing process[/url].



Best regards,

jpgoldberg

Hi Green!



I don't really have anything much to add to what Khad has already pointed out, but I want to discuss your very astute observation:

[quote name='Green' timestamp='1325307424' post='56482']

The user interface with the open and closed 'vault' is misleading as it leads the end user to believe everything in the 'vault' is secure.[/quote]

Khad is right that a more accurate metaphor is the room full of locked boxes, with some information on the label for each box. We do document this for people who want to know more, but as you say, that isn't the model that is presented through the user interface.



This represents some of the most difficult security decisions we make in the design of 1Password. There are several places where what is really going on is different than what is presented in the UI. Another example is that your data items aren't encrypted with your master password, but instead they are encrypted with a randomly created 128-bit key that in turn is encrypted with your master password.



There are good security reasons for these designs, as Khad as pointed out and as is described in the deeper parts of our documentation. So the question we really face is whether to present the more complicated (but more accurate) details to users in the UI or whether to present the simpler (though less accurate model). I consider this a security decision.



What we have tried to do, where ever possible, is make the easy thing for users to do to also be the secure things for them to do. The rationale behind this is outlined in [url="http://blog.agilebits.com/2011/08/22/convenience-is-security/"]Convenience is Security[/url]. If users had to understand the more complex and indirect relationship between how their master password relates to the encrypted data before they could use 1Password effectively, I think that a lot of people would give up and end up less secure. I'm sure all of our customers are capable of understanding the subtleties, but that doesn't mean that they want a long lecture before they can make sense of how to use 1Password.



So we compromise. We present the simple model, but describe the details for those who go looking for them. Another advantage of this is that as we develop and modify what goes on under the hood, we don't have to change the user interface.



[quote]There is no notification once the vault is open as to what items are secure and what are not secure. When I open a website, I clearly can see what site is secure by looking at the https: and looking for the little lock sign or different highlighted URL bar to determine when I am on an ecrypted site.[/quote]

This again is a case where what goes on behind the scenes can vary and be very subtle. First of all, no decrypted data is ever written to disk. More generally (but vaguely because it does get tinkered with) decrypted data is held in memory for the shortest amount of time possible. That is, once something is decrypted, the decrypted data get's "forgotten" right after it is no longer in use.



The actual details of this involve many issues that again can vary. For example, when you sort your data by password strength, 1Password needs to temporarily decrypt each password to calculate its strength and then forget that password again. Also the way that memory management happens in the core app and happens in extensions are fundamentally different because they are written in very different programming languages. If the 1Password UI tried to wear this complexity on its sleeve it would be a nightmare of ever changing colored icons or whatever.



I hope that this helps you see at least why we made the security and design decisions that we did. As I said, I believe that the question of how things are presented to the user is a security decision. You may not have come to the same conclusion that we did, but I hope you realize that there are reasons behind our decision.



Cheers,



-j

Green

Thanks again for your thorough and timely responses. Frankly, what you are saying makes sense with the locked boxes but that isn't the user interface presented. This may be a difference of opinion but I think the vast majority of people would expect a virtual vault to work like a physical vault - that is, *all* the contents in the vault are secure. In fact, it is even what you advertise:



[url="https://agilebits.com/onepassword/iphone"]https://agilebits.co...password/iphone[/url]

[b]"Locks your data[/b] behind a four-digit unlock code and a master password, both of which you configure. Even if your mobile device is stolen or misplaced, your 1Password information is safe."

Note there is no asterix or 'for further information' beside this statement, the statements as a whole or on this page that clarifies this statement in more detail.



If you are going to user an interface such as a vault for convience, at least provide clear notification that it is not the same as a physical vault where only certain elements are safe and other are not. Your sales material also reinforces this concept of 'locking your data behind' [an unlock code - on a vault interface] further confusing customers into thinking all data behind this passcoded vault screen is safe.



I suppose the bottom line is that my [u]1Password information was not safe[/u] when my IPhone was stolen. I stored credit card information or other sensitive information in the title of the notes fields and now this is out in the open. If you expect end users to do more research on what is and is not encrypted then you should provide some very clear notification of that in the application - not everything dives through all the documentation in an application. You should also not mislead customers by saying that their '1Password information is safe' when not all 1Password information is safe.

jpgoldberg

[quote name='Green' timestamp='1325386004' post='56534']

I suppose the bottom line is that my [u]1Password information was not safe[/u] when my IPhone was stolen.

[/quote]

I didn't address this point, but if you had a passcode for your iPhone, then it would be very difficult for someone to even get at the unencrypted portions of your iPhone. That is, iOS encrypts (almost) everything with a strong "device key". So even if the phone is stolen and subject to a jailbreak, the data should be protected.



However, there are tools that can run through the 10000 possible (simple) unlock codes in less than an hour. The common thief is not likely to employ such tools.



The above is to let you know that you shouldn't be particularly worried, but it doesn't take away from your main point. You very reasonably thought that URLs and Titles were securely encrypted by 1Password. This was a reasonable assumption based on how we present things. And this is one of the several reasons why we are working on a new data format that will more closely follow the user model.



Cheers,



-j

Green

[quote name='jpgoldberg' timestamp='1325397786' post='56539']

I didn't address this point, but if you had a passcode for your iPhone, then it would be very difficult for someone to even get at the unencrypted portions of your iPhone. That is, iOS encrypts (almost) everything with a strong "device key". So even if the phone is stolen and subject to a jailbreak, the data should be protected.

[/quote]



Actually, even with a passcode, data protection, and 'wipe all after 10 failed attempts' enabled, it takes less than 30 seconds to get into the unencrypted iphone contents with terminal or [b]very common[/b] IPhone Explorer tools. Take this scenario to access the sqlite data for example:



1) Connect IPhone to computer and open up an IPhone Explorer program (Here's one that is free: [url="http://www.macupdate.com/app/mac/31722/iexplorer"]http://www.macupdate.com/app/mac/31722/iexplorer[/url])

2) Navigate to Apps > 1Password > Documents > 1password.sqlite

3) Copy file to desktop and open with text editor



You now have access to all my unencrypted 1Password data.



You're right that most thieves won't bother looking through the data and will just wipe the data and resell. But encryption isn't there to protect again the 99% of thieves who don't care about the data, it's there to provide peace of mind against the 1% who [b]will [/b]go through the data and use it for nafarious purposes such as stealing your money, identity and dignity.

Green

[quote name='jpgoldberg' timestamp='1325397786' post='56539']

And this is one of the several reasons why we are working on a new data format that will more closely follow the user model.

[/quote]



PS. I don't see this as a complicated solution such as changing your data format to more closely follow the user model, just change your misleading advertising so customers know right off the bat not all their 1Password information is safe (e.g., "for more information about what data is and is not protected..."). In addition, in the actual application, you could provide some notification so as to help security-conscious customers organize their information in a way that is safe.

WilDoane

To bump this topic and to suggest some circumstances where the subtly of what's encrypted and not could be an issue... consider a shared or compromised computer where usernames/passwords for any of the following (I think fictional) sites are present:



IRenounceMyGovernment.com

IThinkIMightBeGay.com

IBelieveAnUnpopularIdea.net

HowToOverthrowATotalitarianRegime.com

ImAnAttorneyForPoliticalDissidents.com

IWantADivorce.org

ProtectionForBatteredSpouses.org

ImAdoptedWhereAreMyBirthParents.org

IHaveASociallyUnacceptableSexualFetish.net

IThinkIMightBeAnAlcoholic.or.uk



If you are moving toward full encryption, then problem solved. But in the mean time, the ambiguity in encrypted/not encrypted for a user who thinks they're buying a security product seems inappropriate.



-Wil



p.s.: hello, NSA. <img src='http://forum.agilebits.com/public/style_emoticons/<#EMO_DIR#>/smile.png' class='bbc_emoticon' alt=':)' />



(no reply is necessary)

jpgoldberg

WiiDoane,



You are absolutely correct. And I fully agree. (And cute examples.)



When we came up with the current design back in 2008 we treated these as revealing no more information than browser bookmarks. Whether or not that was a good decision back then (and we had good technical reasons to have location and title unencrypted), it is not right today.



I wish I could promise a date for the new data format, but there are a lot of big changes we are working on.



Cheers,



-j