Watch App about authenticator HOT 13 OPEN

@mattrubin I would be happy to buy you an Apple Watch if you develop a OTP app for it that syncs with the phone.

from authenticator.

@mattrubin I will chip in with @haasada to buy you that Watch.

from authenticator.

Thanks for putting so much thought into this! I'm certainly interested in the possibility of a watch app, but since I don't have an Apple Watch myself, it hasn't been a high priority to me. If you want to take the lead on making it a reality, that would be great!

As I don't have experience developing for the watch, I'm not certain I follow all of the steps above related to push/pull/sync. If the phone were nearby, the app could (I think) request the current password for the current token on demand, but for the app to function without the phone, the watch will need to securely store the tokens on device. Does the watch OS have keychain APIs like iOS does? I'm wary of storing token secrets in CoreData – I'd much prefer to delegate the secure storage of secrets to Apple's own Security framework.

I appreciate that you're thinking about how to add this functionality without complecting the existing app architecture. I'd be more than happy to provide feedback and code reviews if you want to start working on this.

from authenticator.

Great!

I googled a bit on keychain on the watch, and it seems that previously you shared keychain with your host app, but now it's a "normal" keychain with icloud sync capabilities (i know you're hesitating to use that, lets keep that discussion out of this thread).

So the plan would be to reuse the entire keychain persistence on the watch and write mehods for storing an entire array of PersistentToken.

that array will be pushed when it changes on the phone, and can be requested from the watch on first run etc.

from authenticator.

It would be really cool if you could solve this in a way that doesn't require the secrets to be stored on two different devices.

Perhaps the watch could request the one time code from the app instead of generating them itself. The down side is that the watch and phone would need to be near each other, but that is also the up side.

from authenticator.

Right now I'm working on using the exact same keychain persistence in the watch app as on the iPhone. I.e. local keychain based (local, as in local to the watch).

It's because I personally would want to use the watch separately from the phone. However making something that requests the code from the phone on-demand, would be trivial, so I don't see why we wouldn't make that an option in the future.

from authenticator.

Here's a quick work in progress.

The work is mostly done. Just going to alpha test it myself for a couple of days, and then tidy up my commits.

One thing I did today that I don't know if it is controversial. The syncing between the devices is done using NSData. I decided early on that rather than write some bespoke serialization mechanism, I just use the NSURL representation of the token because I know that will easily be NSData-ified.

Only today did I realise that Token.toURL() produces tokens without the secret so thoroughly that @mattrubin even made test cases to make damn sure the secret is not there. Well. That kinda put my serialization back to square one, so I decided to change that aspect of the OneTimePassword.

I guess the idea may be that secrets go one-way to the keyring and avoid even accidental debugging splip-ups where they leak somewhere in logs or so. Or are there other consequences that I'm unaware of?

from authenticator.

Pull request is in #154

This is probably enough for a first release. Worth to note:

• It doesn't do HOTP since that would require a round trip to the phone to ensure phone counter is "master". Some work to sort, not that complicated.
• This version serialises and transmits all tokens every time there's a change on the phone. I've started work to rather transmit delta updates using a new TokenStoreDelegator but we need some refactoring of the store first.
  • The identifier in PersistentToken is the keyring's identifier which means I can't keep those in sync. Could we perhaps instead use a one-way hash from the secret?
  • The relationship Token - PersistentToken complicates things. If we made some simple "random extra properties" that get persisted with the keychain item, we could potentially stick with just Token.
  • (Related to previous) the order is stored separately.
  • Maybe do a toData() serialization of the Token that definitely is allowed to keep the secret and also potential "random extra properties" mentioned above.
• Bug in that when phone updates the currently viewed token, it doesn't update on the watch. I'm totally lost in the nested view models and enums and can't for my life figure out why. If you go back to the list it is there though.

from authenticator.

I made the entry screen have the circle countdown animation. Updated the screen grabs above.

from authenticator.

Seeing that @algesten has released his own authenticator app, is this issue abandoned then? Would very much like to see an official watchOS part of Authenticator.

from authenticator.

my code is in that PR. it's mostly done. the synchronization may need some love.

from authenticator.

Thank you for your quick reply @algesten - is Tucan a "fork" of Authenticator (with iCloud Keychain Sync added)?

from authenticator.

@PatTheMav It's not a fork. It uses some of Matt's excellent OTP code to generate codes on the watch, but the iOS is (for better or worse) written in react native.

It also differs in philosophy around keychain use where it (is supposed to) set flags that allow cross device synchronize on the saved keychain entries. This is to get automatic backup and recovery which comes at a security cost that you may or may not want to pay.

Ultimately there seem to be some bug around the synching so although my app is the one I use, I'm unsure whether I trust that aspect.

from authenticator.