Anonymize data files
Hello,
1P is nice, but if I'm forced to reveal my master password, everything is made public.
I suggest some new features, all of them to be activated on request.
- never save in history previously opened password archives or, better, let the user specify on opening, whether a pass archive should be kept in the history or not (default: not, since that option has to be specified only once for the archives kept in history)
- flat binary file without predefined extension, to avoid showing the presence of a 1P archive
- random file header, otherwise detecting the presence of the archive is possible
- position of the file free, not limited to specific folders (this means, such feature is not possible with Mac App Store version)
- sync only on request (dropbox is fine, usb preferred) since the user has to do the process manually, also on mobile
- appropriate changes to 1P extension for the browser
This way, people can keep one "standard" archive in the history with a limited set of passwords and also keep a second one with password and other infos (these are the real things to protect) somewhere else, without anyone being sure that such file exists.
Additional secondary feature, to keep the "standard" archive plausible: inside the secret archive, specify the path of a "standard" archive (the pass would be saved as normal pass inside the ghost one) and then also offer a checkbox for the passwords that has to be kept on sync on both archives. This way, some password would be modified automatically also on the standard archive that would show some activity.
Comments
-
Hi @omar,
You correctly point out that 1Password does nothing to conceal the fact that you have 1Password data. It is an extremely difficult thing to achieve.
I love thinking about such things and what could be done, but there are a number of reasons why I don't think it it is something we will pursue (though we are "Agile" so anything is possible.)
Really hard to do right
Consider the case of TrueCrypt (a disk encryption system). It goes to extraordinary efforts to allow you to conceal the fact that you have TrueCrypt data, and yet it still fails to do that. So even for tools that have that as a major design goal and have been working intensively at it for years have not succeeded. I don't see us doing any better unless we were to turn full attention to just that specific problem.
Right tool for the right job
Also if you need to conceal the fact that you have 1Password data, then there is probably other data and activity that you need to conceal the existence of. So a more general solution to that problem may be better than trying to build in such functionality into each and every application. Instead you would want something that conceals the existence of a broad range of data.
So let 1Password do its job, and use a special purpose concealing system.
Contradictory threat model
The sorts of things you are asking about are to defend against a very peculiar Adversary.
The Adversary would have to be powerful enough to compel you to reveal some secrets, but not powerful enough to compel you to reveal all secrets.
If all you are after is "plausible deniability" just claim that you have forgotten your Master Password. So you are looking at genuinely being able to persuade the Adversary that you have revealed all of your secrets when you have not.
An adversary who is in a position to compel you to reveal secrets is likely to have independent mechanisms to know whether you have revealed all. Consider that you have passwords for a dozen super secret sites and services that you don't want to reveal. You try to conceal that you have any such logins. But if the Adversary who is trying to get those secrets out of you may have already compromised some of those sites. So the Adversary, through other compromises or informants, will probably know whether you are coming clean or not.
The Adversary would have to be sophisticated enough to to be a threat to "normal" encrypted data, but not sufficiently sophisticated to know that you may have "hidden" data.
The Adversary would have to be able to compel you to reveal the fake data, but not powerful enough to scare you into revealing the real data.
Over all, I think that the chances of meeting an Adversary who has exactly the right combination of power/weakness, information/ignorance, and sophistication/cluelessness is so rare as to not be worth putting serious effort into defending against.
Still fun to think about
I do love thinking about these sorts of things and what would be required to make it work. It also helps clarify what sorts of threats 1Password doesn't defend against. In particular 1Password does not defend against rubber-hose cryptanalysis. Let's hope it never has to.
-j
–-
Jeffrey Goldberg
Chief Defender Against the Dark Arts @ AgileBits
http://agilebits.com0 -
In what does Truecrypt fail in protecting the data? I never heard of it. If you refer to the fact that not all bytes are written equally often, I think it's a problem a magnitude smaller, but I understand your other points.
0 -
Here is a good starting point:
0 -
TrueCrypt does an excellent job at protecting data. But it does do an imperfect job of concealing that it is in fact being used to protect data. As you can see in the link @khad provided, the TrueCrypt are aware of these difficulties and try to advise people on the limitations and on what additional precautions people should take.
At any rate, my point was that it takes enormous development to get to a tool that conceals its own use on a standard computer. It also requires extreme discipline from the the user. Even if you consider TrueCrypt to be entirely successful at that task, I'm sure you recognize that it goes to great length in working toward that goal. I certainly wish the TrueCrypt developers and users well in their endeavor.
0
