Unencrypted info in 1Password.agilekeychain

khad

Welcome to the forums, Finn! I have merged your post with the appropriate thread. Please see above for some additional background.



There was some discussion elsewhere regarding this topic, and, while we do not have a time frame for a specific release, [url="http://getsatisfaction.com/agilewebsolutions/topics/1password_provides_only_partial_encryption#reply_4568764"]a fully encrypted data file is definitely on our radar[/url] for the future. It will take a lot of testing and recoding across all platforms since they all need to sync together, but we are pretty excited about this.



Please let me know if there is anything else I can help with. <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/skype_smile.png' class='bbc_emoticon' alt=':-)' />



Cheers!

EJ Griffin

[quote name='khad' timestamp='1297385996' post='20386']

Welcome to the forums, Finn! I have merged your post with the appropriate thread. Please see above for some additional background.



There was some discussion elsewhere regarding this topic, and, while we do not have a time frame for a specific release, [url="http://getsatisfaction.com/agilewebsolutions/topics/1password_provides_only_partial_encryption#reply_4568764"]a fully encrypted data file is definitely on our radar[/url] for the future. It will take a lot of testing and recoding across all platforms since they all need to sync together, but we are pretty excited about this.



Please let me know if there is anything else I can help with. <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/skype_smile.png' class='bbc_emoticon' alt=':-)' />



Cheers!

[/quote]



Hi, Can you clarify if the Notes section of a Login account is encrypted? I use this section to store information such as bank account numbers, etc. and I want to be sure it is encrypted. thanks.

khad

[quote]Hi, Can you clarify if the Notes section of a Login account is encrypted? I use this section to store information such as bank account numbers, etc. and I want to be sure it is encrypted. thanks.[/quote]

Absolutely! The titles are not, but all their contents are always encrypted.



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.



That being said, we are still hard at work updating the data format to encrypt every last bit of information! Thanks for asking about this.

BlackMacX

Hi,



Here is the issue I have recently become aware of and the threat as I see it (as well as the possible sync issue across multiple devices)



1. how to have a centralized, cloud based Password Manager application that is:



a. AES 256 encrypted

b. accessible only to the authorized clients (computer and mobile device)

c. non-readable by either the Cloud provider or others

d. encrypted in transit and on end-point with a TNO setup



2. must be mainstream, convenient and cross platform



I know that sounds odd; but in light of the recent [url="http://www.businessinsider.com/dropbox-updates-security-terms-of-service-to-say-it-can-decrpyt-files-if-the-government-asks-it-to-2011-4"]Dropbox issue[/url], how is one to have these, and not have the issues that [url="http://the.taoofmac.com/space/blog/2011/04/28/2233"]Tao of Mac[/url] notes with 1Password. I have found this to be disturbing at the very least. I know convenience comes at a cost and the issue with Dropbox is that I can sync only with one device (easily) if I setup an encrypted diskimage; I can't then sync my iPhone's 1Password with Dropbox as well (as it can't see inside the diskimage).



Therefore, is it possible to do the following:



1. as noted on Tao of Mac, the following Terminal commands open up files/information that potentially leak information that could allow others to guess at or at least have insight into what sites you have accounts with (ergo, your bank):



cat ~/Dropbox/1Password.agilekeychain/data/default/contents.js

grep http ~/Dropbox/1Password.agilekeychain/data/default/*



So, is there a way:



a. to delete the contents.js file immediately after a user uses the 1PasswordAnywhere page

b. that the results of the grep are also removed



I know this is long-winded, so sorry about that. I am just concerned about the strength of both 1Password's design and the integration with Dropbox (that seems to now be less secure then it formerly was).



Cheers,



BlackMacX

khad

Thanks for asking about this, BlackMacX.



[quote]a. to delete the contents.js file immediately after a user uses the 1PasswordAnywhere page

b. that the results of the grep are also removed[/quote]

The short answer is "not yet."



We are hard at work on a new data format with fully encrypted contents, but until that is available, you will always be able to search the unencrypted information in your data file with grep just like 1Password does and you can do manually by opening a .1password file in a text editor.



We have had some great discussions about our current data format over time (as you can see above). The current [url="http://help.agilebits.com/1Password3/agile_keychain_design.html"]Agile Keychain Design[/url] 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.



That being said, we are still hard at work updating the data format to encrypt every last bit of information. When we introduced Dropbox syncing 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.



[url="http://www.schneier.com/crypto-gram-0005.html"]Security is a process, not a product.[/url] We are proud of where we are today regarding the security of storing 1Password data in the cloud, but we wouldn't be true to our name or acting in your best interests if we simply rested on our laurels. [img]http://forum.agile.ws/public/style_emoticons/default/skype_wink.png[/img]



We are excited about the future of 1Password, and we think you will be too. If we can be of further assistance, please let us know.



We are always here to help!

BlackMacX

To possibly answer my own concerns and posit a possible solution, I wonder if the following solution might work:



1. create a encrypted container within Dropbox

2. move my 1Password.agilekeychain file therein

3. create a symbolic link to the 1Password.agilekeychain file

4. move the symbolic link to the previous location within Dropbox and remove the symbolic link component of the name (so that it now appears as 1Password.agilekeychain)

5. only update your iPhone/mobile device's 1Password contents with at home; but via Dropbox. Then have the encrypted container close when you've finished.



Does this work as a security work around? I don't know; but thought to post as a possible discussion idea.



Cheers,



BlackMacX

dteare

[quote name='BlackMacX' timestamp='1305648188' post='27190']

To possibly answer my own concerns and posit a possible solution, I wonder if the following solution might work:



1. create a encrypted container within Dropbox

2. move my 1Password.agilekeychain file therein

3. create a symbolic link to the 1Password.agilekeychain file

4. move the symbolic link to the previous location within Dropbox and remove the symbolic link component of the name (so that it now appears as 1Password.agilekeychain)

5. only update your iPhone/mobile device's 1Password contents with at home; but via Dropbox. Then have the encrypted container close when you've finished.



Does this work as a security work around? I don't know; but thought to post as a possible discussion idea.

[/quote]



You can certainly create an encrypted container, put your 1Password data within it, and store this on Dropbox, but it is going to be prone to error and make syncing with the iPhone very difficult.



You could use something like Knox to create an encrypted vault, store it on Dropbox, and then have Knox open it for you before using 1Password. Knox will mount it in /Volumes/MyEncryptedVaultName and you could have 1Password use this location. The trick is you'll have to have this vault open whenever using 1Password (this is probably ok as you can leave it always open and auto-open on login; the only catch is you could only open this vault on a single computer at a time) and iPhone syncing with Dropbox will not work at all (this is likely not ok). If you decided to only sync using WiFi, this could work, but it is not very convenient.



I think the best solution is to wait a little longer for the new data format we'll be introducing "soonishly". I can't promise a specific date as there are a lot of moving parts, but we are getting closer to releasing this publicly.

Pazzie

After reading things like:



[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.[/quote]



and



[quote]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.[/quote]



I'm curious how the problem with encrypting/decrypting website urls will be solved when 1Password will be using the new data format. Also you mentioned the balance between security and convenience. Will the improved security comes at the cost of losing convenience?

jpgoldberg

[quote name='Pazzie' timestamp='1305804158' post='27348']

I'm curious how the problem with encrypting/decrypting website urls will be solved when 1Password will be using the new data format. Also you mentioned the balance between security and convenience. Will the improved security comes at the cost of losing convenience?

[/quote]



These are great questions, Pazzle. Way back in the summer when Roustem told me that he thought that he had a solution, I was skeptical. But I also know to never under-estimate him. So the short answer is that we can do this because Roustem and Dave and the other developers are really really smart.



The longer answer has several parts.



The first is that computers are much more powerful today than when we developed the current keychain format. The "minimal specification" we have to worry about now is much higher than what we had to worry about then. As we've mentioned elsewhere, 1Password version 3.5.9 will be the last version run on OS X 10.5 (Snow Leopard). Given how tightly components of 1Password need to integrate into other components of the operating environment it is extremely difficult to have a single version of 1Password work on more than two versions of OS X. So after 3.5.9, 1Password for Mac will be Intel-only.



We may see some performance hit on 1Password for Windows on older machines, but we've learned that in practice 1Password performance on Windows is more constrained by file system interactions than through CPU intensive activities. So in practice this shouldn't really be noticeable.



The second thing is that the Location information for an item will be encrypted differently than the rest of the data. So while it will be kept private, it may not be as well protected as the rest of the data. We will, of course, provide the precise details when we are ready to release things.



Thirdly there is a really clever bit that I'm not ready to talk about yet.



Finally there are simply improvements in our data management algorithms taking into account everything we've learned since we introduced the current format years ago.



Please note that everything I've said is pretty much subject to change (though Roustem's awesomeness is untouchable). We really don't like announcing features until they are released. We like to remain Agile.



Cheers,



-j

Pazzie

Thank you for the answers jpgoldberg.



I'm glad that the 1Password developers are really really smart and came up with a solution <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/smile.gif' class='bbc_emoticon' alt=':)' /> .



I'm looking forward to the release of it and hope it also runs well on WINE.



Cheers,

Pazzie

jpgoldberg

[quote name='Pazzie' timestamp='1305894753' post='27434']

Thank you for the answers jpgoldberg.[/quote]

My pleasure, Pazzie.



[quote]

I'm looking forward to the release of it and hope it also runs well on WINE.[/quote]

We don't officially support running 1Password for Windows under WINE, but we are delighted that so many users have reported success using 1Password this way.



May I ask what Linux flavor you using for this?



Cheers,



-j

Pazzie

[quote name='jpgoldberg' timestamp='1305906737' post='27444']

We don't officially support running 1Password for Windows under WINE, but we are delighted that so many users have reported success using 1Password this way.



May I ask what Linux flavor you using for this?

[/quote]



I'm currently using Ubuntu 11.04, but I'll also try Linux Mint 11 and Fedora 15 when their final version will be released this month.



Because I use Bootit Bare Metal I can create more than 4 primary on my HDD, so I can dualboot Windows 7 + multiple linux distros.

kandjar

Hi,



I'm not sure if it's the right forum; since it's kind of a 1Password3 generic question <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/smile.gif' class='bbc_emoticon' alt=':)' />

Anyhow,



I read in your online documentation (http://help.agile.ws/1Password3/cloud_storage_security.html) that:

[i]"some information among your 1Password data is not encrypted. The unencrypted information is includes the web locations (URLs) and the [b]Titles you give to items[/b]."[/i].



From what I read about security; knowledge about what is encrypted can help the hacking process.



I also think it's somewhat common to have people using their mailing addresses as title for the "cards" used to connect to their mail server, such as: "blahblah@gmail.com"; especially if they have multiple gmail accounts for example. In which case: the title will match the login (minus the seed I presume); giving potentially valuable information to the hacker.



Am I wrong? Is this something to be aware off, in order to make sure to never use the login as a title of card?

Or does it not matter?



---





Also, I found it dangerous to have: [i]"password strength, creation time, and last modify time."[/i] unencrypted.

Even if not recommended; having a weak password and a very old "last modify time" or even matching: "creation time" and "last modified time" could help the potential hackers: for example, since you never change the password, he has all the time he needs to tried to hack it; and if it's weak, it gives him information about what to try.



People may have weaker, easier to remember password for website, for which they don't care "too much"; that doesn't mean they want hackers to find their passwords.



Don't you agree?





Thanks,

Kandjar

khad

Welcome to the forums, Kandjar!



I have merged your post with the appropriate thread. As you can see above, we have discussed this quite a bit already and work has already begun on the new data format. <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/skype_wink.png' class='bbc_emoticon' alt=';-)' />



Security is a process, not a product. We are proud of where we are today regarding the security of storing 1Password data in the cloud, but we wouldn't be true to our name or acting in your best interests if we simply rested on our laurels. <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/skype_smile.png' class='bbc_emoticon' alt=':-)' />



If you have any any additional questions or concerns, please let me know.



Cheers,

kandjar

[quote name='khad' timestamp='1306287831' post='27696']

Welcome to the forums, Kandjar!



I have merged your post with the appropriate thread. As you can see above, we have discussed this quite a bit already and work has already begun on the new data format. <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/skype_wink.png' class='bbc_emoticon' alt=';-)' />



Security is a process, not a product. We are proud of where we are today regarding the security of storing 1Password data in the cloud, but we wouldn't be true to our name or acting in your best interests if we simply rested on our laurels. <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/skype_smile.png' class='bbc_emoticon' alt=':-)' />



If you have any any additional questions or concerns, please let me know.



Cheers,

[/quote]



True; it's a process; nonetheless you're making it in a product ;P



On the positive side; I really appreciate the fact that your are not hiding this fact.

Now, I'm gonna read the thread to see if my concerns have already been answered <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/smile.gif' class='bbc_emoticon' alt=':)' />



--



Although, I though a bit longer about the issue; and one point come to mind:

Some "work related" URL are 'in the cloud' without actually been public, visible, in other word: not google-able.

The less the hacker know the better therefore: those URL aren't meant to be known either.

brenty

[quote name='kandjar' timestamp='1306295120' post='27714']

True; it's a process; nonetheless you're making it in a product ;P



On the positive side; I really appreciate the fact that your are not hiding this fact.

Now, I'm gonna read the thread to see if my concerns have already been answered <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/smile.gif' class='bbc_emoticon' alt=':)' />



--



Although, I though a bit longer about the issue; and one point come to mind:

Some "work related" URL are 'in the cloud' without actually been public, visible, in other word: not google-able.

The less the hacker know the better therefore: those URL aren't meant to be known either.

[/quote]



Hey there, kandjar!



Thanks for following up. By all means, review the discussion and ask away!



You make some excellent points. But I think it is important to make a distinction between [b]privacy[/b] and [b]security[/b]. While there is certainly some overlap, I think that in most cases [b]security[/b] is on a "need-to-know basis," whereas [b]privacy[/b] is more of a "want-to-know basis." There are certainly things that I don't want people to know that wouldn't necessarily pose a security risk if they did.



I think a good example is financial information. I definitely don't [i]want[/i] people to know the balance of my bank account (frankly, sometimes [i]I[/i] don't want to either...) -- that's [b]privacy[/b]. But I [i]need[/i] people to not know my account number, PIN, and other key information -- this would pose a [b]security[/b] risk, as it would allow others access to my money.



That said, you are correct that in some situations privacy breaches can lead to security breaches as well. Fortunately, good practices can help avoid this in most cases. With the next-gen 1Password data format, we plan to have [i]everything[/i] encrypted, though. While we stand behind the decisions we made with the AgileKeychain format (128-bit AES encryption of sensitive data, etc.), with today's hardware we have the luxury of going even further. It's more of a "because we can," future-proofing measure rather than something reactive we are doing. And if this change keeps our current customers happy and brings in new folks who were previously on the fence, that's even better! Mainly we are just looking forward and staying Agile. <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/smile.gif' class='bbc_emoticon' alt=':)' />

kandjar

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

updatedAt - unencrypted;

locationKey - unencrypted (part of 'location');

passwordStrength - unencrypted;

title - unencrypted;

location - unencrypted;

createdAt - unencrypted.

...

[/quote]



I understood the reasons behind having unencrypted data in the current format,

at least regarding, the name of the "Card" and the URL; however, I don't see any reason to have the passwordstrength for example in it.

Same with the creation date and the last update date...



Even assuming that people would want to sort by these fields, having them wait to access these data would have been more legit IMHO that having these data unencrypted (since it's not something you would do everyday... heck, I've been using a password manager for more than 5 years, and still haven't felt the need to sort by such fields)



I'd very much appreciate if someone could explain to me the reason for such fields to be in clear text.



[quote name='brenty' timestamp='1285273316' post='11902']

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.

[/quote]



Correct me if I'm wrong, but syncronization is not backup! <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/smile.gif' class='bbc_emoticon' alt=':)' />



[quote name='Paranoid' timestamp='1287359855' post='13479']

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

[/quote]



+1



[quote name='khad' timestamp='1287362431' post='13484']

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)."

[/quote]



Nonetheless, it seems that they have a unique key to encrypt the data; which doesn't make me feel secure <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/smile.gif' class='bbc_emoticon' alt=':)' />



You advertise that it's more likely to have someone stealing your computer than actually breaking through the Dropbox security; I would reply that people would be more tempted to break through dropbox security than coming to your house to steal your PC. They know they will find valuable information inside Dropbox while they can't be sure they will find that on your computer.

We're talking about above 2 millions users vs 1 PC! <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/smile.gif' class='bbc_emoticon' alt=':)' />



[quote name='brenty' timestamp='1289886713' post='15225']

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=':)' />

[/quote]



Well unless people stole your password file and waited for such time; the upgrade would not help against already captured database (granted, they would need a really good reason to access your database to go through the trouble to keeping it for years <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/tongue.gif' class='bbc_emoticon' alt=':P' />)

Also: I just want to say that after reading online papers, I'm fine with 128bits AES.





---



Also:



What would have prevented to encrypt the currently unencrypted information with another AES key which could, as opposed to the other small lockbox you talked about in your doc, been decrypted and keep in memory while you unlock the database????

brenty

[quote name='kandjar' timestamp='1306299355' post='27719']

I understood the reasons behind having unencrypted data in the current format,

at least regarding, the name of the "Card" and the URL; however, I don't see any reason to have the passwordstrength for example in it.

Same with the creation date and the last update date...

[/quote]



Both our customers and my coworkers and I take advantage of this when searching or creating Smart Folders to ferret out passwords that are either outdated or weak (or both), so that we can update and strengthen them. <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/smile.gif' class='bbc_emoticon' alt=':)' />



[quote]

Even assuming that people would want to sort by these fields, having them wait to access these data would have been more legit IMHO that having these data unencrypted [...] I'd very much appreciate if someone could explain to me the reason for such fields to be in clear text.

[/quote]



At your service! In all seriousness though, the AgileKeychain format was released nearly 3 years ago. While that may not sound like a long time, in computing terms it is huge. I don't want to even think about the system I was using then. With the tremendous advances on the hardware side and the awesome improvements Apple has made to OS X, we have a lot more flexibility now. For example, if I am not mistaken, 1Password 2 supported [i]Panther[/i]. I barely remember Panther. I guess what I am getting at is that we want 1Password to run beautifully on all supported hardware and OS versions. Moving to Snow Leopard/Lion and Intel-only for 3.6+ should give us enough room to "beef up" encryption and have nothing in plaintext, without having to sacrifice performance.



[quote]

Correct me if I'm wrong, but syncronization is not backup! <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/smile.gif' class='bbc_emoticon' alt=':)' />

[/quote]



You are correct, sir. However, in the case of Dropbox, it can serve as a backup in limited fashion, since you can download files and also recover deleted ones. I wouldn't suggest using it as your sole offsite backup, because that is not what it is meant for. But in a pinch (and believe me, I have been there) being able to restore from Dropbox is a lifesaver.



[quote]

Nonetheless, it seems that they have a unique key to encrypt the data; which doesn't make me feel secure <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/smile.gif' class='bbc_emoticon' alt=':)' />

[/quote]



Since Dropbox encrypts the data for you (although you can certainly add your own encryption beforehand), they have to have they key, as opposed to services where the data is encrypted one your own computer (often allowing you to choose your own key.) Even if they remove their encryption, your Master Password is still needed to decrypt your 1Password data.



[quote]

You advertise that it's more likely to have someone stealing your computer than actually breaking through the Dropbox security; I would reply that people would be more tempted to break through dropbox security than coming to your house to steal your PC.

[/quote]



I think the more salient point is that, again, in either case -- whether someone gains access to your 1Password data via a Dropbox "backdoor" or the one to your home -- your Master Password is needed to decrypt it.



[quote]

Well unless people stole your password file and waited for such time; the upgrade would not help against already captured database (granted, they would need a really good reason to access your database to go through the trouble to keeping it for years <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/tongue.gif' class='bbc_emoticon' alt=':P' />)

Also: I just want to say that after reading online papers, I'm fine with 128bits AES.

[/quote]



This is an excellent point. I hadn't considered this myself. Maybe I am just not that patient! But in the end, the things I would most be concerned about people getting out of my Vault also tend to have a built-in sense of urgency. For example, all of my credit cards will expire long before the encryption can be brute-forced, and if I know my keychain file has been compromised I will likewise have plenty of time to make arrangements to change accounts and secure fraud and identity theft protection services. Also, I will likely have time to retire, grow old, and die. <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/wink.gif' class='bbc_emoticon' alt=';)' />





[quote]

What would have prevented to encrypt the currently unencrypted information with another AES key which could, as opposed to the other small lockbox you talked about in your doc, been decrypted and keep in memory while you unlock the database????

[/quote]



I am a little confused by the question, but if you mean "what would prevent someone from accessing the unencrypted data in RAM after you have unlocked 1Password?" the answer is "only you," I would say. 1Password only decrypts the data it needs at any given time, rather than decrypting the entire keychain all at once. And if someone has access to your computer, they can accomplish a lot more by accessing your unencrypted data than they would trying to break into 1Password. And if you are around, they can probably just get the Master Password from you somehow. [img]http://forum.agile.ws/public/style_emoticons/default/mellow.gif[/img]



Anyway, I hope this helps. Let me know if I missed something, or if you have any other questions. <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/smile.gif' class='bbc_emoticon' alt=':)' />

kandjar

[quote name='brenty' timestamp='1306307175' post='27725']

Both our customers and my coworkers and I take advantage of this when searching or creating Smart Folders to ferret out passwords that are either outdated or weak (or both), so that we can update and strengthen them. <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/smile.gif' class='bbc_emoticon' alt=':)' />



At your service! In all seriousness though, the AgileKeychain format was released nearly 3 years ago. While that may not sound like a long time, in computing terms it is huge. I don't want to even think about the system I was using then. With the tremendous advances on the hardware side and the awesome improvements Apple has made to OS X, we have a lot more flexibility now. For example, if I am not mistaken, 1Password 2 supported [i]Panther[/i]. I barely remember Panther. I guess what I am getting at is that we want 1Password to run beautifully on all supported hardware and OS versions. Moving to Snow Leopard/Lion and Intel-only for 3.6+ should give us enough room to "beef up" encryption and have nothing in plaintext, without having to sacrifice performance.

[/quote]



Fair enough; and btw, I worked in the video game industry; so believe me I know how long 3 years is in the computer world <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/tongue.gif' class='bbc_emoticon' alt=':P' /> <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/smile.gif' class='bbc_emoticon' alt=':)' /> <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/smile.gif' class='bbc_emoticon' alt=':)' />



[quote]

You are correct, sir. However, in the case of Dropbox, it can serve as a backup in limited fashion, since you can download files and also recover deleted ones. I wouldn't suggest using it as your sole offsite backup, because that is not what it is meant for. But in a pinch (and believe me, I have been there) being able to restore from Dropbox is a lifesaver.

[/quote]



Ouch... Being amongst the people who have a hard time trusting Dropbox even when it comes down to store encrypted files...

Knowing now that they also keep deleted files makes me even less confident.... <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/skype_speechless.png' class='bbc_emoticon' alt=':|' />

(that's one of the reason I never did sync through gmail account using my current password manager)



[quote]

Since Dropbox encrypts the data for you (although you can certainly add your own encryption beforehand), they have to have they key, as opposed to services where the data is encrypted one your own computer (often allowing you to choose your own key.) Even if they remove their encryption, your Master Password is still needed to decrypt your 1Password data.

[/quote]



True. Except that they deliberately hide this fact to the user for a long time letting him think the encryption was using their password...



[quote]

I think the more salient point is that, again, in either case -- whether someone gains access to your 1Password data via a Dropbox "backdoor" or the one to your home -- your Master Password is needed to decrypt it.

[/quote]



Fair enough.





[quote]

This is an excellent point. I hadn't considered this myself. Maybe I am just not that patient! But in the end, the things I would most be concerned about people getting out of my Vault also tend to have a built-in sense of urgency. For example, all of my credit cards will expire long before the encryption can be brute-forced, and if I know my keychain file has been compromised I will likewise have plenty of time to make arrangements to change accounts and secure fraud and identity theft protection services. Also, I will likely have time to retire, grow old, and die. <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/wink.gif' class='bbc_emoticon' alt=';)' />

[/quote]



Well, I may sometimes be a little bit too paranoiac <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/skype_tongueout.png' class='bbc_emoticon' alt=':-P' />







[quote]

I am a little confused by the question, but if you mean "what would prevent someone from accessing the unencrypted data in RAM after you have unlocked 1Password?" the answer is "only you," I would say. 1Password only decrypts the data it needs at any given time, rather than decrypting the entire keychain all at once. And if someone has access to your computer, they can accomplish a lot more by accessing your unencrypted data than they would trying to break into 1Password. And if you are around, they can probably just get the Master Password from you somehow. [img]http://forum.agile.ws/public/style_emoticons/default/mellow.gif[/img]



Anyway, I hope this helps. Let me know if I missed something, or if you have any other questions. <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/smile.gif' class='bbc_emoticon' alt=':)' />

[/quote]



Sorry for the confusion I just wanted to point out that:

the unencrypted data could have been encrypted as a whole block and decrypted during the "unlocking" process (using maybe another AES key)



So instead of having the file containing:

[unencrypted general data] + [encrypted card using AES key] * #cards

The file would look like:

[encrypted general data using AES key1] + [encrypted card using AES key2] * #cards

And when the user try to access the database, the app/plugin would ask him for his master password, then decrypt the "general data" blocks.

brenty

[quote name='kandjar' timestamp='1306310835' post='27726']Fair enough; and btw, I worked in the video game industry; so believe me I know how long 3 years is in the computer world <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/tongue.gif' class='bbc_emoticon' alt=':P' /> <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/smile.gif' class='bbc_emoticon' alt=':)' /> <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/smile.gif' class='bbc_emoticon' alt=':)' />[/quote]

Oh, man! And here I am, preaching to the choir.[img]http://forum.agile.ws/public/style_emoticons/default/rolleyes.gif[/img]



[quote]

Ouch... Being amongst the people who have a hard time trusting Dropbox even when it comes down to store encrypted files...

Knowing now that they also keep deleted files makes me even less confident.... <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/skype_speechless.png' class='bbc_emoticon' alt=':|' />

(that's one of the reason I never did sync through gmail account using my current password manager)[/quote]

Well, again: Data that is encrypted in the first place (such as 1Password data) will still not be fully accessible without its key in addition to the one Dropbox uses, archived or otherwise. Since you are comfortable with AES128, this should be less of a problem, although I understand the initial "eep!" gut reaction. We all had that when the whole Dropbox thing broke, but now that we've had access to additional information and the time to examine it throughly, it is not a concern. The main problem with the situation was how people felt they were mislead (ourselves included) and how it was handled when this came to light. For our part, we just needed to verify that we got accurate information and that our customers (and ourselves) were not adversely affected.



[quote]

True. Except that they deliberately hide this fact to the user for a long time letting him think the encryption was using their password... [/quote]

I am not sure it is fair to say whether or not this was deliberate, but the claims they made were certainly misleading. And when it comes to security, accuracy and transparency are paramount. I like to think we practice what we preach in this regard. [img]http://forum.agile.ws/public/style_emoticons/default/cool.gif[/img]

[quote]

Well, I may sometimes be a little bit too paranoiac <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/skype_tongueout.png' class='bbc_emoticon' alt=':-P' />[/quote]

Hey, when it's your data on the line, you have every right. I reserve this right for myself as well. [img]http://forum.agile.ws/public/style_emoticons/default/tongue.gif[/img]

[quote]

Sorry for the confusion I just wanted to point out that:

the unencrypted data could have been encrypted as a whole block and decrypted during the "unlocking" process (using maybe another AES key)

[/quote]



Thank you for clarifying that. I really like this idea. I can't speak to whether or not it was not done this way for performance reasons, or because of something more technical. The good news is that if all goes as planned, we will be both expanding what is encrypted and strengthening the encryption itself as well. If you haven't already seen it, you should check out [url="http://blog.agile.ws/2011/04/looking-ahead-in-security/"]Jeff's blog post[/url] which talks about this in some detail...well, as much as we are willing to divulge at this time, anyway. <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/wink.gif' class='bbc_emoticon' alt=';)' />

jpgoldberg

[quote name='kandjar' timestamp='1306299355' post='27719']

I understood the reasons behind having unencrypted data in the current format,

at least regarding, the name of the "Card" and the URL; however, I don't see any reason to have the passwordstrength for example in it.[/quote]

I really wish we had our old forum posts from years ago. When the current data format was first announced there was vigorous discussion about the password strength information not being encrypted. I wasn't part of the team then, but would hang on on the forums every now and then.



I didn't like the password strength information remaining unencrypted. Indeed, I probably even had a public tantrum regarding that. (So maybe I should be glad that we no longer have the posts from 2008). Dave and Roustem, if not fully persuading me, at least got me to see their side of the argument.



First of all, we need to remember the kind of hardware people were using back then. If we had had the password strength encrypted, it would be impossible to both follow the practice of decrypting only things as needed and also having the ability of people to sort their data by password strength. The ability to sort by and easily view strength carries its own security advantages. This is particularly true for people who still have "legacy" passwords that were created before they used password management.



Actually one on my home grown password management systems (I did a great deal of hunting around before I settled on 1Password) used pwgen which created 8 character passwords drawn from [a-zA-Z0-9]. At the time that I created these those were reasonably strong. Now they aren't. So I certainly have found it useful to sort my passwords by strength.



People often mistakenly think that the big security trade-offs are between security and convenience. But often they are between one type of security and another. Performance isn't just a convenience issue. If a product is so slow that people don't use it, then it provides no security to those users.



As for the creation and modify time, I'm afraid that those will still, indirectly, be available. Each item in your 1Password data is stored in its own file. The modify times of those files is used by the syncing process.



I suppose it would be possible for us to tamper with the creation time of the files. I don't see a reason to do so, but if you do, please elaborate.



Anyway, I'm not disagreeing with you about the original design decision regarding the password strength. My view on that hasn't changed over the years, even after joining the team last year. What I am saying is that it wasn't an unreasonable design decision at the time. Things have changed, and we are changing our design as well.



[quote]

Correct me if I'm wrong, but syncronization is not backup! <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/smile.gif' class='bbc_emoticon' alt=':)' />

[/quote]

You are correct. But synchronization to a system that does back up is back up. If you only have your 1Password data on, say, an iPhone, then you really do need to take care that it doesn't get lost. We recommend that people perform a backup of their iOS data before every upgrade of either iOS or 1Password.



http://help.agilebits.com/1Password_touch/backup.html



But if you are syncing your 1Password data with a Mac or PC and backing those up, then you don't particularly need to worry about your iOS data.



One thing to keep very much in mind is that [b]iTunes syncing provides no meaningful backup of 1Password data[/b]. (I know this isn't what you were talking about, but I never pass up an opportunity to say that.)





[quote]

You advertise that it's more likely to have someone stealing your computer than actually breaking through the Dropbox security; I would reply that people would be more tempted to break through dropbox security than coming to your house to steal your PC. They know they will find valuable information inside Dropbox while they can't be sure they will find that on your computer.

We're talking about above 2 millions users vs 1 PC! <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/smile.gif' class='bbc_emoticon' alt=':)' />[/quote]

It certainly is true that Dropbox is a much juicier target than an individual PC. But burglaries are motivated by things other than going after data.



But I know that there are no numbers behind that statement (as acknowledged in the document). We could do the research to get a reasonable estimate of how likely you are to have your computer stolen, but there is no data that we could use to estimate the likelihood of a Dropbox breach.



Again, we are moving forward with a new data format design that is better suited for life in the cloud.



[quote]

Also: I just want to say that after reading online papers, I'm fine with 128bits AES.

[/quote]

I'm glad that there's something you like <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/skype_wink.png' class='bbc_emoticon' alt=';-)' /> (Though we are moving to AES with 256 bit encryption in the new format).



[quote]What would have prevented to encrypt the currently unencrypted information with another AES key which could, as opposed to the other small lockbox you talked about in your doc, been decrypted and keep in memory while you unlock the database????

[/quote]



To get a scheme like that to work once we decrypt the data we need to put it some place. It could be too much to hold in memory (some of us have thousands of items) so would need to be written to a temporary file. That file would need to be securely wiped even when 1Password exited abnormally. This adds to complexity and doesn't really protect that data in question all that well.



This, incidentally, was a big problem with my home-grown system. I decrypted everything at once and so had to rely on using encrypted swap to avoid the whole thing getting accidentally dumped somewhere.



There really is great value in having only one item decrypted at a time. And that is an aspect of our design choice that I am extremely please with. (It's hard to say what my favorite design element is, but this is really near the top.) That buys us so much in terms of security, simplicity, and performance that we should only move away from it if absolutely compelled to.



I don't expect to persuade you that we've made all the right choices, but I do wish to communicate that our choices have been well considered.



Cheers,



-j

dougiedd

I was looking at which of my dropbox files have been recently updated ( i only use this for 1password)

I see a file contents.js which seems to have a listing of all the sites i use 1password for?

Is that correct?

khad

Welcome to the forums, dougiedd! I have merged your post with the appropriate thread. As you can see, this has been discussed quite extensively already. Please see above and let me know if you have any additional questions or concerns. <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/skype_smile.png' class='bbc_emoticon' alt=':-)' />



Cheers,

luke1970

Hello,



I have some questions:

In folder Application Support/1Password is a folder [b]Fill[/b]. What's inside this folder?

Here at my Mac are some old logins inside, which I delete in 1Password for months.



Another question: 1Password encrypt only username and password of a website login in 1Password database?

Why is the database not complete encrypted? I can see the website URL in the 1Password login data.



Greetings, Bernd

flambino

So by now it's well-known that Dropbox isn't all unicorns and rainbows. For one, they can access your files all they want, and now they apparently hosed their own authentication system, so that you could log in to any account without the right password. Or indeed without any password. Thanks, Dropbox! Really inspires confidence!



Seen as how 1Password's preferred method of syncing is via Dropbox, I'm sure you guys have already been discussing what - if anything - to do about it.



My biggest worry isn't so much that someone gets access to my Dropbox and decrypts my keychain, but rather that quite a few things aren't encrypted at all. I know you have to balance speed and security, but I'd wish that, for instance, login URLs were encrypted too. As it is, they're plainly readable, even if the password is encrypted. That, to me, seems like an information disclosure issue. I handle some logins on behalf of clients, and frankly it's nobody's business (besides the client's) that I even have those logins. But since the URLs are cleartext, it's not exactly secret.



So I'd like an option to encrypt every field, or to simply encrypt the keychain file entirely. I know this will be slower, but it really seems like it would be worth it. Especially if the file leaves the computer.



Incidentally, I was just looking into ways of encrypting the keychain files myself, but along the way I noticed that I can't seem to move the keychain file at all. It's just impossible. The 1Password preference allow me to pick another data file, except I can't ever select another one in the dialog; the button's disabled. And besides, I don't want to use another data file, I just want to change the location of the current one.



In other words, it seems I can't actually move my keychain file off of Dropbox, without having to (I suppose) export everything, "reset" 1Password, and import everything. But in this case, all I want is to [i]not[/i] have the keychain file on Dropbox. I just want to move it away from there. Is there really no simple way of doing that?



It should be said that I tried this on a Mac running Leopard, so it may just be a bug.

khad

Hey Bernd and flambino,



Please see the rest of this thread for the lengthy discussion on the topic and let me know if you have any additional questions. The short version is that only metadata (the same sort of information in your browser history) is available. All your sensitive data is completely encrypted, and [url="http://blog.agilebits.com/2011/04/looking-ahead-in-security/"]the upcoming data format will be encrypting everything[/url]. I don't have a time frame for it, but we have done some limited internal testing with it.



If you are pressed for time, [url="http://forum.agile.ws/index.php?/topic/1958-all-information-is-not-encrypted/page__view__findpost__p__27143"]an earlier post of mine summarizes the situation[/url] pretty well (if I do say so myself).



Please let me know if you have more questions or concerns. I think you already know that we are always here to help. <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/skype_smile.png' class='bbc_emoticon' alt=':-)' />



Cheers,

chadseld

Bernd,



The data in the Fill folder is used to support the Go & Fill feature. When Go & Fill is requested, a file is created with the destination URL, a unique ID of the login item to fill, and a timestamp. When the browser lands on a matching URL, the login item is retrieved and used to fill the web form. These files normally are removed after use. They may persist for a while if there was an error filling (e.g. the destination URL is not the actual login page). You can delete this folder with no harm done. Alternatively, if you perform a successful Go & Fill I believe the folder contents will be automatically purged.



You are correct, this is an area we will have to consider with our upcoming file format.

khad

flambino,



I should also add that you can simply move your data file outside your Dropbox folder in Finder. Drag it to another folder then double-click it to activate it in 1Password. The default location is in 1Password's Application Support folder if you want to just put it back where it began its life:



[code]~/Library/Application Support/1Password/1Password.agilekeychain[/code]

I hope that helps. Please let me know.



Thanks!

flambino

[quote name='khad' timestamp='1308707771' post='29869']

Please see the rest of this thread for the lengthy discussion on the topic and let me know if you have any additional questions.

[/quote]



I guess I should have figured there'd already be a thread like this. Apologies for the thread-merging inconvenience.



[quote name='khad' timestamp='1308707771' post='29869']

[url="http://blog.agilebits.com/2011/04/looking-ahead-in-security/"]the upcoming data format will be encrypting everything[/url]. I don't have a time frame for it, but we have done some limited internal testing with it.

[/quote]



Interesting. Guess I should have found that too before posting <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/smile.gif' class='bbc_emoticon' alt=':)' />



While I may not have added anything substantial to the discussion, I will say though, that my beef wasn't directly with the partial encryption 1Password employs. That's a well-made trade-off I'd say... except in some scenarios. My post was really a reaction to the Dropbox debacle of the past few days. Granted, it's a moot point if you're already developing a new format, but I rather liked the idea of using full encryption [i]only[/i] when data leaves the computer to sync (e.g. Dropbox). I figured (since I'm not the one implementing any of it <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/wink.gif' class='bbc_emoticon' alt=';)' /> ) that might be a better trade-off in that specific case. 1Password could decrypt the fully-encrypted keychain once, get the normal keychain files from that, and store those locally. Changes to the keychain would only require a full decryption/encryption of certain files inside the keychain bundle. Seems feasible, performance-wise.



But, again, that's a moot point, and no doubt it's already been suggested elsewhere in this thread (which I freely admit I did not read in its entirety, cuz', like, there's [i]a lot[/i] of text here, man).

And no doubt that you've already thought of it anyway. Hmmm... I swear I'll try to actually contribute next time <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/smile.gif' class='bbc_emoticon' alt=':)' />



[quote name='khad' timestamp='1308786274' post='30043']

I should also add that you can simply move your data file outside your Dropbox folder in Finder. Drag it to another folder then double-click it to activate it in 1Password.

[/quote]



Thanks for the tip. I was trying to move it from within 1Password, since manually moving a file that an app depends on is generally A Bad Thing™ to do. I guess it makes sense in this case, but I just didn't think of the keychain file as something you'd just double-click. I mean, it makes perfect sense now that you say it, but to my mind the keychain bundle seemed more integral. I.e. I didn't think of it as a "document", since 1Password isn't a document-centric app (and as you say, the file's in ~/Library/Application Support by default, and not ~/Documents). Hence it seemed counter-intuitive to just move it around willy-nilly. Hope that makes sense.



Cheers, and thanks again

khad

[quote](which I freely admit I did not read in its entirety, cuz', like, there's [i]a lot[/i] of text here, man).[/quote]

ROFLMAO <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/laugh.gif' class='bbc_emoticon' alt=':lol:' /> Yes, there is, and I don't blame you!



[quote]I didn't think of it as a "document", since 1Password isn't a document-centric app (and as you say, the file's in ~/Library/Application Support by default, and not ~/Documents). Hence it seemed counter-intuitive to just move it around willy-nilly. Hope that makes sense.[/quote]

That makes compete sense. In fact, there used to just be a button to "Move Data File" rather than "Move to Dropbox" so it was once possible to do exactly what you describe. I think that even iPhoto allows you to move and double-click its "database" though, but I completely understand where you are coming from on this. There has been talk of making the button a toggle to "Move to Dropbox" and "Stop Syncing with Dropbox" (or similar) which I presume would just move the file back to its default location in your App Support folder.



If you need anything else, we are always here to help. We love talking about these things. <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/skype_smile.png' class='bbc_emoticon' alt=':-)' />



Best regards,