Unencrypted info in 1Password.agilekeychain

J-a-s-o-n

There seems to be quite a bit of information that is not encrypted. The password is encrypted but the url to every password is not. So if someone wanted to focus on a particular site's password this would make it much easier. Also, this takes some privacy away. Another thing that isn't encrypted is the password strength. Someone could tell if your password isn't complex and narrow the scope of a brute-force attack accordingly. These two things together make it even worse. As a security contentious person I would feel more comfortable if all aspects of my data file were encrypted. I am looking forward to the future support of being able to sync my iPhone and desktop using my own personal webdav server.

mr_twister

[quote name='J-a-s-o-n' timestamp='1284967599' post='11556']

There seems to be quite a bit of information that is not encrypted. The password is encrypted but the url to every password is not. So if someone wanted to focus on a particular site's password this would make it much easier. Also, this takes some privacy away. Another thing that isn't encrypted is the password strength. Someone could tell if your password isn't complex and narrow the scope of a brute-force attack accordingly. These two things together make it even worse. As a security contentious person I would feel more comfortable if all aspects of my data file were encrypted. I am looking forward to the future support of being able to sync my iPhone and desktop using my own personal webdav server.

[/quote]



J-a-s-o-n, thank you for a great post!



Quite a lot of confidential information is not encrypted by 1Password!



Huge loophole for confidentiality and security eventually!



Very important post. Thanks again!

[Deleted User]

[quote name='J-a-s-o-n' timestamp='1284967599' post='11556']

There seems to be quite a bit of information that is not encrypted.[/quote]

Yup, and that topic's been thoroughly discussed in other threads… if you can find them. <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/smile.gif' class='bbc_emoticon' alt=':)' />



[quote[]The password is encrypted but the url to every password is not.[/quote]

[url=http://forum.agile.ws/index.php?/topic/370-is-1password-affected-by-the-newly-discovered-iphone-vulnerability/page__p__2829#entry2829]By design[/url].

mr_twister

[quote name='sjk' timestamp='1285010158' post='11595']

Yup, and that topic's been thoroughly discussed in other threads… if you can find them. <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/smile.gif' class='bbc_emoticon' alt=':)' />





[url=http://forum.agile.ws/index.php?/topic/370-is-1password-affected-by-the-newly-discovered-iphone-vulnerability/page__p__2829#entry2829]By design[/url].

[/quote]



Such balance may be acceptable for internet forums like this, but not for financial information.



And titles & URLs is not the only information that is not encrypted.

khad

Indeed. It is by design and titles and URLs are the only things that are not encrypted. If someone get's their hands on your data file, they will be able to view the sites. Security through obscurity is not really what we are striving for with 1Password. Hence the need for the built-in Strong Password Generator. Someone can know all the URLs of logins but without the passwords it will be useless to them. A strong password can take hundreds of years (or longer) to brute force attack.



If you have not followed the link that sjk posted (via Gita's post), I suggest you give it a read.



[color="#0000FF"][size="4"][url="http://help.agile.ws/1Password3/agile_keychain_design.html"]Agile Keychain Design[/url][/size][/color]



If you have any further questions or concerns, please do let us know!

jpgoldberg

Hi everyone!



Thanks for participating in this discussion. There have been great discussions of this in the past on the forums, but as some of you have pointed out, these are difficult to find. (I've just done some hunting and couldn't find the one that I was looking for.)



When we first introduced the Agile Keychain format we posted links to a description of its design.



http://help.agile.ws/1Password3/agile_keychain_design.html



which discusses some of the design principles and what information is and isn't encrypted.



But now that we are more enthusiastically recommending that people store their 1Password data using Dropbox it is time to discuss all of these from a security and privacy perspective more fully. I'm in the process of writing up additional documents to discuss the security of cloud syncing and storage and will be including a section about what is and isn't encrypted.



Actually, the cloud syncing document is already available,



http://help.agile.ws/1Password_touch/how_secure_is_syncing.html



but the document(s) on cloud storage security are still being drafted.



If you could post your questions and concerns and what you would like to see in that document here, I will follow this discussion. I can't promise to address every single point but I and others will be following this discussion closely.



So please jump in.



Cheers,



-j

mr_twister

[quote name='khad' timestamp='1285014239' post='11612']

Indeed. It is by design and titles and URLs are the only things that are not encrypted. If someone get's their hands on your data file, they will be able to view the sites. Security through obscurity is not really what we are striving for with 1Password. Hence the need for the built-in Strong Password Generator. Someone can know all the URLs of logins but without the passwords it will be useless to them. A strong password can take hundreds of years (or longer) to brute force attack.



If you have not followed the link that sjk posted (via Gita's post), I suggest you give it a read.



[color="#0000FF"][size="4"][url="http://help.agile.ws/1Password3/agile_keychain_design.html"]Agile Keychain Design[/url][/size][/color]



If you have any further questions or concerns, please do let us know!

[/quote]



I just opened .password file with plain text editor.



I don't have all the fields filled with data but here what I see:



updatedAt - unencrypted;

locationKey - unencrypted (part of 'location');

passwordStrength - unencrypted;

title - unencrypted;

location - unencrypted;

createdAt - unencrypted.



To me this seems to be pretty much.



[b]In many cases knowing only the service name and login name may be compromising your confidentiality and security.[/b]



Password strength is not encrypted as well. This means that intruder may see that the password is not strong enough and actually successfully find my password with brute force, which he would not even try without knowing the service name, login and password strength. Not always one is free to create as strong passwords as he wants because of service limitations.



Besides creation and update dates and time together with other non-encrypted fields above may give powerful intruder additional information about how to crack you depending on the situation.



Because of this I personally would never use 1Password alone, I will always need another tool that would create encrypted volume to store agilekeychain. Unfortunately this will not help from disclosing of plain-text information to potential intruders when I transfer my agilekeychain form one computer to another or to my iPhone. All this does not sound good for me.



I understand that this discussion leads to nowhere: your team has already thought this through and made a decision. And I'm not a security professional to base my concerns well enough so that you change design. Maybe you cannot do that without losing wowness and marketability of your product. I wanted to use 1Password for security first of all.

So far I’m afraid that I will have to move further and search another tool that aims at security, security through obscurity.



Besides many security experts already advice to use 256bit encryption as quantum computing is not so far ahead and passwords I store in .agilechain file today may still be valid when the intruder has another level computing power to crack my keychain. This is how I understand it.



Would you please consider of optional encryption of all fields? You may make it an advanced option, maybe via command line and alert that some of functionality will be lost and disabled. But my data would be much more secure. Many people are ready to sacrifice browser extensions and fast decoding on mobile devices for true security. Keypasses have a lot of users not only because of open-source and free.

Penelope Pitstop

[quote name='mr_twister' timestamp='1285048321' post='11654']

I just opened .password file with plain text editor.



I don't have all the fields filled with data but here what I see:



updatedAt - unencrypted;

locationKey - unencrypted (part of 'location');

passwordStrength - unencrypted;

title - unencrypted;

location - unencrypted;

createdAt - unencrypted.



To me this seems to be pretty much.



[b]In many cases knowing only the service name and login name may be compromising your confidentiality and security.[/b]



Password strength is not encrypted as well. This means that intruder may see that the password is not strong enough and actually successfully find my password with brute force, which he would not even try without knowing the service name, login and password strength. Not always one is free to create as strong passwords as he wants because of service limitations.



Besides creation and update dates and time together with other non-encrypted fields above may give powerful intruder additional information about how to crack you depending on the situation.



Because of this I personally would never use 1Password alone, I will always need another tool that would create encrypted volume to store agilekeychain. Unfortunately this will not help from disclosing of plain-text information to potential intruders when I transfer my agilekeychain form one computer to another or to my iPhone. All this does not sound good for me.



I understand that this discussion leads to nowhere: your team has already thought this through and made a decision. And I'm not a security professional to base my concerns well enough so that you change design. Maybe you cannot do that without losing wowness and marketability of your product. I wanted to use 1Password for security first of all.

So far I’m afraid that I will have to move further and search another tool that aims at security, security through obscurity.



Besides many security experts already advice to use 256bit encryption as quantum computing is not so far ahead and passwords I store in .agilechain file today may still be valid when the intruder has another level computing power to crack my keychain. This is how I understand it.



Would you please consider of optional encryption of all fields? You may make it an advanced option, maybe via command line and alert that some of functionality will be lost and disabled. But my data would be much more secure. Many people are ready to sacrifice browser extensions and fast decoding on mobile devices for true security. Keypasses have a lot of users not only because of open-source and free.

[/quote]

mr_twister, I think you are doing the right thing by trying to understand exactly how 1PW works so that you can determine for yourself if it appropriately mitigates against risks you perceive. However I think that there is a danger that you could throw the baby out with the bath water by giving up on 1PW.



Why not use secure notes to store the login details for your important financial accounts and manually transcribe them when you need to? 1PW could never log me into my really important financial accounts anyway. They all ask for random bits of information from several strings of data and have multiple step logins deliberately designed to thwart automated login processes. Transaction authorisations also require a separate hardware based challenge/response authentication step. Secure notes are therefore ideal for me and I use the random password generator to help construct the passwords (deleting them afterwards). For obscurity, I use unrelated names for the titles of these secure notes. For all my other accounts, the automated use of separate, randomly generated passwords provided by 1PW is just perfect. I have only a few really important financial accounts and hundreds of others. This technique therefore provides the right balance for me.



The articles on syncing and 1PW security in iOS greatly reassured me over the loss of the phone.



Finally, you are right that security will always be a moving target and we have to use the best available tools to try and stay one step ahead. But it is and will always remain a trade-off between convenience and mitigation of risk. It's getting the balance right for you I suppose.



Finally, If you weren't happy with the secure note idea, you could also create a document in a secure filesystem completely outside of 1PW that contained what you needed to know for those really important accounts. Either way, you still retain the convenience of 1PW for the majority of your accounts and the security you desire for the remainder.

mr_twister

Here is how I've been storing all my password information for years:



+ Account information is stored in plain-text file.

+ Backups for database performed by me manually via file copy-paste.

+ Database is stored on an encrypted volume (similar to .dmg) created by Program #1.

+ Virtual memory is encrypted by Program #2.

+ Disk on which virtual memory and database is located is encrypted with whole-disk encryption Program #3.

+ When I need to transfer my database I transfer it via secured network or via physical media inside encrypted volume.



- Unfortunately my account information is not encrypted while stored in operating memory and not securely deleted from memory after not needed anymore. I'm trying to struggle with this deficiency by maintaining physical safeguards and not leaving my computer right after it was shut down in public places so it could fade out of the memory in minutes thus trying to mitigate possible cold boot hack by memory dump. I'm picky about software used as well.



Some of the measures may be excessive - but it works for me.



I wanted to try to switch to 1Password because of usability. If I have to store my information in notes it will not make it much different from the way I've been working so far.



I actually don't like the idea of storing and transferring titles, URLs, etc. in plain-text.



If I buy a special software for password keeping I expect it to do all this for me. Auto-filling web-forms is the thing I least care about.





Can somebody explain how worthy is the security/usability trade off is?



As I understand only notes/passwords are encrypted (add items please, if I'm missing something)?



How much longer will it take to decrypt an average database of 500 entries with all fields encrypted vs. passwords/notes fields encrypted only? In seconds and in percentage terms? On iPhone 2G, on MacBook Pro 13" 2008 and on a new MacBook Pro 15" with Intel Core i5 processor which supports hardware acceleration for AES with AES-ni instructions?



So we can understand if it is a really good trade off?





There are people trying to convince me that FileVault is just as secure as WDE. I don't buy it so far.



By the way, my WDE software uses AES-256 encryption and I don't suffer even on 5-year old computer because of lack of performance power. I think it will not be a problem for a small keychain file on any decent computer used nowadays. So basically the performance question only should be applied to iPhone.

jpgoldberg

Hi Mr Twister,



I'm going to reply to just two points (actually one) in this reply. So forgive me for skipping the rest at this time.



[quote name='mr_twister' timestamp='1285067382' post='11668']

- Unfortunately my account information [in my previous setup] is not encrypted while stored in operating memory and not securely deleted from memory after not needed anymore. [...]



How much longer will it take to decrypt an average database of 500 entries with all fields encrypted vs. passwords/notes fields encrypted only? [/quote]



The answer (of sorts) to both of these is actually the same. 1Password does not decrypt all of your items. The file based system that you describe would decrypt everything. But 1Password decrypts only the specific items it needs at the moment and removes it from memory as soon as it is no longer needed. When you select to use, say, your login for this forum, only then will the actual user name and password be decrypted.



When 1Password is "unlocked" what this really means is that 1Password has the ability to decrypt any particular item when needed. It does not mean that everything is actually decrypted. This way 1Password keeps your secrets encrypted nearly all the time even when "unlocked." This is a much better approach than simply decrypting an entire file once. Your secrets are not sitting around in memory and so won't get written out to swap or in crash dumps.



But to manage this 1Password needs to perform little decryptions frequently. These are most typically done in our libraries loaded into browser extensions. So efficiency plays a major role. If we were to merely decrypt once at start up than waiting an extra second or so once at start up wouldn't be an issue. But we need 1Password to be immediately responsive when matching and filling forms.



This also means that to be able to present any kind of usable index of items either to you or to the browser we need to keep that index sort of information unencrypted.



The best way to see what is and what isn't encrypted is to view your items Widescreen or Traditional View. (View > Layout). What appears in the actual list of items isn't encrypted. This is by design specifically so that 1Password can produce such a list (or match Logins to web pages in the browser) without having to keep all of your data decrypted.



[attachment=249:what_s encrypted.jpg]



I hope that this gives you some insight into why things are the way they are.



Cheers,



-j

mr_twister

Jeffrey, thanks a lot for your reply. It actually throws light.



First of all I should accept that I initially wrongly considered that my logins were not encrypted as well. I was confused because I included my login names into the title of the entries and was not enough attentive during my quick examination of .password files (I usually do not do this and forgotten about this peculiarity of my test database).



So (please correct me if I'm wrong) both login name and password are encrypted? As long as entry title, URL location, change dates and password strength are not?



Actually the fact that both login and password are encrypted makes me feel better about 1Password. I will try to work around how I can hide sensitive information in encrypted part of the file. I will also try to inspect other sections and see what information is left unencypted there (if any).

khad

How I love these kinds of discussions! Thank you all for this. <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/skype_smile.png' class='bbc_emoticon' alt=':-)' />



mr_twister, after reading your description and seeing Jeff's response it sounds like 1Password will be at least as secure as your current set up if not more so. There is the option (which is disabled by default I believe) to include usernames in login titles, but I do not use it myself.



Usernames and passwords are both stored encrypted, yes. I like the way Jeff put it: Everything for which you can add a column in Traditional view (View > Layout > Traditional) is stored unencrypted. (You can view the full list of columns via the View > Columns menu.)



Please let us know if you have any further questions or concerns. I never want to come across as a know-it-all, but the keychain design has been very thoroughly thought out. I was a user myself before joining the company and am very impressed with it. It allows the flexibility to use the application in many different ways. Penelope Pitstop gives a great overview of one method. (I think I may steal some of those ideas for myself.) <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/skype_bigsmile.png' class='bbc_emoticon' alt=':-D' />

jpgoldberg

[quote name='mr_twister' timestamp='1285087480' post='11700']

Jeffrey, thanks a lot for your reply. It actually throws light.[/quote]



You are very welcome. Khad has already followed up, but I'll just confirm things and add a few details.



[quote]

First of all I should accept that I initially wrongly considered that my logins were not encrypted as well. I was confused because I included my login names into the title of the entries and was not enough attentive during my quick examination of .password files (I usually do not do this and forgotten about this peculiarity of my test database).[/quote]



Ah. I understand the confusion. This is why the default in 1Password 3 is to [i]not[/i] "Automatically include usernames in Logins" which can be set in [i]1Password > Preferences > Logins[/i].



Some people (me included) are fine with having many of their usernames in the Titles. After all, the vast majority of them are either jpgoldberg or my email address, both of which are fairly public. But there are a couple of sites where my username is more cryptic, and for those I do not include them in the Titles.



Still, we believe in "secure by default", so 1Password defaults to not putting usernames into the Login titles.



[quote]

So (please correct me if I'm wrong) both login name and password are encrypted? As long as entry title, URL location, change dates and password strength are not?[/quote]



Precisely! That is it. By the way, I think that it is great that people are looking under the hood at the actual format.



[quote]

Actually the fact that both login and password are encrypted makes me feel better about 1Password.[/quote]



I'm glad to hear that. Sorry for the fright. I hadn't realized that you thought that usernames were unencrypted.



[quote]I will try to work around how I can hide sensitive information in encrypted part of the file. I will also try to inspect other sections and see what information is left unencypted there (if any).

[/quote]



The titles, the type (what kind of item it is), the file create and modify times and whether the item has attachments are unencrypted. Of course, the attachment itself is fully encrypted.



Cheers,



-j

brenty

I love this thread! Pure gold! Thanks to jason and twister for getting the ball rolling.



[quote name='jpgoldberg' timestamp='1285081363' post='11691']

This also means that to be able to present any kind of usable index of items either to you or to the browser we need to keep that index sort of information unencrypted.[/quote]



This was exactly what I was thinking. It wasn't immediately clear to me from this short statement, but, in case anyone else missed it, what he is saying is that if things like web site URLs were encrypted, there wouldn't be any meaningful way to select the login you're trying to use! Whether from within a browser plugin or in 1Password itself, you would just sort of have to click on blank entries in a list and enter your password to unencrypt it to find out if it was the one you were trying to access.



Having any of this data available in the clear is absolutely a privacy concern, but it seems necessary from a usability standpoint; quite literally, without having some frame of reference for what you are selecting, it is [i]un[/i]usable. Perhaps Penelope's suggestion of storing information in secure notes would be best for instances in which absolute privacy is warranted. It's inconvenient to have to manually unlock, copy, and paste each field (especially after 1Password goes to such lengths to spoil us with autofill and autologin), but the most sensitive data calls for the utmost care; and convenience is sometimes a sacrifice that must be made.



Fortunately, in most cases having my username and password stored securely is more than enough. Since most sites lock the account after several failed attempts, brute force attacks are infeasible.



Additionally, using Dropbox in tandem with 1Password is a nice solution because, in addition to effectively having offsite backup and access to your data virtually anywhere, it's also encrypted.

khad

[quote name='brenty (toromei)' timestamp='1285273316' post='11902']This was exactly what I was thinking. It wasn't immediately clear to me from this short statement, but, in case anyone else missed it, what he is saying is that if things like web site URLs were encrypted, there wouldn't be any meaningful way to select the login you're trying to use! Whether from within a browser plugin or in 1Password itself, you would just sort of have to click on blank entries in a list and enter your password to unencrypt it to find out if it was the one you were trying to access.[/quote]



Precisely.



Unless — as is the case with merely storing all your data in a text file in a Knox vault — we unencrypted your entire keychain when it was unlocked. I just want to hammer home the point that only the data that needs to be used at any given moment is actually unencrypted: individual logins, card numbers, etc. The entirety of your data is never fully decrypted at once. Another great benefit!

JoDavid

Hello,



First let me say this: " I just love 1Password " <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/biggrin.gif' class='bbc_emoticon' alt=':D' />

And I started with the beta updates <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/smile.gif' class='bbc_emoticon' alt=':)' />



But I'm a bit concerned about the urls not beeing encrypted inside of the keychain file.

So maybe someone hacks into your computer, dropbox, iphone etc... he/she is able see for wich sites you store passwords.



Not so good imho.



Any plans on changing this?



Greetings from Germany,

Jonathan



PS: Is Dropbox realy trustworthy (to store your uttermost important data)?

(If I use bad english it's just for your amusement)

khad

Hi JoDavid,



Welcome to the forums! I merged your post with the appropriate thread. Please let me know if you have any further questions or concerns that are not already addressed above. Thanks! <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/skype_smile.png' class='bbc_emoticon' alt=':-)' />

macdonut

[quote name='JoDavid' timestamp='1286610547' post='12940']

PS: Is Dropbox realy trustworthy (to store your uttermost important data)?

(If I use bad english it's just for your amusement)

[/quote]

Never trust a cloud service, use local encryption instead (and hope your system is clean otherwise) – that's why bascially don't have to care about Dropbox security if you use 1Password.



Martin

khad

Very good point, Martin. I think that is what makes me uneasy about some other cloud-based password managers. Sure, they might encrypt the data before sending it (and even, like Dropbox, encrypt the transmission channel), but I personally would rather not have the company that is in charge of encrypting my data also store it. They "know too much" for me to be at ease. I love the way 1Password stores and encrypts everything locally itself and then transmits it, fully-encrypted, to Dropbox snuggled safely inside SSL.



It's like we are saying, "Here you go, Dropbox. Have some random chunks of encrypted data. Just store them safely for me." Rather than a cloud-based password manager saying to us, "I'll take that sensitive data that I just encrypted and store it safely for you. Don't worry, even though I encrypted it and know all about it, it's safe with me." (Of course, in my head, I also hear a maniacal cackle at the end of that sentence, but I'm trying to be more diplomatic. <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/skype_bigsmile.png' class='bbc_emoticon' alt=':-D' />

Paranoid

Hi all, I just joined because of this topic. I really like 1 Password, but:

I also recently discovered, exactly the above, that not all information is encrypted inside the 1Password keychain.



Sorry, but I also do not like that kind of design. For me, 1Password 3 is not secure with a keychain design like it is today.



Yes, this might be by design but to say that something is by design, doesn't make it right automatically.

Also it is good that the keychain design was well thought out, but that doesn't mean that it's perfect.



The problem that I have is not only security but also PRIVACY. Privacy is at least as important as security.

No one needs to know anything about my data.

I bought 1 Password because of security AND privacy.

I wanted an elegant solution that is SECURE. Not encrypting all data means that 1Password is not secure.



If 1Password's keychain doesn't encrypt ALL information, for me, this is a major fault in it's design.



I really would like to sync with dropbox - I love the idea. But with a keychain design like it is today, this is anything else than secure.

Wifi sync works, but only to the iPhone and back. But my MacBook does not sync that easy. And what about recently changed entries that I didn't sync and I am already on the road?



The conclusion of all this if, that the somehow still a little bit faulty keychain design needs more security, which also means privacy.

Everything in the keychain SHALL be encrypted if there is such functionality to sync to the cloud.

khad

Hey Paranoid (I like your username),



Welcome to the forums!



Please take a look at [url="https://www.dropbox.com/help/27"]Dropbox's own security documentation[/url] and consider that, "Your files are actually safer while stored in your Dropbox than on your computer in some cases. [They] use the same secure methods as banks and the military to send and store your data."



Additionally, "Dropbox employees aren't able to access user files, and when troubleshooting an account they only have access to file metadata (filenames, file sizes, etc., not the file contents)."



You are certainly free to make your own decisions regarding your own level of comfort with the security/privacy and convenience tradeoffs, but I trust my data to Dropbox.



Please let me know if you any specific questions about the 1Password data file and Dropbox syncing. Thanks! <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/skype_smile.png' class='bbc_emoticon' alt=':-)' />

khad

Also, it occurs to me that our document on [url="http://help.agile.ws/1Password_touch/how_secure_is_syncing.html"]Secure Syncing[/url] was written after this topic was started, so a link has not yet been included to it in this thread. It may contain further information that you might find helpful.

Paranoid

What makes you so confident about what Dropbox writes? If you trust them that much, why do you even encrypt your passwords? Would you give them a plaintext file with all data that is stored inside 1 Password today? If you will answer this question with yes, than there is no need to increase the security of the 1Password keychain. If you answer no, you deeply need to think about to enhance the security of the 1PW keychain.



To do just a little brainstorming this can be done for example to use a second password that will be stored inside the OS and iOS keychain just to decrypt the now unencrypted parts. Using the same strength as for all other already now encrypted data, this should not be a very big performance decrease because only small chunks of data need to be decrypted to show a list of all items.



Anyway, what I hardly miss is a sync function inside the 1Password Mac desktop application itself (or did I overlook it?). For example I can sync from and to my iPhone. But what I can not do is to sync between my desktop and my notebook only by using 1Password. It would be great to see such functionality in 1Password 3.4.5, because the code is already there in the iPhone app. It just needs to be ported to the Mac desktop application. Please do not point my to 3rd party sync solutions because it already works between the Mac desktop app and the iPhone.

[Deleted User]

[quote name='Paranoid' timestamp='1287405481' post='13505']

What makes you so confident about what Dropbox writes? If you trust them that much, why do you even encrypt your passwords? Would you give them a plaintext file with all data that is stored inside 1 Password today? If you will answer this question with yes, than there is no need to increase the security of the 1Password keychain. If you answer no, you deeply need to think about to enhance the security of the 1PW keychain.[/quote]



No, I wouldn't store my 1Password data in plain-text within Dropbox, but that's not related to the security of the Dropbox service itself. With Dropbox your data is always stored on your local machine and then synced to the Dropbox service, which is why it works so well and is far more reliable than some other sync solutions, so while I'd be confident that no-one could get to my Dropbox data from the web, there's still the issue of physical access to the 1Password data file on the local machine.



So, although some limited information is left unencrypted the most important information, such as your usernames, passwords, card numbers etc, is encrypted. If someone where to get hold your system they wouldn't need to look in your 1Password data file to find the sites you'd been visiting, they'd just look at your browser history or your cache.



Now, I'm not a security expert, and my colleague Jeff can do a much better job of explaining some of the security nitty gritty here, but as a 1Password user of several years before I joined the team, I've always felt very confident with syncing my 1Password data with Dropbox and about what information is exposed. I really don't want to pay the price of having to constantly enter my master password every single time I want to list, view or fill a login saved within 1Password, and I'm sure after any period of time with that approach no-one would.



[quote]Anyway, what I hardly miss is a sync function inside the 1Password Mac desktop application itself (or did I overlook it?). For example I can sync from and to my iPhone. But what I can not do is to sync between my desktop and my notebook only by using 1Password. It would be great to see such functionality in 1Password 3.4.5, because the code is already there in the iPhone app. It just needs to be ported to the Mac desktop application. Please do not point my to 3rd party sync solutions because it already works between the Mac desktop app and the iPhone.[/quote]



The syncing solution we use between 1Password for Mac and our iOS applications used Apple's Bonjour technology and requires that both devices be on the same network and thatboth be constantly open and unlocked for the sync to take place.



That really wouldn't be practical between multiple Macs, so we had a few choices, create our own sync solution which would take a lot of time and money to build a secure and reliable infrastructure for, or to look to an existing 3rd party sync solution, in this case we chose Dropbox because of our own experiences with their service. We're not planning on stopping at Dropbox, it's just our the first solution we've been able to implement, and we have plans for both MobileMe and WebDAV syncing in the future, once we can ensure the sync would be reliable and secure.



WebDAV would be a great option for a lot of users, because you can install a WebDAV server on your own hardware and completely isolate the sync process from the wider internet, if you wanted to. Also, there are many other options already available for syncing your 1Password data between two Macs, and I believe some users even use SVN or rsync without issues, and we've created a guide on some of these alternative solutions here:



http://help.agile.ws/1Password3/sync_solutions.html



Hope that helps,

jpgoldberg

Hi, Paranoid. You ask some great questions (and living up to your name)!



[quote name='Paranoid' timestamp='1287405481' post='13505']

What makes you so confident about what Dropbox writes?

[/quote]



We can never be certain that their (or anybody's) security is flawless or that there wouldn't be some sort of insider attack. On the whole, we trust them because we have worked with them and they have always been happy to discussion security issues without anything that looks evasive.



But why you should trust them is different than why we do. There are several companies in the cloud storage business, but Dropbox is one of the few whose existence as a company depends on them being trusted with our data. (On a similar note, I personally prefer to use an email provider from a company whose survival depends on how well they provide email services.)



[quote]

If you trust them that much, why do you even encrypt your passwords?

[/quote]



The simple answer is what is called "defense in depth". We use multiple layers. But there is a fuller answer that requires some background.



When we first designed our data format, we anticipated that some people would have their computers stolen or that in some other ways "bad guys" would gain access to what is on your disks. That, for the most part, is why 1Password never writes decrypted data to your disk. (Although, as the title of this thread indicates there is some data that never gets decrypted/encrypted that is stored in your 1Password data.)



People may have different views about the relative risks a Dropbox breach. My feeling (I have no numbers to back this up) is that the risk of your computer being stolen or compromised is much higher than the risk of a Dropbox breach. So all of the protections which we put into place to protect you if your computer gets stolen apply equally well to a Dropbox security breach.



Even if we didn't have to worry about the contents of your own hard disk getting stolen, we would encrypt the information on Dropbox to provide defense in depth. But probably the single biggest reason that we encrypt the data is because of concerns about the contents of your home computer disk becoming available to bad guys.



[quote]

If you answer no [you wouldn't give Dropbox your unencrypted data], you deeply need to think about to enhance the security of the 1PW keychain.[/quote]



As Stu said very nicely in his post, the design of the Agile keychain was made with full knowledge that some would fall into the hands of bad guys. Adding Dropbox into the mix doesn't really change that.



[quote]

To do just a little brainstorming this can be done for example to use a second password that will be stored inside the OS and iOS keychain just to decrypt the now unencrypted parts. Using the same strength as for all other already now encrypted data, this should not be a very big performance decrease because only small chunks of data need to be decrypted to show a list of all items.[/quote]



This is actually close to how things work on iOS. But in iOS your 1Password data is stored in a sqlite3 database. You need to use your unlock code even to get to it. But because of the file and folder based syncing, on Mac and PC (and thus on Dropbox) each item is stored in its own file. Opening each file to perform a decryption of some of it would be prohibitive.



This goes back to something mentioned earlier in this discussion. When most people think about how stuff like this works, they imagine that the whole file gets decrypted when you enter your master password. We could do things that way, but it would be [i]worse[/i] for security. There would be some much secret data decrypted at any given moment, 1Password couldn't avoid having some of that written to disk. As things stand now, 1Password only decrypts the smallest amount of information it needs at a particular moment.



Let me quote from the draft of a document I am working on to help clarify this:



[quote]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 are 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 only decrypting the particular item you need at any given time 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 http://www.example.com/Login.php, 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 an 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.



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 that information is only available if someone captures your 1Password data file. That would mean either Dropbox becoming compromised, 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. As we said at the beginning of this article, 1Password was designed with the knowledge that some users would have their computers stolen. We do not believe that syncing to the cloud via Dropbox diminishes the security of your data in any meaningful way.[/quote]



I'm not saying that we are rejecting the approach you mention completely. We always keep an open mind with respect to how we can improve security. But everything we have done we have done for a reason. And what you suggest is something that we thought through at the time.





[quote]

Anyway, what I hardly miss is a sync function inside the 1Password Mac desktop application itself (or did I overlook it?). For example I can sync from and to my iPhone. But what I can not do is to sync between my desktop and my notebook only by using 1Password. It would be great to see such functionality in 1Password 3.4.5, because the code is already there in the iPhone app. It just needs to be ported to the Mac desktop application. Please do not point my to 3rd party sync solutions because it already works between the Mac desktop app and the iPhone.

[/quote]



This is an interesting idea, but I doubt we will be looking at expanding wifi sync.



Keep in mind that you can sync your data on a peer to peer basis using file and folder syncing tools such as rsync, Unison, and the like. We have even heard reports from a user who has done this with Subversion. However, setting up those sync solutions and in particular the networking issues that go along with them is not something we can offer support for.



But please do look at file and folder syncing tools on your local network. The 1Password data format is designed to work well with file and folder syncing tools in general (though it is best to have something that can maintain OS X metadata).



Overall, particularly if people are syncing beyond their local networks, they would be far more likely to introduce security problems by rolling their own than they would have by relying on Dropbox.



Please keep the questions coming. I think it is great that people are thinking about implications of their (and our) security decisions. This is the kind of discussion that should exist around every security product.



Cheers,



-j

brenty

[quote name='jpgoldberg']

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.

[/quote]



I have a profound appreciation for the way 1Password handles the decryption of my personal data, but I believe that it would be infinitely beneficial from usability and customer service standpoint to implement some user interface changes to better reflect the way 1Password actually operates.



Perhaps a better metaphor than "Unlock" would be to "Authenticate," with visual cues to indicate that, while you have verified your ability to access the data, it is only unencrypted when you actually access a particular item. Maybe there could be padlocks next to each item, which opened as they were accessed and then closed again in the interval after they are used. I was impressed with 1Password before I knew this was how it actually functioned, but now that I am aware of this, it seems to me a shame that this key functionality isn't apparent in the UI!



While I'm sure someone else could come up with a more refined way to reflect the inner workings of 1Password with graphical interface elements, I think it's definitely something that needs to be addressed. <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/smile.gif' class='bbc_emoticon' alt=':)' />





[quote name='Paranoid']

What makes you so confident about what Dropbox writes? If you trust them that much, why do you even encrypt your passwords?

[/quote]



I don't know offhand how Dropbox implements its own encryption, and frankly I don't care.



If security is a concern at all, being in control of our data demands that we use our [i]own[/i] encryption. If we rely on a 3rd party to encrypt our data, even if they have our utmost confidence, they have access to the decryption key, and they could at some point be bought out by a less scrupulous company, fall prey to hackers or an inside job, or be compelled by a government subpoena to hand it over.



[quote]

The problem that I have is not only security but also PRIVACY. Privacy is at least as important as security.

No one needs to know anything about my data.

I bought 1 Password because of security AND privacy.

I wanted an elegant solution that is SECURE. Not encrypting all data means that 1Password is not secure.

[/quote]



You make a lot of good points, Paranoid, but I feel like you're characterizing security and privacy as a binary proposition: either something is secure/private, or it's not. I don't think that's quite accurate.



Just as technological advances render [url="http://en.wikipedia.org/wiki/40-bit_encryption"]older encryption schemes[/url] obsolete through sheer speed of bruteforce attacks, making the decryption of [url="http://en.wikipedia.org/wiki/Data_Encryption_Standard"]previously out of reach[/url] cyphers feasible, stronger encryption using more processing power than was available to the average user a few short years ago also helps us as we try to stay one step ahead of malicious hackers. And I think that secure [i]practices[/i] are at least as important. I guess what I mean is that security and privacy are each on a continuum, and the best we can do is take steps to be more secure and to protect our privacy.



That said, I think it would be a nice feature if 1Password supported more granular user control over what is and isn't encrypted, but I think that categorically stating that "1Password is not secure" because my CapitalOne credit card -- not the card number -- is listed by name and not encrypted would be both inaccurate and unfair.



In the end, you have to decide for yourself what software/service is right for you, but it seems like a shame to write off such a versatile app completely when there are plenty of use cases where its strengths (convenience and, yes, security -- both in good measure) could benefit you, even if you'd prefer to keep your most critical data elsewhere.



[quote name='mr_twister']

Not always one is free to create as strong passwords as he wants because of service limitations.

[/quote]



Absolutely! I wish this wasn't the case, but many of the sites that don't allow long passwords with special characters or aren't case-sensitive happen to be the ones that have all these silly "secret questions" and such that are generally things that anyone could easily find out about me (mother's maiden name, high school, etc.) -- as if [i]that[/i] were a viable alternative to strong passwords! I tend to just make up fake answers and store them securely, but that doesn't make it any easier for 1Password to log me in to those sites, unfortunately. I think this is as much "[url="http://www.amazon.com/Beyond-Fear-Thinking-Sensibly-Uncertain/dp/0387026207"]Security Theater[/url]" as a trip to the airport has become these days. Sadly, they're just hoops to jump through.



[quote]

If I buy a special software for password keeping I expect it to do all this for me. Auto-filling web-forms is the thing I least care about.

[/quote]



The automation features are what I use most. For me, being able to store everything else securely is just icing on the cake; it's great to have that capability, but it's not what gets me through the day.



[quote]

Can somebody explain how worthy is the security/usability trade off is?

[/quote]



Absolutely not! <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/wink.gif' class='bbc_emoticon' alt=';)' />



It's your data, and, ultimately, you are the only person who can say one way or the other. We can discuss the pros and cons of one use case or another, and that's what this forum is all about. It's all a matter of what's important to you and what tradeoffs you are or aren't willing to make. I don't think of it as "should I use [i]Software X[/i] or [i]Software Y[/i]," because I may very well have a use for both, just for different purposes. For example, I have some account data I store in Knox as opposed to 1Password. I don't need frequent, convenient access to it, and as a result I can store it using stronger encryption in a separate location. What solution works best for you? <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/smile.gif' class='bbc_emoticon' alt=':)' />







[quote name='Penelope Pitstop']

But it is and will always remain a trade-off between convenience and mitigation of risk.

[/quote]



Amen, sister! <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/biggrin.gif' class='bbc_emoticon' alt=':D' />

Lzsolt

Is it (or would it be) possible to use AES 256 (or higher) instead of 128 in 1password? I mean I now AES 128 is "unbreakable" today, but that's what they thought us about the DES few years ago...

[Deleted User]

[quote name='Lzsolt' timestamp='1289041675' post='14634']

Is it (or would it be) possible to use AES 256 (or higher) instead of 128 in 1password? I mean I now AES 128 is "unbreakable" today, but that's what they thought us about the DES few years ago...

[/quote]



Hi Lzsolt,



Thanks for the question, we actually talk about why we intentionally chose to use 128-bit encryption over 256-bit in our[url="http://help.agile.ws/1Password3/agile_keychain_design.html"]'Agile Keychain Design' document[/url] and I'll quote the relevant section here in case you don't fancy reading the whole thing:



[quote]

The Agile Keychain uses 128-bit keys instead of 256-bit keys because they are long enough to be very secure and short enough to allow devices like the iPhone and web browsers to quickly decrypt their contents. The extra computation required for 256-bit encryption was simply not justifiable given the astronomical nature of a 128-bit key. According to the National Institute of Standards and Technology:



"What is the chance that someone could use the “DES Cracker”-like hardware to crack an AES key?

In the late 1990s, specialized “DES Cracker” machines were built that could recover a DES key after a few hours. In other words, by trying possible key values, the hardware could determine which key was used to encrypt a message.



Assuming that one could build a machine that could recover a DES key in a second (i.e., try 255 keys per second), it would take that machine approximately 149 thousand billion (149 trillion) years to crack a 128-bit AES key. To put that into perspective, the universe is believed to be fewer than 15 billion years old."



We felt that adding an extra 128 bits, i.e., multiplying 149 trillion years by an extra 3.4 x 1038, was not worth the performance cost that would be incurred. At 128 bits, it is much more likely that an attacker would focus on finding a weakness in the underlying system than attempt a brute force attack on a 128-bit key.



Additionally, the operating system on the iPhone, iPod touch, and iPad provides a standard, hardware-accelerated implementation of AES-128. With security algorithms and protocols, it is always better to rely on well-tested and reviewed implementations than to develop one’s own.[/quote]



Now, we may revisit this in the future, but for now we're sticking with 128-bit AES encryption for your 1Password data.



Hope that explanation helps.

brenty

[quote name='stu' timestamp='1289062633' post='14649']

Now, we may revisit this in the future, but for now we're sticking with 128-bit AES encryption for your 1Password data.

[/quote]



Definitely an understandable concern. However, I think an important thing to take into consideration is that 1Password is still very much in active development. If at some point in the future it becomes technologically feasible to brute force 128bit cyphers in a timely manner (or at such a time as mobile devices are sufficiently powerful,) they could simply update 1Password and give everyone the option to convert their keychains to stronger encryption. If, at this time, 1Password is no longer being supported, we will all be using something else that works with current operating systems anyway. <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/smile.gif' class='bbc_emoticon' alt=':)' />

jpgoldberg

[quote name='brenty (toromei)' timestamp='1289886713' post='15225']

Definitely an understandable concern [about 128 vs 256 bit AES]. However, I think an important thing to take into consideration is that 1Password is still very much in active development. If at some point in the future it becomes technologically feasible to brute force 128bit cyphers in a timely manner (or at such a time as mobile devices are sufficiently powerful,) they could simply update 1Password and give everyone the option to convert their keychains to stronger encryption.

[/quote]



You are exactly correct. We certainly are paying attention to what is out there, and will make adjustments as needed. We call ourselves "Agile" for a reason. But here is a bit of news that we don't have to adjust for.



http://stacksmashing.net/2010/11/15/cracking-in-the-cloud-amazons-new-ec2-gpu-instances/



Basically traditional password cracking (having a computer try millions of them per second) is getting cheaper all of the time. However, your 1Password master password is protected against this kind of attack by the password strengthening scheme PBKDF2. http://en.wikipedia.org/wiki/PBKDF2



But let me review why we continue to be happy with 128-bit encryption.



[list=1]

[*] The threat from an attack on 128-bit AES is truly negligible. So moving from 128 bit to 256-bit would be moving from negligible to negligible.

[list=a]

[*] Attacking 128-bit AES would already take all of the computers on the planet many times the age of the universe to crack.

[*] If someone was willing and able to dedicate millions of trillions of dollars to getting at your passwords, they could find more efficient ways of doing it. (See http://xkcd.com/538/ for example)

[*] The AES-128 encryption is probably the strongest part of the system. An attacker would look for something else other than trying to attack at the strongest point.

[/list]

[*] There are real life advantages to using 128-bit AES that we see every day.

[list=a]

[*] Unlike other systems, 1Password does not just do a one time decryption of all of your data. It decrypts only what is needed at any given moment (and then forgets about them.) Thus, there are lots of AES decryptions going on. Thus the efficiency of the decryption plays a greater role.

[*] iOS performs 128-bit AES in hardware. This makes an enormous difference, particularly when combined with the point above. Although our data format on iOS differs from our data format on Mac and PC, your iOS devices still needs to encrypt and decrypt data from your Mac and PC when doing Dropbox syncing.

[/list]

[*] At this point, the only advantage of 256-bit encryption that we can see would be in marketing.

[/list]



But things may change. Once everyone is on a 64 bit architecture, we may find that the advantages of staying with 128-bit encryption is less than the marketing advantages of moving to 256. If something is discovered about AES that effectively weakens it then moving to AES-256 may be a good idea (though probably moving to an entirely different algorithm might make more sense).



So I hope that this makes some sense of why we currently are sticking with 128-bit AES.



Cheers,



-j

padrone

Hi,



it is also possilbe to encrypt username and url (Location) in my .1password files (Data Folder)?

If not, it is possible to build this feature into 1Password?



Greetings Finn