Thoughts and ideas on the Quick Unlock Code

brain_death

i use 1pw around 30-50 times a day. and the new masterpw feature is a total pain in the ass in the new 1pw 4 app ...



please change it back to the way it was. or at least provide this option !!! it is unusable for me this way <img src='http://forum.agilebits.com/public/style_emoticons/<#EMO_DIR#>/sad.png' class='bbc_emoticon' alt=':(' /> it always requires the masterpw for logins with LOW security !



what i mean is: quickpw ONLY when starting the app (with auto lock option) and a seperate masterpw requirement for logins you want secure more ... it was so much better that way



pls <img src='http://forum.agilebits.com/public/style_emoticons/<#EMO_DIR#>/sad.png' class='bbc_emoticon' alt=':(' />(;

brain_death

i DO LOVE 1pw! but it is so crucial for me that you change or add this old behaviour option. 1pw4 is absolutly UNUSABLE for me this way since my masterpw is very long and secured with special characters and if it won't change soon i will demand a full refund <img src='http://forum.agilebits.com/public/style_emoticons/<#EMO_DIR#>/sad.png' class='bbc_emoticon' alt=':(' />

jhollington

The use of the [i]actual[/i] Master Password provides significantly more security and much less complexity than the old way, so under the hood it's actually a good thing.



If you turn on the Quick Unlock Code in settings, with [b][i]Lock on Exit [/i][/b]enabled and [b][i]Auto-Lock[/i][/b] set to "Never" this should result in the app prompting you for the Quick Unlock Code most of the time when returning to the app -- the Quick Unlock Code will be used as long as the app remains resident in the background, so you'll only need to enter the Master Password in this case if the app is terminated by iOS due to low RAM, you terminate it yourself from the multitasking tray, or you reboot your device.



I too use a very long and complex Master Password (40 random characters), but find this option to actually be quite acceptable (and I've been running 1Password 4 this way for a couple of weeks now).

judegreer

Add my name to this request. I have a super secure password on my master database, and a somewhat easier password on my iOS devices. The removal of this feature is a critical omission in my opinion. Please please allow the old quick PW behavior!

jhollington

For what it's worth, I railed against this new "Master Password" approach after discovering it in the Android version (see http://forum.agilebits.com/index.php?/topic/8534-1password-ignores-protection-settings/ ).



However, I've now been using it in the new iOS app for a couple of weeks and I'm pleasantly surprised how non-invasive it actually is as long as you keep the Quick Unlock Code properly enabled (as described above).

tseager

I'll be the devil's advocate here. I loathed the quick password on the phone. 90% of the time, I needed a password, and hated having to enter the quick password. An option to turn it off would have sufficed. Never asks me on the iPad version.



Perhaps I've missed the point of the quick password, but seeing a list of available data, without being able to get into it, was meaningless to me.

CurbedEnthusiasm

I'll never upgrade to 1P4 with this MP change in place. Hate it, Agile.

Carl

[quote name='brain_death' timestamp='1355390099' post='64974']

i use 1pw around 30-50 times a day. and the new masterpw feature is a total pain in the ass in the new 1pw 4 app ...



please change it back to the way it was. or at least provide this option !!! it is unusable for me this way <img src='http://forum.agilebits.com/public/style_emoticons/<#EMO_DIR#>/sad.png' class='bbc_emoticon' alt=':(' /> it always requires the masterpw for logins with LOW security !



what i mean is: quickpw ONLY when starting the app (with auto lock option) and a seperate masterpw requirement for logins you want secure more ... it was so much better that way



pls <img src='http://forum.agilebits.com/public/style_emoticons/<#EMO_DIR#>/sad.png' class='bbc_emoticon' alt=':(' />(;

[/quote]



Personally, I prefer the new way.



Pin + master password was always a pain my opinion.

jhollington

It's also worth noting that items protected by the low-security PIN in 1Password 3 were quite insecure against brute-force attacks should anybody have gotten their hands on your iOS 1Password data file -- something that would be trivially easy to do with rudimentary jailbreak tools.



The high security password improved this somewhat for those items, but was still dependent upon the complexity of that password -- many users didn't necessarily use a long one there because they felt they already had a PIN on the front door.



This doesn't even include the fact that if you were using Dropbox syncing, the actual full Master Password was stored in the iOS Keychain. Hard to access from there as long as you're using a device passcode, but still theoretically possible and somewhat dependent on the strength of your device passcode.



1Password 4 fixes all of this by enforcing use of the higher security Master Password and no longer needing to store it on the device.



So, for a bit of inconvenience, you get a *much* more secure solution. Seems like a fair trade off to me, especially when you consider that Master Passwords don't have to be ridiculously long and complex in order to be secure.

brain_death

@jhollington: your workaround seems ok. NEVER THE LESS, the new behaviours renders the option in 1pw for mac, to set a specific login as "highly secured" or not, useless.



i am not demanding to throw the whole new concept over board. i just would like to have the OPTION to use it the old way. couldn't be that hard. and in this case everybody can decidve for him/herself which way works best form him/her.



but what i absolutly hate are developers who think the new way is soooo much better but it's not ... and you are forced to use it like they THINK it's better. dafuq? that's why there are donuts with or without filling. customer decides.

khad

You're not the first we've heard this from. One of our goals with 1Password 4 was to make strong security the default. The old PIN code had the downside of being used to encrypt some items and with only 10,000 possibilities, this just wasn't good enough for us to continue with. We did away with that approach in the first iPad version as well. The PIN code was originally conceived as a convenience feature for frequently accessed items in the time before iPhone OS supported fast app switching and background tasks. It was a compromise we were never happy with, but it provided the best balance of security and user experience at the time. We do still have the unlock code available in settings, but it is only used to control access to the 1Password application, never for encryption of any of your data.



I hope that clarifies the decision a bit. If you have other thoughts or ideas, don't hesitate to let me know.

brain_death

let me first thank you for your reponse!



well, i do understand the security concerns. e.g. i did not know that the short pw back in version 3 was not for encryption. so the steps you made for version 4 are now clear to me!



jhollington's workaround works nicely so far. but maybe i will rethink my master pw to one thats a liiiittle bit more easy to input through the iphones keyboard. because, as i said i am forced to use the 1pw app around 50 times a day (!) and the quick pw was just comfortable. but never the less, security is crucial <img src='http://forum.agilebits.com/public/style_emoticons/<#EMO_DIR#>/wink.png' class='bbc_emoticon' alt=';)' />



another question: would a gesture based unlock code like on anroid phones be an alternative to the 4-digit quick pw?

jhollington

[quote name='brain_death' timestamp='1355472168' post='65177']your workaround seems ok. NEVER THE LESS, the new behaviours renders the option in 1pw for mac, to set a specific login as "highly secured" or not, useless.[/quote]



Actually, the way to look at it is that this option is no longer even relevant. In 1Password 4, [i]every[/i] item is "highly secured" by definition in that it uses the same level of security as the desktop version. "Highly secured" added nothing extra in 1Password for Mac, and now it's the same in 1Password 4 for iOS.



As Khad pointed out, the old PIN code was a very [i]low[/i] security option, which necessitated the need to [i]add[/i] higher security for users who were concerned about protecting their items with something more than a four-digit PIN code that could have been cracked in a few hours using the raw iPhone data files. Obviously, if you're only using a four-digit PIN code for your [i]real[/i] Master Password, you're not better off, but most people use an actual Master Password that is more secure than even the old iOS "high security" password, so you're actually far better off with 1Password 4 in this case.



To look at it another way: 1Password 3.x actually provided two [i]lower[/i] security levels as compared to the desktop version. 1Password 4 brings the security up to the same level.



[quote name='brain_death' timestamp='1355486515' post='65226']jhollington's workaround works nicely so far. but maybe i will rethink my master pw to one thats a liiiittle bit more easy to input through the iphones keyboard. because, as i said i am forced to use the 1pw app around 50 times a day (!) and the quick pw was just comfortable. but never the less, security is crucial[/quote]



The Quick Unlock Code is actually pretty secure as you only get [u][i]one[/i][/u] attempt to enter it before 1Password reverts back to requiring the Master Password. Even educated [i]guessing[/i] isn't going to be an option here. Plus, as soon as 1Password shuts down or you reboot the device, you're also back to requiring the Master Password.

brain_death

[quote name='jhollington' timestamp='1355487361' post='65227']

The Quick Unlock Code is actually pretty secure as you only get [u][i]one[/i][/u] attempt to enter it before 1Password reverts back to requiring the Master Password.[/quote]

<img src='http://forum.agilebits.com/public/style_emoticons/<#EMO_DIR#>/ohmy.png' class='bbc_emoticon' alt=':o' /> did not know that! cool!



well it that case ... with your workaround ... i am quite happy <img src='http://forum.agilebits.com/public/style_emoticons/<#EMO_DIR#>/smile.png' class='bbc_emoticon' alt=':)' />

benfdc

I just loaded 1P4 onto my iPhone, and I see that 1P3 is still there as well. I'm wondering whether keeping both of them on my iPhone indefinitely would remain an option, so that I always have a choice of how I access my data.



This would be similar to how I run 1P/Mac—I use version 3.9 on an everyday basis, but every now and then I close it and fire up 3.5 when I need a feature that Agile later dropped (such as [color=#282828][font=helvetica, arial, sans-serif]File > Export Selected > Encrypted Web Page or [/font][/color][color=#282828][font=helvetica, arial, sans-serif]File > Export All > Palm or Treo[/font][/color][color=#282828][font=helvetica, arial, sans-serif]).[/font][/color]

jhollington

As long as you're using Dropbox sync, it should certainly be an option, at least for now. As you've noted they're separate apps, and of course 1Password 3.x is still used on the desktop. Both apps will use their own separate data, but you can sync to a single 1Password file on Dropbox to keep them both up to date. 1Password 4 converts the data to a newer format, but this is during the Dropbox sync process -- the data in Dropbox has to be left in the 3.x format in order to communicate with 1Password on Mac/Windows.

judegreer

Well, with khad's reply explaining their motivation but not addresssing the actual request to have the feature added back in, I must assume that AgileBits has no intention of doing so, and will unfortunately have to request a refund from Apple. Sorry AgileBits, but this is unacceptable.

bobzef

jhollington,



Your posts are much appreciated and very enjoyable.



Can you speak further as to why Dropbox sync requires the master password be stored in the keychain? I understand there needs to be some cross authentication with Dropbox, but I thought Dropbox doesn't care about the contents of files and only worries about binary synchronization. It seems if that's the case then the data can be fully synchronized without any knowledge of the master password.



What am I missing?

jhollington

In 1Password 4, it doesn't, since 1Password 4 uses the [i]actual[/i] Master Password -- the same one that's used to encrypt your file on Dropbox and to open it from 1Password for Mac, Windows, or even directly using the 1PasswordAnywhere feature.



1Password 3.x required this, however, because it used a different password system to encrypt the data on the device -- two separate passwords, actually, the low-security PIN and high-security "master password" that was used solely on a given iOS device. In this case, Dropbox doesn't care about the content of the files, but 1Password 3.x does.



Basically, with 1Password 3.x, you needed to supply the [i]actual[/i] Master Password so that the iOS app could decrypt the data on its way down from Dropbox and then [i]re-encrypt[/i] it on the iOS device using the local low/high security password system. In theory, the actual Master Password didn't need to be permanently stored on the device, but the alternative would have been a requirement to key it in every time you wanted to perform a Dropbox sync, in which case you'd actually be using a system more complex than 1Password 4, requiring up to [i]three[/i] passwords to be involved.



There's a much more in-depth discussion of this issue that can be found over in this thread: http://forum.agilebits.com/index.php?/topic/10412-storage-of-master-password-on-ios-devices



Note that the Master Password that was stored on the device used the iOS keychain, which took advantage of the iOS data protection APIs. As long as you used a passcode lock on your device and encrypted your iTunes backups, it was very difficult to get at, but still theoretically possible. Plus, it was only as secure as the complexity of your passcode -- most users only use a four-digit PIN for this. With 1Password 4, the Master Password doesn't exist anywhere on the device at all -- even in the 1Password data files; the Master Password you enter is used to derive the decryption key, and therefore doesn't actually need to be [i]stored [/i]anywhere.

codinghack

This is a follow up from this twitter thread: [url="https://twitter.com/codinghack/status/282632922698223616"]https://twitter.com/...632922698223616[/url] and [url="https://twitter.com/codinghack/status/271332690647724032"]https://twitter.com/codinghack/status/271332690647724032[/url], where I was asked to post to this forum. Here is the short of it. I have two kinds of data:

* Data I really really care about (Want very high security)

* Data I care about (Happy with a 6 to 10 digit password, even current 4 digit is fine w/ me).



I don't like the idea of having to type in public my long password to unlock the data I care about. It takes too long and it's a risk if someone is watching.



The QUL feature was proposed as solution to me for this. My concern is if the data I really really care about is protected only by a 4 digit password. Even if it reverts to the master password after one failure, the implication is that 1password is holding a key in memory to unlock the remaining data I have. Assumedly that key has been encrypted w/ the weaker QUL password. Which implies that if someone gets a hold of my phone while 1password is running in the background, they can access the raw memory and decrypt the key (by guessing it since it's less secure) that allows someone to decrypt my entire list of passwords by simply cracking the shorter QUL password. In effect the QUL password becomes the weak link, if some gets a hold of my phone while it's running. Worse, the increased complication in the logic increases the chances that a bug existings in the code, perhaps leaving the key in memory longer then it should. Basically, not purging keys from memory when it should. Am I missing something?

bobzef

Thanks for that explanation and the link.

khad

Welcome to the forums, codinghack! It is great that you are thinking about these things.



I've passed your post along to our resident Defender Against the Dark Arts. As you might imagine, we're all trying to spend some time with our families for the holidays, so the response time may be delayed a bit more than it normally would be. However, we'll get you some more information as soon as possible.



In the meantime, I hope you are having a good holiday and spending time with the folks you love.



Cheers! <img src='http://forum.agilebits.com/public/style_emoticons/<#EMO_DIR#>/biggrin.png' class='bbc_emoticon' alt=':D' />

jpgoldberg

Hi codinghack,



You are absolutely correct that when your 1Password data is unlocked (but protected by the Quick Unlock Code) the decryption keys for the data in the program's memory. No matter what sorts of obfuscations we try, it isn't possible to guarantee that such data can't be extracted in the circumstances that you describe. The QUC is not about encrypting your data. It is about keeping access to your 1Password data "hard" under some very common circumstances. It does not present a defense against the particular attack you describe. Instead it defends against what we see of as much more common and likely attacks.



I'm not entirely sure what alternative you have in mind. You can simply set 1Password to fully lock on exit (which means throwing away its knowledge of decryption keys), but that does mean that you will need to enter your master password more often. As you correctly note, that adds some risks of shoulder surfers and of picking a poor master password.



Our "solution" to this is to let you be the judge of the various risks and allowing you to set autolocking settings make the security tradeoffs that you are most comfortable with. If we knew how to offer a solution that required no such trade offs we would have done so.



I, personally, am not particularly worried about the kind of attack that you mention at the moment. Of course the threat landscape will change, and it may do so in a way that makes such attacks more of a concern. But in the current environment I am happy to recommend use of the QUC for the overwhelming majority of 1Password users. Still, you do have the ability to adjust the trade offs to meet your needs.



I hope this help. Please let me know.



Cheers,



-j

codinghack

This is why I think you previously had a brilliant solution and why I am holding off upgrading to the latest version of 1password until you put it back or come up w/ a better solution. Have two passwords. One password that unlocks everything and another simpler for password for less critical items. If a 4 digit pin is too short, then I'll be happy w/ a 6 to 10 digit one. I don't need full encryption for a library pin, so why do I need to take on the risk of typing in my master password in public for it?

khad

One of our goals with 1Password 4 was to make strong security the default. The old PIN code had the downside of being used to encrypt some items and with only 10,000 possibilities, this just wasn't good enough for us to continue with. We did away with that approach in the first iPad version as well. The PIN code was originally conceived as a convenience feature for frequently accessed items in the time before iPhone OS supported fast app switching and background tasks. It was a compromise we were never happy with, but it provided the best balance of security and user experience at the time. We do still have the unlock code available in settings, but it is only used to control access to the 1Password application, never for encryption of any of your data.



I hope that clarifies the decision a bit. If you have other thoughts or ideas, don't hesitate to let us know.

codinghack

I understand that. What you have said, was previously stated in the original twitter thread and in this thread. If you could re-read my orignal post and jpgoldberg response and my last response it would be much appreciated. You didn't answer my question. I agree a 4 digit pin code is inappropriate for a bank account. But, it is not inappropriate for a library card pin or a voicemail password, especially if that pin was expanded to 6 or 8 digits. In addition, using the fully master password in public to get access to library card, increases the risk that my masterpassword will comprised (somebody watching) which means my critical data is comprised rather then just my less critical data. You should really consider adding this feature back.

khad

One of the design goals of 1Password is to make it easy to do the secure thing and difficult to do the insecure thing. Perhaps something like an opt-in Quick Unlock Code for certain items would work. In version 3, items created in iOS defaulted to low security so many users saved [b]all[/b] items as low security.



We always remain agile and greatly appreciate your feedback. It helps us greatly to know what users are looking for and how different folks use 1Password. We never say "never", and there is always room for improvement. We will see how we can best address your use case in the future.

Penelope Pitstop

I don't wish to invalidate codinghack's request for the return of a low security option (or anyone else that wants it) but I found the default to low security in 1PW3 for iOS irritating.



Personally I much prefer the new way and find the QUL a perfectly acceptable compromise when you have the timeouts set appropriately - particularly if you have an iOS device with quite a bit of RAM.



If you do decide to bring back multiple security tiers, please can you make sure it defaults to the higher security option?

codinghack

I agree that defaulting to the lower security is not a good idea. But, like the length of the pin, this is more of an issue with tuning the low security feature rather then saying the feature is bad. The ability to segregate high and low security items and allowing the low security items to be unlocked w/ a shorter/faster code enhances the security of the high security items. Again, please bring back with a slightly longer pin and default to high security when entering in new items.

khad

Thanks again for your continued feedback. Please keep it coming if you have more to share.

Chris100

Add me to the group that prefers the new system.



I waited for v4 before I switched my family to 1PW, because I knew they would not understand or care about the difference and simply use the simple code for everything.



Now that the master password is required, I am more comfortable with them using the iPhone version.