Touch ID changes in 5.1 [please see post #67 for latest information]
Comments
-
@bwoodruff: I respectfully disagree and I find this a very concerning attitude, not to mention that the comic is besides the point. What is and what isn't a security threat is largely dependent upon circumstances and susceptible to changed attitudes. I would make the assumption that with the growing popularity of Touch ID, this will be an avenue worth considering, if it isn't already. You don't want to protect your data from common exploits alone, but ideally against as many exploits as possible, without sacrificing usability too much. I've just outlined two fairly straightforward workarounds that might mitigate the risk while keeping a similar level of convenience. A product that is based on security should stay on the safe side if possible and don't rely on assumptions too much. When features are taken out because of an, at best, arguable proposition that a 'common thief' would not be interested in the average user's data, then perhaps 1Password just isn't the product for me anymore. As pointed out by Hessijames numerous times here, the feature was there before for a long time and taken out for, in my opinion, very questionable reasons. Likewise 1Password for Mac has numerous options to change the auto-lock behaviour that suits your needs.
Moreover, the story you posted is yet another reason why unrestricted use of Touch ID is problematic and it could have been completely avoided if the previous time-limit feature would still be there. It pretty much counters your own argument and demonstrates that some people can do stupid things occasionally, which is why the suggestion that the master password should be used, is not a serious one.
0 -
I respectfully disagree and I find this a very concerning attitude
We're allowed to disagree. Thanks for sharing your opinion.
not to mention that the comic is besides the point
Obviously I disagree.
What is and what isn't a security threat is largely dependent upon circumstances and susceptible to changed attitudes
Very true. There are a lot of factors. I'm implying that you should consider what yours are (and I'm talking to the larger audience here, not "you" specifically).
You don't want to protect your data from common exploits alone, but ideally against as many exploits as possible, without sacrificing usability too much.
The balance between security and convenience is always an important struggle, and you should choose the settings that best give you that balance for your unique situation.
When features are taken out because of an, at best, arguable proposition that a 'common thief' would not be interested in the average user's data,
That isn't why the feature was removed. It was removed because frankly it didn't work reliably and caused mass confusion.
then perhaps 1Password just isn't the product for me anymore
And that would be unfortunate, but it may be the case. Products evolve, personal situations evolve, and the product will never be the ideal product for every individual and every situation.
We certainly appreciate your feedback, and will continue to take it into consideration. We're not saying "no" but we are saying "not now." As iOS and 1Password continue to evolve, that may change.
Thanks.
0 -
+1 to original post
0 -
not to mention that the comic is besides the point
Obviously I disagree.
The point with the comic is that you are using a current deficiency of 1Password i. e. the missing of a plausible deniability functionality to justify another deficiency that was deliberately induced by 1Password development. I will leave the interpretation to which end this leads to the readers of the thread.
What is and what isn't a security threat is largely dependent upon circumstances and susceptible to changed attitudes
Very true. There are a lot of factors. I'm implying that you should consider what yours are (and I'm talking to the larger audience here, not "you" specifically).
Having infinite time to unlock the complete vault of 1Password is no individual consideration but one that all 1Password users should have who - like me - store sensitive information in your product. I am aware that there are also users misled by funky buttons or the ultimate convenience rather than objective security considerations which I learnt from the wi-fi sync discussion but AgileBits is in the responsibility to protect these users as well. This is especially the case since the expertise of the average 1Password user is below the one of your team. I may add that your business strongly dependant of the absence of any negative security press.
You don't want to protect your data from common exploits alone, but ideally against as many exploits as possible, without sacrificing usability too much.
The balance between security and convenience is always an important struggle, and you should choose the settings that best give you that balance for your unique situation.
bwoodruff, these exact settings have been removed. This is what this thread is about.
When features are taken out because of an, at best, arguable proposition that a 'common thief' would not be interested in the average user's data,
That isn't why the feature was removed. It was removed because frankly it didn't work reliably and caused mass confusion.
Maybe that is not the reason for the removal but this is your main argument why the removal did not cause any harm which I - to underline this important point - strongly challenge.
Discussing the reasons for the removal of the TouchID timeout is not easy because these changed during the thread. I will therefore try to discuss the current ones:
[...] it didn't work reliably [...]
It worked perfectly in 5.0. If this changed in a pre-5.1 build lowering the security was obviously the wrong decision.
[...] caused mass confusion
Risking another discussion loop let me emphasize that this is an issue which should have been dealt with without lowering security. @Remington even proposed a simple solution in posting #7 to counter the "confusion" and at the same time maintaining security which has not received more than 5 words of superficial attention of AgileBits.
then perhaps 1Password just isn't the product for me anymore
And that would be unfortunate, but it may be the case. Products evolve, personal situations evolve, and the product will never be the ideal product for every individual and every situation.
I might add that 1Password will not be the product for anyone storing sensitive information. This is not solely a result the TouchID issue but also a lesson from the statements in this thread clearly indicating the priority of bells and whistles (namely: The plugin introduced in 5.1) over security.
We actually reportedly had a customer who passed out drunk and had someone use their finger to unlock their phone:
Assuming that the customer didn't get drunk till he passed out in 15 minutes this incident would have been prevented by the TouchID timeout. I repeat: It is your responsibility to design your product to protect even the inexperienced.
There is also a technical reason we ran into that I haven't seen discussed yet (if it was, and I missed it in my quick scan of the thread, I apologize).
In this case, the extension should have been deferred rather than a security feature removed. Could you please get into detail here to allow us to understand your decision as well as - in the best case - propose a solution.
Patrick
0 -
Thanks for the feedback. I'll leave it to Chris to elaborate if appropriate on his comment.
0 -
I would like to thank everyone for their comments on this thread. It is great to see the passion that we all share for security and privacy.
In 1Password version 5.1 we simplified the inactivity auto-lock settings to a single timeout setting. There were a number of reasons that we did so. However, the primary reason we simplified the settings was the fact many people (I would argue most) did not understand them and as a result had security settings which did not behave how they expected. Even I had trouble explaining how the “Request After” and “Request Fingerprint After” settings worked together in a way that others could understand.
If we look at a previous 5.0 scenario where a person has the MP time-out set to 24 hours, it is quite possible that they would never see the Master Password prompt, simply by using 1Password at least once each day. Alternatively, if they set the MP time-out to 10 minutes, it is quite possible that they would never see the Touch ID prompt.
Having security settings which behave differently than you expect is both unsettling and potentially risky.
That doesn't mean that having the Master Password required every once in awhile isn't valuable. It does indeed give people a level of comfort and potentially added security.
If we do add this feature back (and we are strongly considering it) then it would be with a slightly different approach. We would add a setting which removes the Master Password from the keychain at a set time interval. For example, something like the following.
This setting would simply remove the Master Password from the iOS keychain when that time interval has expired. The effect would be that on the next attempt to unlock 1Password would require the Master Password.
This is a simpler concept, albeit still advanced, and I would love your feedback. While I am not promising that this feature will be included in an upcoming release, I do promise to make that decision quickly taking your current and past feedback into account.
0 -
Jeff, I like the proposed approach. One yea vote here.
0 -
@Jeff Shiner
Finally a developer actually took some minutes to work on a solution. Thank you very much.From my understanding your solution works as follows:
- On successful master password login 1Password stores the master password in the iOS keychain thus enabling TouchID or PIN login depending on the device.
- When 1Password runs in the background it removes the password from the keychain as soon as the require master password interval expires. If 1Password does not run it does so on the next start.
- Any logins within the chosen period reset the timer.
Is this correct?Patrick
0 -
Hi @Hessijames you're understanding is very close.
On successful Master Password login, 1Password does store the MP in the iOS keychain which enables Touch ID or PIN code. Any unsuccessful unlock attempts will remove the Master Password from the keychain.
When the Master Password time interval expires we would look to remove the Master Password from the keychain. As you mentioned we could either remove it directly if running in the background or remove it when 1Password is next started.
My thought is that this would be a static time-out value rather than an inactivity time-out value. So unlocking 1Password using either Touch ID or PIN code would NOT reset the timer. Unlocking 1Password with your Master Password would essentially start the timer (you can think of it as reset) as that is what places the Master Password in the keychain.
I hope that makes sense :)
0 -
@Jeff Shiner
While the static timeout variant should be slightly easier to implement I would personally prefer the one where the interval is reset upon successful login which will be especially useful for the shorter periods I used in version 5.0, e. g. 10 minutes.Patrick
0 -
I actually like the idea of
it is quite possible that they would never see the Master Password prompt, simply by using 1Password at least once each day"
The only time MP is needed if the device is not used for an extended period of time. At the same time, if 1PW is accessed constantly, MP may not be needed. This would prevent the inevitable MP request at the wrong time because the timer just run out.
Thank you for working on this.
0 -
Hi @Fairgame,
I'm with you - I really like the convenience, and, since I enter my Master Password several times a day on my Mac, there's little danger of me forgetting my password due to dis-use.
However, as you can see from the lengthy discussion here, there are some users who are wary of relying solely on TouchID to access the password data. We'll do what we can to ensure that 1Password's security settings work for all users. :)
0 -
Let's sum it up.
@Jeff Shiner thankfully started the discussion of a potential(!) alternative to the original timeout, i. e. 1Password is unlockable by TouchID (or the PIN on non-TouchID devices) for a user configurable timeout.
There are now two alternatives (let's assume the user configurable timeout is set to 10minutes):
a.) Master password will be required 10 minutes after the last 1Password unlock by master password.
b.) Master password will be required 10 minutes after the last 1Password unlock by master password or TouchID.
At the current state of the discussion, Jeff prefers a, I prefer b and @Fairgame prefers b. Please correct me if I am wrong.
I would be happy to hear additional opinions on the alternatives.
Patrick
0 -
Either one would be acceptable to me, but I prefer a to b, because a keeps the master password timeout separate from the touch ID / pin code timeout. IIRC, this is how the original 5.0 scenario worked.
0 -
@Jeff Shiner Thank you for your elaborate response and your acknowledgement of why the issue is so important to us. I think the following sentence underpins what this whole discussion is about:
Having security settings which behave differently than you expect is both unsettling and potentially risky.
The oddity, from my perspective, is that nothing effective has been done to compensate for the loss of the additional security layer that the timer previously had. Where at first the risk was that users might not understand how the timer worked and, by mistake or ignorance, chose a timer that was too long, now the timer isn't mentioned at all and Touch ID has for all practical purposes become more similar to the master password while offering demonstrably less security on its own.
Your suggested solution is adequate for my needs, as long as I am in control of Touch ID a bit more. I like to use it as well, but not at current expense. I would prefer solution B as well, but I can live with solution A. After all, having to enter your master password regularly should still give you the impression that Touch IS is only a secondary authentication mechanism.
In addition, I want to ask whether you could reconsider bringing back the passcode option as well.
0 -
Hi all!
The security properties of 1Password TouchID unlock are neither ideal nor very clear. I don't think that there is any disputing that.
The question that we have to face in our design is whether the advantages outweigh the disadvantages, and what we can do to accentuate the advantages and mitigate the disadvantages.
Force Master Password usage for next unlock
One thing that we do to mitigate the disadvantages is that when the operating system tells us that a TouchID attempt has failed, we immediate clear the obfuscated Master Password equivalent (MPE) from the iOS keychain. The same is true if you tap the "Enter Password" option instead of using TouchID on the 1Password TouchID screen.
This gives us all a quick and easy way to ensure that the next time 1Password is unlocked, it must be unlocked with the Master Password. So if you are going to hand your phone to a family member who has an enrolled finger, you can first do that to protect against TouchID unlock. Likewise, if you are facing a situation where someone might use your finger to unlock 1Password, you can also set it so that a Master Password is required for next unlock.
There are two (opposite) problems with this trick.
It places the burden on the user to develop the habit of using the trick when needed.
This is far from ideal, and does not conform to our goal of making the easy thing to do be the security thing to do. I know that I rarely follow my own recommended practice here. We continue to look for solutions to this (more on that below).
It locks app-extensions, too.
Using this trick will not only force you to use your Master Password the next time you try to unlock 1Password itself, but it will force use of the Master Password the next time you use the 1Password app extension. This is try, even though the app extension is giving you just very limited access for a very specific task.
The big change between PIN/TouchID behavior between versions 4 and 5 was motivated less by TouchID and more by app extensions. App extensions may be called more frequently than people opening 1Password itself. And when they are called, it is for quick specific tasks. We found our mechanism clearing or retaining the MPE was so unreliable that it meant that people had to enter their Master Passwords far more frequently then they expected. It made app extensions a pain to use.
It is the second point that becomes a problem when we try to set a time limit on use of TouchID for unlocking. There simply is no reliable method to say, "remove the MPE from the iOS keychain if 1Password hasn't been used for 30 minutes."
The various schemes that we used in 1Password 4 for the PIN with this respect were also unreliable, the the consequences of that unreliability were not as noticeable prior to app extensions.
Confusing options don't help. Particularly if they don't always work as expected.
Many of the proposals that I've seen in this discussion are good, but they require additional configuration options. Our experience is to try to avoid those. They make things harder to understand and generate confusion even if they always worked reliably.
Every time someone opens 1Password expecting to be prompted for their Master Password but isn't, this gets seen and reported as a vulnerability. Yet to make sure that that never happens, we would have to be so aggressive about removing the MPE that we make the PIN or TouchID unlock unusable. People will be prompted for their Master Passwords when they don't expect to.
Separating MPE removal from lock screen behavior
One approach to, say, force use of Master Password when opening the application, but allowing TouchID to work in the app extension would be to programmaticly take people to a Master Password screen in the main app even when the MPE (Master Password Equivalent) is available in the iOS keychain. The app extension could use TouchID then, even though unlocking the main app would "require" the Master Password.
The problem with this is that it would make it appear to users that the Master Password really is required to unlock, even though its equivalent is stored in the iOS keychain. This would be highly misleading about the security state of ones data.
Again, I can see some people wanting this sort of behavior as a option. That is, keep the MPE available for the app-extension for a long time; allow use of the MPE to unlock the main app for a shorter time; an have some mechanism to allow the user to fully flush the MPE from the system. This is actually how I would personally like to use 1Password with TouchID on my phone. But merely describing each of the multiple configuration options would multiple screens, and even then the actual security properties would be far from transparent.
What we are looking at
We have been taking a fresh look at the bag of tricks that we can use to control how long the MPE lives in the iOS keychain. Perhaps we can get that to be reliable enough that it won't lead to confusion, frustration, and dangerous misperceptions about the lock state of your data. But even under the best of technical circumstances, we do face adding to confusion.
I can't promise what will come next as we continue to work through this. We are hardly complacent about the current behavior, but we need to think through the consequences of the realistic alternatives.
0 -
I have put my thoughts on this topic in the comments of the blog post from months ago. I've left it and hoped for some improvements, months have gone by and every 1password update causes me to check the preferences for something with some more security for Touch ID.
Glad to see that you guys are still thinking about it even though there's been no changes app side for a while.
Like others here the current simplified solution is not fit for purpose with our sensitive information, so sadly touchID sits disabled on my phone's 1password. My iPad version has it enabled as its kept in my home and feels more secure because of that. It's great using the feature on there, and makes entering my full master password on my phone all the more painful. Especially when in public!
For me, master password input on mobile is a fail. It's clumsy, it's given away the keys to the castle to anyone who's looking.
TouchID is awesome, and on its own pretty damn secure but clearly bypassable albeit with a fair amount of effort. I'm not sure what the odds are for a fake print failing before working and therefore triggering 1Ps revert to master password behaviour. But in light of the complexity of making that fake print it seems reasonable that 30-60 mins is as quick as that fake print could be created and used from stealing the device.
To me this leads to a natural best of both worlds solution for me.
Touch ID on its own will unlock app and extension for a user definable timeout period from when the app or extension were last unlocked. So I'd set this timeout to 30-60 mins.
Beyond this timeout the app now requires Touch ID and a pin to unlock. A pin is quick to type, easier to shield, and to any casual observer who does clock it doesn't gain access to your entire data without hacking your print unlike if they scope you entering your entire master password.
Sounds like some people would prefer the master password being required, which could be an option. On timeout expired do you want
Pin + touch ID - for convenience
Or
Master password - for security
I'd hope that timeouts could be handled by the app and extension time stamping their last use via app groups NSUserDefaults. This stamp can then be tested against once a login attempt is requested from either app or extension. If time elapsed is greater than timeout then discard from keychain if wanting to force MP or just go down to pin + Touch ID UI and test to still use the keychain if that's in the users preferences. I believe NSUserDefaults is meant to be secure for this sort of usage? Sounds a better idea than any backgrounded app removal of the keychain etc. as you've never gone down this path to my knowledge I'll presume there is a fundamental issue with this sort of simple approach?
The reason a timeout to master password doesn't suit me that well is because my usage of 1P is very variable. I'll unlock sometimes once every couple of days, sometimes daily. Any decently safe timeout expires and so I had to master password it again with your earlier versions. Essentially for my usage it was as if I wasn't using Touch ID at all. Hence why a timeout to pin + Touch ID makes more sense for my level of usage.
Anyways just my 2 cents. Great to know that you're still thinking about this issue. Something more than touch ID will be needed for some of us to feel "safe". All I'd ask is to consider more than just master password fall backs as some of us would prefer an alternative like pin + Touch ID after a timeout to guard against hacked prints but without being forced to put our master passwords in in public!
Cheers
0 -
I just saw that the latest update of iOS brought back the option to require a master password in certain intervals. That is certainly good! Thanks for that.
However, I have to complain twice more. First, the option is rather well-hidden. It is located under Settings > Advanced > Security instead of Settings > Security (I have a habit of checking ALL the settings whenever something is updated, hence why I noticed it). Is there a particular reason for this? To me, it seems that this produces additional complexity where there doesn’t have to be one, not to mention that it doesn’t do anything to bring this issue to people’s attention. Second, I’m a bit unhappy with the available intervals. You can choose between 1 hour, 1 day, 2 days, 2 weeks and 30 days. How about 6 hours?
0 -
it doesn’t do anything to bring this issue to people’s attention
That was the intention. :) It caused a lot of confusion, and as such it has been hidden away in the advanced preferences for folks who feel they really need it, but we're not by any means advertising it or encouraging use of it as a common practice.
You can choose between 1 hour, 1 day, 2 days, 2 weeks and 30 days. How about 6 hours?
Thanks for the feedback.
0 -
First of all, thank you for bringing back this basic security feature after after 5 months. I am still concerned about the chosen default values (30 days, never...) and the burial of the setting (there was a very nice alternative for a easily conceivable slider by @Remington ). In my opinion, this shows that the reintroduction of the timeout was rather a result of resignation than comprehension.
However, I agree with @jimbobuk that 30 minutes is definitely a missing value as well as 6 hours ( @Eitot ).
Patrick
0 -
Thanks Patrick. We are indeed considering this an 'advanced' feature and as such it isn't available in the normal security pane.
I do agree we could offer additional options for the timeout (perhaps even allow arbitrary entry) so I will pass that along.
0 -
I know that it has been a long five months for people (like me) who like to be able to set a maximum time between entering a Master Password. Please recall that a major part of the the reason that it went away is that we had difficulty getting it to work as expected. The new incarnation of it should work better, but again its semantics remain tricky.
One of the things you may note in the settings we have is that the granularity is coarse. We do have the "1 hour" setting, but after that it is days or weeks. This should help suggest that the actual timing of the removal of the Master Password Equivalent from the iOS keychain is not something we can control precisely. The difficulty that we face, namely that 1Password may not always have the opportunity to remove the item from the iOS Keychain, remains. But we've tried to develop more mechanisms to be able to do this more accurately.
So despite all of the improvements that we hope will shine through, this does remain an option with subtle security implications. I'd love it to be otherwise, but I suspect that until there is some break through of some sort, I expect that the questions and the the complex answers of "it depends" will keep flowing.
0
![[Deleted User]](https://w9.vanillicon.com/v2/9d1b176a985b7220d73f88997272e1f1.svg)
