The solution here is a missing option for using biometrics along with the passcode. I feel the biometrics are too low of a barrier - so prefer using a passcode. However I have no issue with using biometrics along with the passcode such that entering the code is useless without my fingerprint or face. That leaves the problem of the passcode currently being used as an override for biometrics, but that can be solved with a different passcode for override or requiring the iCloud password to unlock.
2FA via passcode and biometrics is quite nice. The solution you propose enhances privacy/security protection against "the criminal element" and law enforcement alike, as biometric indicators in isolation are fair game for the police. #acab
I thought so too. But counterintuitively, security keys are treated the same as an already logged-in device. This means, even if you had a security key set-up, an attacker would still be able to change the iCloud password only with the knowledge of the device passcode. The attacker could even remove the security key after changing your Apple-ID password.
You only get the extra security of the security key when you set up a new device or when you log in using a browser.
Current security systems tend to have strict logic to say what actions are possible when. For example, 'if you have an iPhone logged into iCloud and the pin then you can change the iCloud password'.
I think a better model would be to compare the position the user is trying to get into with the position they were in 7 days ago.
If the user wants to remove a device from their account... Fine... But if the user 7 days ago had a totally different set of synced devices, has changed the recovery phone, and changed the password, then that's probably a bad sign.
The recovery process from this is then to ask a user to provide as many forms of Auth as possible from forms of Auth they had configured 7 days ago. If they know the 7 days ago password, recovery phone, pin, and can access devices from 7 days ago, you probably have the real user.
This is pretty scary. I doubt there is a one size fits all solution, but it seems like a red flag that Find My iPhone can be disabled immediately after the Apple ID password is changed on that device. If there was a waiting period that wouldn’t be possible.
I don’t want it to be this easy to take control of my device. There should at least be an option to require the passcode and biometric authentication to do this.
This doesn't doesn't right! Is there a design document for the security of an iPhone?
We have:
- pin code for the sim
- unlock code for the iPhone
- touchid/face unlock
- apple account password
- "forgot password" process for apple account password
Is there an official definition of the furthest I can get with each one?
Allow me to reiterate my argument against passwordless. The same people that shouldersurf a pin will still your yubikey.
This is why you need MFA at every authentication control. MFA means layered defense. Two factors are superior than one regardless of how good that one factor is. I support passwordless with MFA, in which case "passwordless" is just a marketing ruse because you still have to remember a secret similar to a password. And no, biometric auth "who you are" is the equivalent of a username not a secret you can use to authenticate (can be replicated but can't be revoked).
Passwordless is not one thing. A yubikey does not do biometric auth.
More than that "who you are" should not be used as a factor of auth but as a user id aka username. It identifies, it does not authenticate unless you can revoke it and guarantee it can't easily be reproduced.
That's not true, many years ago all you needed was long range camera or even photo to reproduce finger print and fool iphones. Especially with ML advances and considering future capabilities, biometrics is just about the worst choice. When you pick a cipher in crypto for example, you want it to resist future attacks and take small cracks seriously because they can be improved upon right? Same thing here except biometrics are a fixed immutable identifier.
12 comments
[ 4.2 ms ] story [ 33.5 ms ] threadYou only get the extra security of the security key when you set up a new device or when you log in using a browser.
I think a better model would be to compare the position the user is trying to get into with the position they were in 7 days ago.
If the user wants to remove a device from their account... Fine... But if the user 7 days ago had a totally different set of synced devices, has changed the recovery phone, and changed the password, then that's probably a bad sign.
The recovery process from this is then to ask a user to provide as many forms of Auth as possible from forms of Auth they had configured 7 days ago. If they know the 7 days ago password, recovery phone, pin, and can access devices from 7 days ago, you probably have the real user.
I don’t want it to be this easy to take control of my device. There should at least be an option to require the passcode and biometric authentication to do this.
We have:
Is there an official definition of the furthest I can get with each one?This is why you need MFA at every authentication control. MFA means layered defense. Two factors are superior than one regardless of how good that one factor is. I support passwordless with MFA, in which case "passwordless" is just a marketing ruse because you still have to remember a secret similar to a password. And no, biometric auth "who you are" is the equivalent of a username not a secret you can use to authenticate (can be replicated but can't be revoked).
Something you have (your device) Something you are (your biometric)
Those are definitely two factors that are required to be together for passwordless to work
More than that "who you are" should not be used as a factor of auth but as a user id aka username. It identifies, it does not authenticate unless you can revoke it and guarantee it can't easily be reproduced.
Biometrics are very difficult to impossible to reproduce short of physical coercion.