Features Request: Emergency Safety Password

Henry Y.

Here's a request that I haven't seen brought up before.



How about letting us setup an emergency password to be used under duress (especially important on portable devices like iPhone & Android).



Entering this false emergency password can either wipe the Agile keychain & sync settings from the device or replace all the displayed passwords with false data.



Imagine if you were being held at gunpoint and being forced to provide your Master Password. In this scenario you could:



1) Give them your real Master Password and lose everything

2) Give them Emergency Password #1, which completely destroys the Agile Keychain & Sync settings on the device (You should still have a backup on your home computer right?)

3) Give them Emergency Password #2, which will repopulate all your password fields w/ false data giving you time to get away.



Just a thought.

Penelope Pitstop

Henry, your post reminded me of [url="http://xkcd.com/538/"]this amusing cartoon[/url]. <img src='http://forum.agilebits.com/public/style_emoticons/<#EMO_DIR#>/emoticon-0136-giggle.gif' class='bbc_emoticon' alt='(giggle)' />

jhollington

Part of me thinks that if you're storing data so sensitive that somebody is likely to hold you at gunpoint to get at it, then perhaps you have bigger problems than 1Password is able to solve for you. Hiring a guy with a name like "bullet tooth Tony" to hang out with you might be a more practical solution <img src='http://forum.agilebits.com/public/style_emoticons/<#EMO_DIR#>/smile.png' class='bbc_emoticon' alt=':)' />



Then again, perhaps we're looking at a whole new generation of mugger.... "Give me all your money" has now been replaced with "Give me all your passwords." <img src='http://forum.agilebits.com/public/style_emoticons/<#EMO_DIR#>/smile.png' class='bbc_emoticon' alt=':)' />



Of course, option #2 would probably result in the attacker shooting you [i]anyway.[/i]

Henry Y.

Okay, Option #2 might not be wise, but Option #3 would definitely offer a clear benefit. Even TrueCrypt offers plausible deniability with a hidden volume. It's not too much of a stretch to extend the current "Demo" password feature to allow us to customize one where if, say you're being subpoenad for your password, you could provide the false password instead.

face

I totally agree with Henry Yeh. I was thinking about the same solution adopted by TrueCrypt.

Please extending the actual Demo option feature: demo password should really be replaced with a password chosen by user populating 1P with own false non sensitive data.

thightower

[quote name='face' timestamp='1355261033' post='64880']

I totally agree with Henry Yeh. I was thinking about the same solution adopted by TrueCrypt.

Please extending the actual Demo option feature: demo password should really be replaced with a password chosen by user populating 1P with own false non sensitive data.

[/quote]



I read this earlier and couldn't get free enough to bring up the demo thing as you guys have mentioned. Glad you guys took care of it. <img src='http://forum.agilebits.com/public/style_emoticons/<#EMO_DIR#>/smile.png' class='bbc_emoticon' alt=':)' />



I have to agree with Henry its not that far of a stretch. Heck you can still use it to demo 1P just let the user set the demo password. Not sure I would use it but hey its an option.

face

Yes it should be simple to implement, but, please, if possible allow also user to insert fake data for that option ...

khad

I moved this to the lounge since it seemed more appropriate here since it isn't necessarily related to a specific version of 1Password on a specific platform.



I'm wrapping up about 12 hours right now but we should be able to give a more satisfying reply soon. <img src='http://forum.agilebits.com/public/style_emoticons/<#EMO_DIR#>/smile.png' class='bbc_emoticon' alt=':)' />

jpgoldberg

I find this sort of stuff really fun to think about, but of course, as others have mentioned, if this sort of thing is a realistic threat, then you have problems that I really don't think I can help with.



Technically, it wouldn't be too hard to redesign our data format to do this. There is a random "master key" that is encrypted with your Master Password, and that key is used to decrypt actual data. What we could do is have two encrypted master keys stored, one for real data and one for fake data. When a master password is entered, it will be tried against the real encrypted master key and if it fails there, it will be tried against the fake one. Some items would be encrypted under the real key and others under the fake key, and then 1Password would display only those that it can decrypt.



So while we could, in principle, modify 1Password in such a way, it still wouldn't provide the security needed against such a threat if the attacker does their homework. 1Password's data format is publicly documented (and even if it weren't it could be reverse engineered). And so an attacker could see that only a portion of all items are actually getting decrypted as well as see that different items are encrypted under different "master keys" even if they have no way to figure out what those keys are.



So this sort of defense might work against an unsophisticated attacker (e.g., "I'm your father, and you should have no secrets from me, son. What is in that "1Password" thing you use?") But a motivated attacker (and I consider anyone holding a gun to your head to be motivated) would consult with someone who would know about this feature.



So as I said, it is fun to think about how we could pull this off. (I love thinking about things like this which makes my job so great.) But very narrow range of situations in which this could actually be useful is exceedingly small (coercion from someone who doesn't bother to learn whether 1Password has such a feature).



Cheers,



-j

Henry Y.

I was more concerned about people being "compelled to give up their Master Passwords" as in the cases involving TrueCrypt. For example, "[color=#000000][font=sans-serif][size=3]In July 2008, several TrueCrypt-secured hard drives were seized from a Brazilian banker [/size][/font][/color][url="http://en.wikipedia.org/wiki/Daniel_Dantas"]Daniel Dantas[/url][color=#000000][font=sans-serif][size=3], who was suspected of financial crimes. The Brazilian National Institute of Criminology (INC) tried unsuccessfully for five months to obtain access to his files on the TrueCrypt-protected disks. They enlisted the help of the [/size][/font][/color][url="http://en.wikipedia.org/wiki/FBI"]FBI[/url][color=#000000][font=sans-serif][size=3], who used [/size][/font][/color][url="http://en.wikipedia.org/wiki/Dictionary_attack"]dictionary attacks[/url][color=#000000][font=sans-serif][size=3] against Dantas' disks for over 12 months, but were still unable to decrypt them.[/size][/font][/color][sup][url="http://en.wikipedia.org/wiki/True_Crypt#cite_note-Dantas-55"][55][/url][/sup][color=#000000][font=sans-serif][size=3] The case presented a noteworthy real-world test which proved the strength of TrueCrypt." The law here is exceedingly in favor of making it legal to force people to give up their passwords. There needs to be some sort of defense against this.[/size][/font][/color]

Penelope Pitstop

This is a very interesting thread. However this is really about the ethics/principles/legal position over privacy. As Jeff says, it is fascinating to discuss but the reality is that we aren't all governed by the same laws. It's very hard to design a product for every market where different laws apply.

tatchley

I second this addition. With most, if not all of the passwords being random, the attacker wouldn't know the difference. All he would see is he has purportedly gained access to the victims files. If an attacker ignorant of 1P asked for something more general, like your online banking info, which you do not know since you use 1P, you could explain that and give him the fake password, and the USB we all carry around with our data file. He would be satisfied thinking he hit the jackpot, when really, that's not the case.

benfdc

The amount of effort that it would take to make a fake password collection look real strikes me as unrealistic.



Wiping the data off of your device won't really help either. No matter whether you are using Dropbox Sync, iCloud Sync, or just backing up your device to iTunes, your assailant could force you to retrieve the info.

jhollington

[quote name='benfdc' timestamp='1355506611' post='65276']The amount of effort that it would take to make a fake password collection look real strikes me as unrealistic.[/quote]



That's actually not really true if you were simply concerned about ensuring the [i]passwords[/i] didn't work. You can easily use [i]real[/i] data with [i]fake[/i] passwords. Let's face it, if you're using 1Password properly, every password should be randomly generated anyway, so one pile of random gibberish looks the same as any other pile of random gibberish <img src='http://forum.agilebits.com/public/style_emoticons/<#EMO_DIR#>/smile.png' class='bbc_emoticon' alt=':)' />



Realistically, however, I think that this is a solution to a problem that virtually nobody actually has. It's a "geek-chic" kind of feature that probably has very little practical, real-world application -- at least right now.



I think Agile has a pretty good approach overall, generally avoiding "security theatre" features in 1Password.

Henry Y.

I can think of a realistic scenario where this would be extremely useful for security and data privacy.



Say, you are a member of Anonymous and arrested by the FBI.



All the incriminating evidence against you are stored in encrypted volumes, and your encryption keys are stored in 1Password.



The court orders you jailed in contempt of the court until you release your encryption keys to the court (of course doing so would incriminate yourself due to the release of evidence stored on the encrypted volumes).



In this scenario, you could release the false Master Password to the court. Just because they won't unlock the encrypted volumes isn't your problem. You could plausibly deny that there are any other passwords if structure of the Agile Keychain is changed so as to make such a scenario possible.

jhollington

That would be an interesting test of the judicial system, but I still think it's a hacker fantasy when it comes right down to it.



The FBI has people who know their stuff well enough to realize that 1Password would have such a backdoor in it, and therefore could easily assume that you did exactly that by not providing the "real" Master Password for your data. How far that would hold up in an investigation or the furtherance of the contempt order is open to debate, of course, but the bottom line is that any such security feature that is advertised in a commercial product is going to be common knowledge ("Your honor, I present as exhibit A, the documentation for the 1Password Password Manager...." <img src='http://forum.agilebits.com/public/style_emoticons/<#EMO_DIR#>/smile.png' class='bbc_emoticon' alt=':)' /> ).



I suspect most real hackers use proprietary solutions that they've rolled themselves for this very reason, and I know that government/military organizations most definitely do.

Henry Y.

That's where the plausible deniability comes in. TrueCrypt has the same feature. As long as the FBI can't prove that you have this feature turned on and enabled, there's not much they can do about it.

khad

But the kinds of attackers this is most useful for are [i]aware[/i] of these kinds of features and wouldn't care how "plausible" your deniability was. <img src='http://forum.agilebits.com/public/style_emoticons/<#EMO_DIR#>/wink.png' class='bbc_emoticon' alt=';)' />

Henry Y.

Just because the feature is known doesn't mean it's not plausible. http://en.wikipedia.org/wiki/TrueCrypt#Plausible_deniability

jhollington

I'm honestly curious to see a case like this actually tested in court someday, since thus far it's all speculation as to how it would go down, and most of it still seems like hacker nerd dreams to me <img src='http://forum.agilebits.com/public/style_emoticons/<#EMO_DIR#>/smile.png' class='bbc_emoticon' alt=':)' />



The closest equivalent would be handing out the wrong key to a lockbox. Of course, that's not really the same issue, since lockboxes are much easier to get into without a key than high-level encryption systems are.

Henry Y.

It's testing in court all the time, this is why I am requesting this feature.

[url="http://www.theregister.co.uk/2012/03/01/forced_decryption_ruling_moot/"]http://www.theregist...on_ruling_moot/

http://news.techworld.com/security/111731/laptop-user-ordered-to-hand-over-encryption-key/[/url]

Many more. I search for "court refuse to hand over encryption keys contempt".

jhollington

[quote name='Henry Yeh' timestamp='1355522068' post='65334']Just because the feature is known doesn't mean it's not plausible. [url="http://en.wikipedia.org/wiki/TrueCrypt#Plausible_deniability"]http://en.wikipedia....ble_deniability[/url][/quote]

That's a completely different issue, since you're denying the existence of something entirely, as opposed to handing out incorrect information that you fully know doesn't work.



If the perpetrator thinks they've found what they're looking for, then they'll stop looking. If they can't get into what they're looking for, they aren't going to stop, and they're going to continue trying to beat it out of you regardless of how much you shrug your shoulders and innocently pretend to have no idea why those passwords didn't work.

Henry Y.

This is a good one: [url="http://www.techdirt.com/articles/20091128/1803197100.shtml"]http://www.techdirt....803197100.shtml[/url]



I view them as the same thing, if everything is encrypted properly, there's no way they can prove that you're handing them incorrect information.



If someone saw an encrypted TrueCrypt volume on your drive, but you handed them the key to the key to a "plausible deniability" volume, there's no way they can prove you handed them the false key.

jhollington

[quote]It's testing in court all the time, this is why I am requesting this feature. Many more. I search for "court refuse to hand over encryption keys contempt".[/quote]



That's a different test. Refusal to hand over keys differs from handing over the [i]wrong[/i] keys. In some jurisdictions, the latter could be considered an even bigger offense, since it's one thing to withhold information, especially under certain perceived rights. It's another to [i]lie[/i] to the court.

jhollington

[quote name='Henry Yeh' timestamp='1355522518' post='65343']I view them as the same thing, if everything is encrypted properly, there's no way they can prove that you're handing them incorrect information.



If someone saw an encrypted TrueCrypt volume on your drive, but you handed them the key to the key to a "plausible deniability" volume, there's no way they can prove you handed them the false key.[/quote]



That's very likely true, but from a 1Password point of view, that requires you to actually maintain two separate data stores entirely, rather than just have an emergency password that returns invalid passwords.

benfdc

[quote name='jhollington' timestamp='1355507002' post='65277']

You can easily use [i]real[/i] data with [i]fake[/i] passwords. Let's face it, if you're using 1Password properly, every password should be randomly generated anyway, so one pile of random gibberish looks the same as any other pile of random gibberish <img src='http://forum.agilebits.com/public/style_emoticons/<#EMO_DIR#>/smile.png' class='bbc_emoticon' alt=':)' />

[/quote]



You seem to be suggesting that my situation has somehow improved if I can get 1P to supply an attacker with all of my login accounts and usernames but a bunch of bad passwords. It seems to me that this is the worst of all worlds—I've both surrendered valuable information (now my adversary knows exactly what to look for) and made a transparent effort to slow him or her down.

jpgoldberg

Henry,



In the situation where a government agency is demanding an encryption key, then the kinds of things that we could plausibly implement in 1Password would be ineffective. The existence of duplicate records would be apparent to anyone working with your data.



The idea that we would just have to decrypt the "passwords" parts of records differently wouldn't fly for a number of reasons. Some have been mentioned above, but additionally note that the contents of an item is encrypted as one chunk of data. Sure the decrypted stuff is highly structured, but if just the password material within it were different, the entire item would need to be re-encrypted.



Although it is theoretically possible encrypt data with the property you require (where it is undetectable that there there is additional data that has not been decrypted) it requires the use of a one time pad (OTP). This means that you need to have a completely random (not pseudo random) pad that is at least as long as the data. You will need a second, false pad, to yield the false decryption. Furthermore you could never ever use the same pad on different data. If you modified your data, you would have to encrypt it with an entirely new pad.



If your goal is to trick, say, a family member or a coworker who won't put any effort into seeing whether they have been tricked, then it would be possible to modify 1Password in a way that might be able to pull that off. But I am doubtful it would be worth redesigning our systems so much and adding so much complexity just to pull off a trick that won't withstand serious inspection.



If you want to be able to pull the same sort of false decryption trick on a Three Letter Agency (TLA), then you need a level of operational security (management of pads for OTP and devices and systems) that completely obviate the need for 1Password.



That is, if you are set up to be able to manage OTPs, then you don't need to be using 1Password in the first place. And remember, while true OTPs provide perfect security, systems that are very very similar to OTPs, but differ from them in what seem like minor ways often provide terrible security.



I am skeptical of any system, unless it uses a one time pad with all of the very severe limits and restrictions that come with that, that claims that it can provide a "false decryption" scheme that will fool a TLA.



Cheers,



-j

Henry Y.

Thanks for the response. I understand the difficulty in designing this in a secure way, and I agree it's probably not worth adding a feature that is only effective in tricking a family member or coworker.

jhollington

[quote name='benfdc' timestamp='1355757053' post='65713']You seem to be suggesting that my situation has somehow improved if I can get 1P to supply an attacker with all of my login accounts and usernames but a bunch of bad passwords. It seems to me that this is the worst of all worlds—I've both surrendered valuable information (now my adversary knows exactly what to look for) and made a transparent effort to slow him or her down.[/quote]



I don't disagree at all, which is one other reason (among several) that I consider the suggestion to be generally impractical in real-world scenarios.

Henry Y.

[quote name='jhollington' timestamp='1355765543' post='65725']

I don't disagree at all, which is one other reason (among several) that I consider the suggestion to be generally impractical in real-world scenarios.

[/quote]



I do disagree with this, as I believe that in a real-world scenario, the presence of such a feature would be able to let a person be released from prison rather be detained indefinitely for refusing to release encryption keys.

jhollington

[quote name='Henry Yeh' timestamp='1355765759' post='65726']I do disagree with this, as I believe that in a real-world scenario, the presence of such a feature would be able to let a person be released from prison rather be detained indefinitely for refusing to release encryption keys.[/quote]

Not if none of the passwords provided actually [i]worked [/i]<img src='http://forum.agilebits.com/public/style_emoticons/<#EMO_DIR#>/smile.png' class='bbc_emoticon' alt=':)' />



TrueCrypt-style plausible deniability is one thing -- let the user access a harmless "honeypot" rather than the real, secure data so that the investigator thinks they've found the "real" data. However, it's reasonable to assume that there would be services where the passwords simply wouldn't work at all, and I think the person of interest would have a hard time explaining why NONE of their passwords, worked, especially if this was a known feature in 1Password.



Lying is not the same as plausible deniability, and in most jurisdictions you merely have to provide a balance of probabilities, not concrete evidence. No working passwords in the user's 1Password vault, combined with the fact that the ability to unlock "fake" passwords is a published feature of 1Password would in the very least provide evidence of continued contempt of court, if not outright perjury if the information was given under oath.



As I said, I'd be curious to see it tested in court, since we have no idea how it would actually go down. I don't think it's a slam-dunk, however, and thus far all of the court tests have been about [i]withholding [/i]information, not about knowingly providing [i]false[/i] information.



As for protecting your information against criminals rather than the government, I think that [i]benfdc's[/i] point is correct that you're still providing too much information even without the actual passwords.