search

mssun / passforios

Pass for iOS - an iOS client compatible with Pass command line application.
https://mssun.github.io/passforios
MIT License
1.5k stars 102 forks source link

app specific passcode vs device passcode #383

Open rayx opened 4 years ago

rayx commented 4 years ago

(This is not an issue but a question)

I wonder why the app requires user to set an application-sepcific passcode when user enable authentication in Settings->Passcode Lock? Isn't it better to just call LocalAuthentication API to authenticate user using touch/face id and fall over to asking user to input device passcode if that fails? In my opinion, asking user to set a shorter and almost never needed application specific passcode is not only inconvenient but also insecure.

What confuse me most is that the design is not specific to the app, but is common to all iOS apps I have used. I never see an iOS app authenticates user using device passcode. Why? Is there a policy in App Store that doesn't allow this (I doubt it because if so what's point for Apple to provide LAPolicy.deviceOwnerAuthentication)? Or is it considered a bad practice? Thanks for any explanation.

nylocx commented 4 years ago

I don't know the code, but I guess this is a historical thing, before the faceid/touchid thingy was integrated. But in my opinion it would be good to replace the key with the apple standard.

SimplyDanny commented 4 years ago

Good point. I would like to volunteer to have a look into this topic.

SimplyDanny commented 4 years ago

It is actually very simple to change the behavior. My question to @mssun is whether we could put the change to a separate branch in order to release it via TestFlight without the changes implementing support for multiple PGP keys as they are not quite stable yet. The authentication stuff is not entirely testable within the simulator only.

SimplyDanny commented 4 years ago

Or even better, the “Multiple PGP keys“ feature could be put to a separate branch. I assume it will be ongoing work for some more time blocking other smaller changes from being released.

SimplyDanny commented 4 years ago

The advantage of not using the device passcode is that users can enter a more secure passphrase. 4 characters is only the minimum. If the device has the default 6-digit code, it can be better to have the possibility to use a longer passcode for the app. Changing the behavior might annoy some users having chosen a more secure one.

So, I would actually vote against a change.

rayx commented 4 years ago

@SimplyDanny Thanks for the investigation. It's fine whether you guys decide to change it not. I asked because I was interested in the reason behind the design. There are a few other apps on my phone (simplenote, onedrive, etc) that also asked me to set a passcode before I was able to enable touch/face id. I never get why that was necessary. Honestly speaking, I'm not convinced by what you said above. If I remember correctly, device passcode can be longer than 6 digits too. If a user picks a 6-digit passcode for his devcie, what's the chance for him to pick a longer passcode for an app? In addition, if a phone was already exploited, I suspect it might be easy for some people in the world to break the applications on the phone no matter how long application-specific code were set or not.

nylocx commented 4 years ago

I'm also not convinced. Because if I'm not totally mistaken you only need you passcode to alter the FaceID information, so I guess whoever enables FaceID/TouchID is aware that there is no gain in security having a high entropy passphrase to protect the password store. And as the Passcode/FaceID/TouchID feature implements a good brute force mitigation and stores its secrets in the Secure Enclave I doubt that there is a very high attack vector on this part.

My suggestion would be to still allow using a custom passphrase in the case someone does not enable FaceID/TouchID support. But as soon as this is enabled the fallback to the passcode should be possible. In the current time when you often wear a mask in the public I really would like to use the passcode if my FaceID does not work.

rayx commented 4 years ago

For people who are interested, I stumbled on this article while looking for something else on the net. The author believes using keychain APi is more secure than using LocalAuthentication API because the former is is a system level component and the latter is an application level component (and hence has larger attack surface).

Note the author doesn't suggest using application-specific code.

It’s critical that developers set up access control on the keychain so that when users attempt to retrieve a secure item, they must authenticate with the device passcode (and therefore, Face ID when enabled).

SimplyDanny commented 4 years ago

Well, I see your points with regard to possible attack vectors and I'm a fan of simplifying things. However, I don't think the solution is to throw away the app-specific passcode.

People may intentionally allow others to access their device, e.g. an iPad shared among family members. Or someone does not have a device passcode set at all (for whatever reason) but wants to secure Pass. Relying on biometric authentication is okay. Relying on the passcode as an alternative, though, might not in all cases.

I assume this is the reason why many other apps require the user to set an additional passphrase.