Had to wipe all app data on Android after I restored a backup keychain on the Mac (incl. Dropbox)
Because of an mishap I had to go back to a backup of my keychain on the Mac. After Dropbox did its sync on the Mac, I got an error message on the Android side (Dropbox + 1Password there also). 1Password for Android told me that the "key" (internal encryption key?) had changed (I did not change the master password) and that I should reenter "it". As I did not find a way to do that, I had to wipe the complete data of 1Password on Android and let it sync again. Now everything is fine again.
(1Password for Android ver 4.0.0.b8)
Comments
-
If you can answer the following questions for me, I may be able to better diagnose the issue:
- What version of 1Password are you using on your Mac?
- Do you have any other versions of 1Password on any other devices (other than the two you've mentioned) syncing with this same keychain?
- What steps did you take to restore the backup of your keychain?
Thanks in advance!
0 -
ad 1. 4.1.2 from the App Store
ad 2. Other Mac, also uses 4.1.2
ad 3. Deleted Keychain from Dropbox (otherwise the merge feature of 1Password after switching on the Dropbox sync again would give me some half-backed results), then used the restore function of 1Password, then switched Dropbox sync on again in 1 Password. 1Password then copied all it's data to Dropbox which syncs it to the cloud.BTW: is there a reason for your two step approach of an internal keychain file and a copy in Dropbox? Plus caches probably. I think it is a weak point. Just had to completely remove 1Password from the other Mac and reinstall form App Store because it would not recognize the restored and synced keychain from the mishap on the other Mac. The changes made it to the keychain folder inside the Dropbox folder, but 1Password would not see them.
0 -
Hi @boboAgile!
Thanks for answering mverde’s questions. It sounds like regenerating the data file fixed the issue. :)
The reason why we store your keychain internally is because 1Password 4’s data format is much different from the agilekeychain format. Your 1Password 4 data file is stored with a much more secure encryption. This approach allows us to not have full dependency on Dropbox or iCloud. It also makes the experience of switching between sync services and vaults much easier and smoother.
Next time you have any problems with syncing on your Mac, please send us a diagnostic report by downloading the 1Password Troubleshooting utility and follow the instructions to generate the report. Then attach the entire file to an email to us: support+androidbeta@ agilebits .com We would be happy to take a look into the problem.
Let me know if you have any other questions.
0 -
Hmm, "fixed the issue" does not exactly describe my feelings about it. I had to do a clean-up procedure for every other Mac also because 1Password would not recognize the restored keychain. Instead it showed the local one (or something).
"Your 1Password 4 data file is stored with a much more secure encryption." Does that mean the Agilekeychain stored in the cloud is less secure than the internal/local one? Hopefully not.
Please clarify.
0 -
I'm sorry for the confusion that all of this caused. And you are correct that we do need to make things smoother when data is changed.
If I correctly understand you, you have hit upon a bug in the 1Password Android beta. It should have handled the situation better.
But first let me explain what did happen and why. Mostly because I like explaining this sort of stuff, but I'm also hoping that people will put up with some of my overly long answers to questions that come up around this matter.
Local versus synch formats
The file formats that are well designed for synchronization are not the best for "live" usage. This is one of the big, under-the-hood, changes in 1Password 4. We use an efficient, native database, for each particular app and then use either the Agile Keychain Format or the 1Password 4 Cloud Keychain Format for synching. Prior to 1Password 4 on the desktops, 1Password used the Agile Keychain format both as its local data store and for synching. So there is a sense in which 1Password 4 treats the 1Password.agilekeychain data as "external".
Under normal operation, people using 1Password need neither know nor care about those sorts of internal details. But when something does go wrong, then these things can be very surprising. We do need to find ways to make this easier.
Master Passwords and random keys
That was the simple part. That whole "local" versus "synch" data distinction then interacts with some other things, in particular the relationship between your Master Password and the encryption keys.
When you create a new keychain (whether a "local" one, an Agile Keychain or a 1Password 4 Cloud Keychain Format keychain), 1Password generates a set of truly random number to be your encryption keys. Let's pretend that there is a single "master key" (things are actually more complicated that this) in a keychain. 1Password encrypts that master key with your Master Password (and even that is a multistep process).
Now for synching, 1Password will store the master key for your Agile Keychain within its local store. This way, 1Password will be able to import and export items and changes from its local data to the Agile Keychain. Note that once this has been set up, 1Password no longer needs the Master Password of the Agile Keychain for synching. It already has the master key for that data.
Note that the master key for the local format and the master key in the 1Password.agilekeychain cannot be the same random number, as we've changed many details of the encryption. In the Agile Keychain Format there are two 128-bit keys that are used. In local data with 1Password 4 there are 4 256-bit keys.
Here's what happened
What happened in your case is that you created an entirely new Agile Keychain. When you did that another master key was created for it. 1Password for Android found that the master key it had for your Agile Keychain no longer worked.
What 1Password for Android should have done here is prompt you for your Master Password again so that it could decrypt the master key in the new Agile Keychain.
So I'm sorry that you had to go through this. As you see now the underlying system is far more complicated than it superficially appears. We need to improve things for users when something goes awry at those levels.
Further reading
Details of the relationship between Master Password and keys in the new data format are in the keychain design document.
Some discussion of the local versus sync formats is in the new data format rollout document.
0 -
Thanks for explaining. This sounds like a fragile design although I understand the reasons.
Please note that I had problems with 1Password for Android Beta but also with 1Password on the Mac (see above). Basically I had to completely wipe 1Password and its data (~/Library/Containers/...) on my other Macs because they would not recognize the changes in the restored keychain on the first Mac (Dropbox had completed its sync, the files in Dropbox on all sides had been up to date).
What I also do not understand: I did not create an entirely new keychain on the first Mac but instead I restored one from the local backup (with the help of 1Password). Shouldn't that backup copy also use the original master key?
0 -
Hmm. It seems like I misunderstood the sequence of events (I should learn to read more carefully.)
I wouldn't call our design "fragile", but there are lots of moving parts, and when things don't quite run as expected there can be surprising results. (OK, maybe that does count as "fragile".) The complexities of the design are actually needed to make the system more robust and secure. There as, as you note, good reasons for what we do.
I did not create an entirely new keychain on the first Mac but instead I restored one from the local backup (with the help of 1Password). Shouldn't that backup copy also use the original master key?
That is correct. That would have the same master key, but that is the master key in the local format. When you then set up Dropbox synching from that system, you did create a new 1Password.agilekeychain.
The new 1Password.agilekeychain would have the same master key as the restored local format; it would have its own unique set of keys that had never been used before. As I mentioned in the previous comment, the local format uses different kinds of keys than the Agile Keychain Format; so there is no way that they could share keys even if we wanted them to.
We do have a "known" problem with coordinating Master Password changes and master keys when synching. You got hit by this problem particularly badly. Obviously we are working on ways to resolve this problem, but I can't promise at this point when the solution will appear or exactly what it will look like. Every time, I think "well the only way we could do such-and-such is X, which won't be very pleasant for users" Roustem invents a brilliant approach that would have never occurred to me.
0
