Unlock 1Password on a Mac using Touch ID on an iPhone 5s or later
Comments
-
It has been a while, what's new? Any progress beeing made? What are the hurdles?
thanx
0 -
Hi @K_Mar,
The case for this in our bug tracker has many brain dumps with different ideas for how this could be done... none of them good enough.
So there's two parts to this problem, both of which we have to take extremely seriously. I'll go through them and then explain why this is different than other apps you may have seen that do things that might make you think "if they can't do it, why can't AgileBits?"
- How does the Mac know to unlock?
- How does the Mac get the information needed to unlock?
First let's look at how I think other apps accomplish this. I'm pretty sure that other apps use a simple paired bluetooth LE connection between the Mac and the iOS device. So the iOS device sends a signal to the Mac over the BTLE connection, and the Mac is responsible for doing the rest itself. On the Mac side, the app stores your password in the OS X keychain. The app gets your password out of the keychain, and enters it on your behalf into the password field that's shown, and triggers the enter key for you. That's more or less it. Sounds simple, right?
Now let's look at those two parts and why that method doesn't satisfy my requirements.
How does the Mac know to unlock?
Let's go on the assumption that the Mac app has everything it needs to unlock itself like the other apps.
From the Mac's side, we need to know that the unlock signal came from the mobile device we think it came from. The iPhone should have to prove itself to the Mac. This could be done with something like public/private keys, assuming that when you're doing the initial setup you're in a trusted environment so that the key exchange can happen securely. You could feasibly build something here where the two devices could setup a secure communication stream on top of BTLE so that we don't need to rely on BTLE's encryption at all.
Keep in mind that it is crucial that we know that the unlock signal came from the device we need it to come from.
How does the Mac get the information needed to unlock?
All of this assumes that the Mac has the information it needs to unlock the Mac app. I say information here to be generic... it could be in the form of your Master Password, or maybe it's the encryption key derived from your Master Password... whatever could be used in order to unlock your vault. This is a major worry.
Other apps are likely using the OS X keychain. We don't like the OS X keychain. I'm not knocking the OS X keychain, it does some great things, it just turns out to be a poor fit for us in most cases. Unlike the iOS keychain, the OS X keychain makes it possible for us to write data into the keychain, then later have it be inaccessible because the keychain will have asked the user "are you sure you want to allow this app access to the keychain?" Those technical enough to understand that question from Keychain know what button to click. Normal users see a dialog like that and tend to get scared. They click the "wrong" button, and we've lost access to data we need, which then breaks our feature.
Putting that information in the keychain also raises a concern... other apps can read the keychain. Do you want all apps to have access to that? Personally... I wouldn't feel comfortable with that.
You can get around both of those problems by not using the system's Login keychain and instead using a separate keychain. This stops any other apps from snooping in, and also lets you access it without having to ask the user for it. Awesome! Except now we've just moved the problem. The system keychain is protected by OS X and your login account. This new keychain we create is protected by... a password of our choosing. We can create a random password, but then where do we store it?
One option would be to not store this information anywhere on disk. The Mac app could store it in memory, encrypted with a random key. This would mean that the feature would only work after you've unlocked your vault manually once. We'd need you to give us the password so that we can store it in memory, since it's not available for us anywhere else. This wouldn't be the first feature we make that only works properly after an unlock. So maybe that's not the end of the world.
I'm still a little uncomfortable with that idea though. Mostly because it means that the Mac app would almost always have what it needs to be unlocked, even when you've locked your vault and your iPhone isn't anywhere to be found. This opens up security concerns, and puts a big target on the Mac app. What if another app can trick it into unlocking itself?
What does the unicorn look like?
There's going to be a whole lot of hand waving here, but in a perfect world here's what I would like to see:
- The iOS and Mac device go through a pairing process. Maybe we can assume that the pairing process is done in a secure environment.
- The iOS and Mac device set themselves up such that they can later do mutual authentication.
- The Mac app passes unlock keys (maybe your Master Password, maybe an encryption key) to the iOS app.
- The iOS app stores that in its keychain (where it's the only process that can read it, and access won't be revoked)
- When the iOS app wants to unlock the Mac app, it connects to the Mac, and the mutual authentication takes place.
- Upon successful authentication, the iOS app passes the unlock keys to the Mac.
- Mac app uses that to unlock the app
There might still be issues with this, for example with Master Password changes and such.
The part that we've not been able to figure out is how to do the mutual authentication. When you live in a world where you have to distrust everything, it's really difficult to do this.
I hope that explains where we're at. All of us think that this would be really neat to have. We haven't given up on it yet, but we want to make sure that if/when we build this that we're building it in as solid a way as we can. People trust 1Password with their most important of information.
Rick
0 -
Many people like me want Touch ID access on Mac. Why doesn't 1Password add this feature as many other apps like MacID?
1Password Version: 6.0.2
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided
Referrer: forum-search:Touch ID on Mac? Why not?0 -
@brioscio: Indeed, Rick went into a great deal of detail in his previous post on the challenges involved in doing something like this. I've discussed much of that in the past, but definitely read his thorough explanation. Cheers! :)
0 -
I'm 100% for this. Having to type my extremely long master password is annoying but necessary. If there was a way to verify the iPhone belongs to the account and then use touch ID maybe followed by a short pin even for 2FA as an option. This would be so handy. As for the people using MacId. I used it for awhile, then after a crash it wouldn't unlock my laptop and I didn't know my ridiculously long password. I had to build a new keychain and lost my whole keychain built up over years. Just a word of warning. I reverted back to knock after this.
0 -
As for the people using MacId. I used it for awhile, then after a crash it wouldn't unlock my laptop and I didn't know my ridiculously long password. I had to build a new keychain and lost my whole keychain built up over years. Just a word of warning. I reverted back to knock after this.
@PumpedSocial: I love MacID, but like you I've had issues with it too. I'll have to check out Knock. But as for not knowing your password...there's an app for that! Keep it in your 1Password vault on your iPhone so you don't have to go through that again! :dizzy:
I really hope we'll be able to add this kind of functionality to 1Password someday too, but apart from the technical challenges Rick mentioned, as users we face very different challenges like you illustrated above, so it will have to be not only secure, but also well-thought out. :pirate:
0 -
The part that we've not been able to figure out is how to do the mutual authentication.
I read the way some car keys prevent replay attacks is to send a different code for each unlock, following a mutually-known but secret sequence. Perhaps for the mutual authentication you could do something similar. Either take that idea directly, or, once the Mac and phone authenticate to each other, they agree on a fresh set of keys to use next time.
As for duplication attacks, I’m not an iOS developer, but skimming Apple’s iOS Security document it looks like they’ve made it easy to store data that is entangled with the hardware UID (which is "provisioned during fabrication” and "not known to Apple”), and thus non-transferrable. See the "Complete Protection” Data Class (p. 12).
0 -
I read the way some car keys prevent replay attacks is to send a different code for each unlock, following a mutually-known but secret sequence. Perhaps for the mutual authentication you could do something similar. Either take that idea directly, or, once the Mac and phone authenticate to each other, they agree on a fresh set of keys to use next time.
@1poster: Ah! I cringed when you made the reference to electronic car locks. It's definitely an interesting idea, but as we've seen, you can use all the cryptography you want, but if the implementation is broken it won't be secure. Which brings me to the next point:
As for duplication attacks, I’m not an iOS developer, but skimming Apple’s iOS Security document it looks like they’ve made it easy to store data that is entangled with the hardware UID (which is "provisioned during fabrication” and "not known to Apple”), and thus non-transferrable. See the "Complete Protection” Data Class (p. 12).
It's certainly something to consider. The trouble with a lot of these Apple conventions, however, is that they are not based on known standards and are ill-defined: for example it still isn't clear exactly what they mean by "tangled". Do they just mean "hashed"? If so, why not simply say that? If not, then what? It's likely this is something they consider proprietary that they do not wish to publish, and that's certainly their prerogative; but I'm not sure it would be a good idea to base something as important as cross-device unlock on an unknown. After all, it's impossible for either of us to determine if an unknown can be implemented securely.
0 -
Disclaimer: I’m not a security engineer. That said, rethinking this, if we treat it like a traditional untrusted network (the iPhone, the Mac, and the attacker), it seems like traditional solutions could suffice. You’d have to assume a safe initial pairing where public keys are exchanged, but from then on the iPhone and Mac could authenticate each other by asking one another to sign some random data with their private keys. To address the issue of not wanting the Mac to have all the information it needs to unlock itself, have it generate a unique unlock key pair on each use (after identity authentication) and store half the pair with the iPhone in a secure file.
This would mean trusting Apple’s security on iOS. Though you don’t know all the details, users have already made the decision to trust their texts, emails, and selfies to it. Coming from desktop land, where you trust nothing, I can understand the apprehension, but iOS was architected in a different way. It seems to me it’s secure enough that it’s defensible to allow the user to make the choice to trust it.
you can use all the cryptography you want, but if the implementation is broken it won't be secure
The same can be said of all security software, past, present, and future. I agree car keys aren’t a great example, since they’ve been broken so many ways. But you have an advantage, which is significant processing power on both ends of the connection. And, in reality, I imagine part of why more scrutiny hasn’t been paid to car key fob security is that people are (rightfully) not as worried about a sophisticated RF/crypto attack as they are a $5 wrench attack or just being hoodwinked.
0 -
Hi @1poster,
I can't comment on what our security team and our developer team have considered as I wasn't privy to the details but @rickfillion did mention the use of public/private keys in his previous post. He would need to be the one to address any such queries regarding that. Even once we have a rough idea though it will take time to implement such a feature and make sure it is secure.
To be honest my fear has always been anything that might increase the possibility of a person forgetting their Master Password. Repetition is what keeps it fresh in our minds and given some people might have their Mac go months between reboots what do we do to ensure we aren't encouraging people to forget their Master Passwords. That's not a technical aspect like those Rick was addressing, it's more a side-effect of such a feature. I speak from experience of that one myself. I'm sure Rick will read your posts though when he's got a chance :smile:
0 -
Hi @1poster,
You're right, except that you're hand waving over the part about where we can store the private key securely on OS X that isn't the OS X keychain. The heart of the problem for us is that we have no secure storage that's usable. The usability issues of the OS X keychain make it a non-starter for us, and there's nothing else for us to use that's truly secure. If you can't secure the private key, you can't do trusted authentication, which means you can't do proper security.
If the OS X keychain worked like the iOS keychain we'd be golden.
Rick
0 -
@rickfillion I don’t mean to be waving my hand over that part. I think I’m not appreciating all the threats you are trying to guard against. Rogue applications running on the user’s system? Duplication of an HD? Law enforcement?
Imagine this implementation (all communication is wrapped in TLS):
Set up
- The desktop generates a key pair
- It encrypts the master password with the secret key, and signs some unique hardware info with the public key
- The desktop sends the secret key and signed hardware info to the phone
- The phone stores both securely
- The desktop wipes the secret key from memory
To authenticate
- The desktop re-sends the signed unique hardware info to the phone, the phone confirms it matches what it has on file
- The desktop sends the encrypted master password to the phone
- The phone challenges the user to prove themselves via Touch ID
- On authentication, the phone uses the stored secret key to decrypt the encrypted master password it just received
- The phone sends back the master password to the desktop and the desktop unlocks
In this scenario, I would feel comfortable with fairly light mutual authentication. You might be quick to point out it would be possible to spoof the desktop on step A. I’d argue that as the user, I’m actually part of the mutual authentication process: I know whether I just tried to open 1Password on the desktop, and whether I should approve an unlock. As for authenticating the phone: an imposter phone simply won’t have a copy of the secret key.
I totally understand you may not be comfortable with “light mutual authentication," as a company. You are the ones on the hook here, not me. It just seems like it’s within the realm of reason to give the user the option to bear this risk. The very nature of this feature means that direct attacks would have to come from someone on the same LAN, which out of the gate puts it in a different (much lower) threat category than a publicly-exposed network service. The risk that remains (that someone would duplicate my HD, copy my hardware config, and precisely time an attack) feels acceptably low, given how convenient this feature would be. Viruses could be a threat, but I imagine a virus running actively on the system can do all kinds of damage after the user has unlocked 1Password, regardless of how that unlock occurred.
Coming from the opposite direction, I would suggest that if you can prove this feature is impossible to implement given your constraints, you say so publicly just to stop the speculation.
0 -
Hi @1poster
I'm still reading your post, but you start with this:
Imagine this implementation (all communication is wrapped in TLS):
That's the faulty assumption that you're starting with. TLS requires private keys. Where are you storing these private keys on the Mac that another app can't easily steal then pretend to be 1Password?
Now I've read your entire post, and I think a lot of what you're saying makes sense. Especially with
It just seems like it’s within the realm of reason to give the user the option to bear this risk.
I think there's a portion of users who could be made to understand the risks, and they would be ok with this, and we might be able to build something that's not perfect but "good enough" for them. Unfortunately that's just not good enough for us... because while those users might be ok with the risks, other users won't understand the risk. As a security company (that aims to have a product that's simple enough for everyone), that's a really big problem.
I would suggest that if you can prove this feature is impossible to implement given your constraints, you say so publicly just to stop the speculation.
We can't prove this, or at least haven't been able to prove it yet. We still have hope. We're trying to be as open as we can about this: we don't know how to do this yet in a way that satisfies our requirements. But there's been many things in the past here where that's been the case with and we've eventually figured something out. Those challenges are what get me up in the morning. :)
Rick
0 -
I just recently found out about an app called MacID. What it basically does is to automatically unlock my mac when my phone or my apple watch is close to my mac. I was thinking it would be a great feature to include in 1password so we can avoid typing in the password to unlock our 1password app everytime. What do you think?
1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided0 -
We're trying to be as open as we can about this
Which is both rare and commendable, and one reason why I’m a happy 1Password customer.
all communication is wrapped in TLS
I threw this line in at the last minute and should have put more time into it. I just meant: wrap the traffic in some form of encryption so when you send the master password it’s not in the clear. Surely with both devices having Internet connections and access to trusted key servers, there's some method to do this (I was imagining something akin to HTTPS).
Thanks for taking the time to respond to my posts.
0 -
I just recently found out about an app called MacID. What it basically does is to automatically unlock my mac when my phone or my apple watch is close to my mac. I was thinking it would be a great feature to include in 1password so we can avoid typing in the password to unlock our 1password app everytime. What do you think?
@minhqp107: I hope you don't mind, but we've merged your post with an existing discussion on this very topic. While it's very much something we'd like to be able to do in the future, it isn't something we have a solution for currently, mainly because OS X does not have the same facility to store keys securely that iOS does. Rick went into a lot more detail in an earlier post. :sunglasses:
Personally, while I enjoy using MacID myself, it really falls down a lot. I don't think it's their fault. It isn't clear if it's a problem inherent with Bluetooth itself, or just instability in Apple's implementation of it. Sometimes I can get it to work by restarting Bluetooth, but often it requires a full device restart. :unamused:
We're trying to be as open as we can about this
Which is both rare and commendable, and one reason why I’m a happy 1Password customer.
@1poster: And thanks so much for your support! We wouldn't be here if it weren't for you and the rest of our awesome customers! :love:
I really hope we can do something cool like this in the future, to allow cross-device unlocking. It could be super convenient, and provided we can do it in a secure and stable fashion I think a lot of people would really love it. :chuffed:
0 -
+1
0 -
:) :+1:
0 -
Very much looking forward to this feature
0 -
Likewise, it's something I really hope we'll be able to do someday! Perhaps WWDC will reveal some new tools we can use for something like this. :)
0 -
vote++;
WWDC 2016 two weeks from now :-)
0 -
Instead of using TouchID on the iPhone to unlock 1Password on the Mac, why not just use TouchID to pass data on the Mac that's stored in 1Password on the iPhone.
Example for web page fields that you want to complete:
- Establish a secure channel between Mac and iPhone
- Click on a new 1Password extension in Safari on Mac
- Mac passes current URL to 1Password on iPhone
- iPhone requests TouchID
- On successful TouchID iPhone passes completion info to 1Password extension in Safari on Mac which completes web form
0 -
@baldboy: We (and other 3rd party developers) don't have access to Touch ID in the way you imagine — or really at all. We can invoke Touch ID to have it authenticate you, but then we just get a "pass" or "fail" response. There may be some tricky way to do something like this in the future as Touch ID becomes available for web transactions, but it's something we'll really have to approach cautiously. Even if such a thing is possible, we'll need to respect the spirit and letter of Apple's guidelines. However, even if it isn't possible this year, given the direction Apple seems to be heading it may be something they enable more explicitly in the future — especially if macOS (and Macs themselves) gets native Touch ID support.
0 -
Hi,
An interesting topic and feature which I would also love to see.
I understand concerns from Agile side as a security company and hopefully you guys will find a solution that will satisfy you.I am also not security expert of no kind, did some certificate stuff with e-goverment but that is about it, so do not laugh me out too hard if my "observation" seems ridiculous :-)
I noticed one thing in all the "1Password, TouchID, Mac" topics - no one ever mentioned iCloud account - which is something Apple also relies a lot when doing stuff like Handoff (or I missed it and I am simply making a fool of myself now :-))
Is there no way to utilize iCloud architecture for initial setup and help in later device negotiation? Create a hash that can only be created on a device logged in with same iCloud account?This would push security a bit further because attacker would also need to have iCloud account hacked.
iCloud account could also be used to generate keys for TLS communication.Also - you have control. For instance, you ask user to enter iCloud pass to authenticate and if password is too simple, you can disable feature telling user it needs stronger password to use this feature.
Further, for initial setup, you can request additional confirmation over e-mail - because e-mail can not be icloud.com (neither can be for iCloud account) - it is additional step in security, requiring attacker to get yet another account hacked.Regards,
Mario0 -
Hi, An interesting topic and feature which I would also love to see.
I understand concerns from Agile side as a security company and hopefully you guys will find a solution that will satisfy you.
@mblataric: What we really need to satisfy is the security that you and the rest of 1Password users — including us — expect. And, ideally, we want to do it in such a way that it's transparent.
I am also not security expert of no kind, did some certificate stuff with e-goverment but that is about it, so do not laugh me out too hard if my "observation" seems ridiculous :-)
Not ridiculous at all! Even if something isn't possible today, I think it's always important to think about the "what if's". Someday we may have the necessary tools, so having an idea already what people want and how we might achieve it is actually pretty important.
I noticed one thing in all the "1Password, TouchID, Mac" topics - no one ever mentioned iCloud account - which is something Apple also relies a lot when doing stuff like Handoff (or I missed it and I am simply making a fool of myself now :-)) Is there no way to utilize iCloud architecture for initial setup and help in later device negotiation? Create a hash that can only be created on a device logged in with same iCloud account?
Not currently, but that's also a neat idea. The main obstacle is that the other end (probably the Mac, in your scenario) will need to know i advance how to "unlock" the shared secret, so it would require some setup.
This would push security a bit further because attacker would also need to have iCloud account hacked. iCloud account could also be used to generate keys for TLS communication. Also - you have control. For instance, you ask user to enter iCloud pass to authenticate and if password is too simple, you can disable feature telling user it needs stronger password to use this feature. Further, for initial setup, you can request additional confirmation over e-mail - because e-mail can not be icloud.com (neither can be for iCloud account) - it is additional step in security, requiring attacker to get yet another account hacked. Regards, Mario
These sound like a lot of steps and factors to consider, so before we do something like that we'll want to make sure that it's not only done securely, but that it isn't even more burdensome on the user. Sometimes when too many "levels" are added, we get to a chicken-and-egg scenario where the user wants to access 1Password, but they need to access some other information in an account...whose credentials are stored in 1Password. Definitely something to think about though. Cheers! :)
0 -
Hi,
Not currently, but that's also a neat idea. The main obstacle is that the other end (probably the Mac, in your scenario) will need to
know i advance how to "unlock" the shared secret, so it would require some setup.I think it is reasonable that setting up a feature like that does require several steps and using iCloud could be a "common ground".
These sound like a lot of steps and factors to consider, so before we do something like that we'll want to make sure that it's not only done securely, but that it isn't even more burdensome on the user. Sometimes when too many "levels" are added, we get to a chicken-and-egg scenario where the user wants to access 1Password, but they need to access some other information in an account...whose credentials are stored in 1Password. Definitely something to think about though. Cheers! :)
As I said, on initial setup it is completely acceptable to have multiple steps and security checks. It is not required for users to do it and those who wants it - I am 100% sure - will not mind few extra steps in setting up phase to get things done in a secure way.
But here is another idea, Google experimented with something like that a while ago.
Create your own web service which can securely communicate with both Mac and iPhone version.
Then, when initiating setup, display some QR or PDF417 like code on Mac screen and use iPhone to take photo of that code and use your service to validate. This will ensure that person validating a phone is actually sitting in front of the Mac and since both apps communicate securely with your service - you have pretty secure environment for initial setup.
It would be hard to spoof that, since attacker does not have keys to access your service and would also have to intercept the validation code. You can also add time-expiration of like 15 secs after which a new code would be required.Of course, this still leaves the issue of further authentication and storing secure keys.
I understand you do not like Keychain, but is it really that bad that no solution is better than Keychain solution?Or how about 1Password on PC/Mac has a push service built-in with it's own "vault" and iPhone would register and authenticate using tcp/ip. It would work only in local network (would not require bluetooth), registration can be done only in local environment, you can setup any propriety encryption and so on ...
Regards,
Mario0 -
@mblataric: The main obstacle with this or any other solution is enforcement and secure authentication. On iOS we have the Keychain, which is really locked down. Macs have a "Keychain" too, but it doesn't have the foundation of the iOS security architecture to build on:
WWDC 2016: How iOS Security Really Works
It would be a difficult transition given the platform's legacy baggage, but I hope that this can make its way to the Mac, as it would make a huge difference there. And once there's a chain of trust in place, it's something that can benefit anyone on the platform — from users to apps like 1Password.
0 -
Please count me in on the list of persons that want this feature.
I'm sure a safe way exists, otherwise other apps like MacID wouldn't work or they would be very insecure, I doubt they are.
0
