For an 8 dollar app I expected a smoother experience. I give some feedback. Agile, take what you can from it. Hopefully the app will improve if many users feel this way.
1) The list of accounts seems to not be encrypted. This is private data! I don't want this revealed to anyone!
2) The default of your app is to NOT encrypt using the master password? That does not make sense at all! I'd rather accidentally be too secure than not secure.
3) I'm worried... why does your documentation say that the backup should be kept safe? Surely your encryption must be good enough that I can hand it to anyone I don't trust. If your concern is merely that I might not have chosen a good password and that a dictionary attack can be used, rather educate the users as they are about to choose their master password.
4) Why can't I do anything useful with this backup, like import it on the Mac version of your app? Couldn't you make this backup in a universal importable format used between all versions of your app?
5) How do I do the WiFi sync with the app? Your documentation talks about all the things that can go wrong with network setup and all that. My question is more... where is the button on the Mac version to sync over WiFi with the iPhone version? You say to enter authorization codes, but where? Where must the authorization codes be entered? I can't find the place.
Here is what I expected from this app:
I enter a master password which unlocks a 100% encrypted archive. The archive itself can be distributed through any means, like your Dropbox and WiFi options or even email. With no "cry wolf" warnings that just confuse me as to when things are safe and when things are not safe. A properly encrypted archive should always be safe to distribute.
When the archive is "open" though (master password is in the iPhone memory), I have to admit I like your pin feature (unlock code) which I have set on a very short timer. Then the master password is on a longer timer. Also, it is great that the lock and home buttons on the iPhone immediately lock everything.
To the developers of this app: I'm used to working with Truecrypt. Check out their documentation and explanations and FAQ on encryption. You can see that they are really serious about encryption and keeping data safe. I'd expect no less from a paid for app.
There is a very lengthy discussion in another thread on the topic of why the Agile Keychain Format was originally designed this way. The TL;DR version is that there was some further discussion elsewhere regarding this topic, and, while we do not have a time frame for a specific release, a fully encrypted data file is definitely on our radar 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.
This is something else we are considering in the future. Thanks for letting us know you would be interested in this option as well.
From our "Backing Up and Restoring Your 1Password touch Data" guide: "You may wish to store the backup file somewhere else that is both safe and memorable in case you need to access it further in the future." As in, don't store your backup on a USB flash drive that you give to the neighborhood kids to play baseball with, and don't forget where it is.
That may be something we do in the future, but for various technical reasons, your 1Password data is not stored directly in an .agilekeychain file in our iOS apps. Syncing via Dropbox will allow you to always have a data file in your Dropbox folder that can be read by 1Password on all the platforms we support. You can also sync with 1Password for Mac via Wi-Fi and export in one of several different formats.
With 1Password running on both your Mac and iPhone, you will be prompted automatically when you tap the "Allow New Connections" button on your iPhone. Has this not been your experience, or were you just asking preemptively?
It sure is. Could you provide the link or screenshot to these warnings you are describing? Perhaps we need to update some documentation.
Two of the main requirements for the design of our Agile Keychain Format were:
Since we did not want to write a single line of encryption code, the Agile Keychain therefore uses the OpenSSL library for all of its encryption and key generation needs.
OpenSSL is open source, used on the majority of servers in the world, shipped on every Mac, and actively supported by a huge community. It is also compliant with the FIPS 140-1 and FIPS 140-2 Federal Information Processing Standards.
OpenSSL is used to encrypt all confidential information with AES (Advanced Encryption Standard) using 128-bit encryption keys and performed in Cipher Block Chaining (CBC) mode along with a randomized Initialization Vector.
You can read more in our "Agile Keychain Design" document.
I hope that helps — if even a little bit. Please let me know if you have additional questions or concerns. It is great that you are thinking about these things!
I see now that I can't edit the original topic of my post, so if this is causing you bad publicity I give consent to you adding "concerns resolved" to the topic if this is within your power.
Regarding ease of use I think I'll keep my opinion though that it could be a bit better
Thanks for your explanation about what is meant by "store the backup file somewhere else that is both safe and memorable". That was what I was referring to, yes. Regarding the "cry wolf" comment, the iPhone app recommends that you do not keep the Wifi sync service running for long.
So it seems you're saying there is no explicit button or menu item for this? You're right, an automatic prompt has not been my experience but now I know to follow your troubleshooting instructions and not look for the button
Finally, thanks for the additional explanation on the internal workings of 1password. I'm totally in support of using a proved encryption system.
I just want to add a couple of things to what Khad has already explained.
In addition to what Khad said about keeping backups safe so that you can get to them when you need them, points 1 and 3 are connected, as is your point about things being stored "low security".
As as been extensively discussed (and you are welcome to join that discussion), 1Password does not encrypt the kind of information that you would find in a browser bookmarks files. So you may also wish to keep your backup "confidential" for that reason.
We have lots of reasons to be confident in the encryption and protocols that we use. If you have a well chosen Master Password, then your encrypted data will remain encrypted.
You raise a good point about educating people about master passwords, but we also have to recognize that many people will have weaker master passwords for their data on their phones than they will for their desktops. (I know that I do). The master password that I have for my 1Password data stored on Dropbox is a real pain to type on an iPhone keyboard.
Thus, if someone got hold of my computer, they would have a much better chance attacking the master password in my 1Password backup from my phone than they would going after the master password for my desktop 1Password master password.
Thanks! This is what I do as well. Indeed, I have the four digit unlock code set to "lock when inactive". I know other people who use the opposite, they set the unlock code for very long (basically they don't use it), but use a shorter time for master password.
We certainly pay attention to what others are doing. I think you will find that we are as serious about encryption as anyone, but you need to read delve into our background documents. I am hopeful that the more you read about how things actually operate under the hood and about our design decisions, the more pleased you will be.
This is not to say that there isn't room for improvement. The threat landscape is changing (particularly with more cloud storage and advances in password cracking techniques). So we are trying to anticipate new threats and adapt accordingly.
The security buzzword behind this is "defense in depth". Running a webserver on your phone carries its own risks, irrespective of what happens with your 1Password data. So we have always advised people to run that for as short a time as possible.
Indeed the security researcher Aaron Sigel discovered a potential problem with the configuration of the webserver behind our backup and restore mechanism. It didn't threaten 1Password data, but it could have been exploited as a small step toward getting phone configuration data off of the phone. This was about a year ago and we were quickly able to fix it. But we were pleased that we had already been advising people to keep the backup service not running for long.
This is part of a general principle to keep anything that could potentially be vulnerable open as little as possible. If we could be absolutely certain that every aspect of everything we and the operating system does is free from bugs then there would be no reason to follow this kind of "principle of least privileges" as part of "defense in depth". As it stands, it is very good practice.
So please don't take our recommendations that backup files or backup fetching mechanisms be limited to just when you need them as indications of problems with the encryption. Instead, this is just good practice.