Is the 'change Apple ID password with stolen passcode' issue fixed in iOS 17?

[papbot]

Interesting. From my MacBook Pro, I opened settings and tried to change my Apple ID password.

And this screen appeared:

So how hard would it be to make a small change to the iOS code to make you use your current password before changing said password? Then it wouldn’t matter if someone had your unlock pin.

Unless they also knew your Apple password.

But that’s an argument for another day.

Well if gangs of knife wielding muggers attack you as has been mentioned in this thread, odds are they’ll get your passcode as well as Apple ID. Why wouldn’t they unless they’re stupid. So that’s an argument for today as well.

 

[LuisNeto]

as well as Apple ID.

I assume you meant "Apple ID password" there.

And no, you are wrong. Thieves wouldn't necessarily get your password, because contrary to the Passcode, there is no guarantee that the victim has memorised the password.
They can't force you to reveal a password that even you haven't memorised. Or even if you have, you can deny that you do know it.

Good password practises include:

• having a long password which can be made of random characters and symbols.
• store it in a password manager.

Don't use a password manager? Store it in a piece of paper and keep it at home, or wherever you consider secure.

So yes, it would make a big difference if Apple made a change in iOS to require the password instead of the Passcode when changing that password.

 

[papbot]

Or even if you have, you can deny that you do know it.

You can deny remembering the passcode as well. None of these protects you in the scenarios mentioned in this thread when the roaming gangs of knife wielding thieves attack you. In that case you’re toast even if you have no phone. And if you do they’ll get those passcodes or passwords despite what you claim. You can just as easily deny remembering your passcode as you can your password. Again other than the roaming gangs I’ve only seen a few reports of this at a bar. Since I’ve never had to enter my passcode in public I don’t give those a second thought. But the roaming gangs, well you better come up with something better than “I can’t remember”.

 

[LuisNeto]

You can just as easily deny remembering your passcode as you can your password.

Wrong. That tactic would not work.
Pretty much everyone knows their passcode.

None of these protects you in the scenarios mentioned in this thread when the roaming gangs of knife wielding thieves attack you. I’m that case you’re toast even if you have no phone.

If you're talking about protection in the sense of physical integrity, you're going off-topic

This thread and my points are not about protection from physical harm.
It's about security of the Apple ID account.

Let's stay on the topic, please.

 

[papbot]

This thread and my points are not about protection from physical harm.

You better get back on topic and reread the posts. I was not the one to bring up roaming gangs of knife wielding thieves. And denying you remember your password is not any more valid than denying your passcode. Neither will work in the scenarios presented in this thread.

Use the current safeguards that are in place, don’t enter a passcode in public, and protect your devices. I know many who use their Apple ID password as their passcode. So they know them and could be at risk in any of these scenarios physical or otherwise.

 

[LuisNeto]

I was not the one to bring up roaming gangs of knife wielding thieves.

Yes, I mentioned thief/thieves with knife/knifes, because you were insisting that this only happens to careless people who let others see their Passcode:

There is nothing new here, just the same risk of careless behavior.

Bottom line don’t be careless.

Many if not most of the reported incidents were from bar surfing people who were putting in their passcodes. Alcohol and carelessness - always a bad mix.

Another careless bar story.

So I mentioned the thieves with knives to make you understand that this is also happening to people on the streets who are mugged, not just to careless people as you were insisting.

The point was never about whether a particular method of securing the Apple ID account puts you at risk of physical harm and another method saves you from that risk.
Again, this thread is only about the security of the Apple account.

And denying you remember your password is not any more valid than denying your passcode.

I will continue to disagree.
Pretty much everyone knows their phone PIN (iPhone Passcode). It's even the fallback when biometric authentication doesn't work.
Not everyone will know their password. If I tell you I don't have my password in my memory because it’s a long string of random characters, you can't argue with that.

I know many who use their Apple ID password as their passcode.

The people you know are the people you know. That doesn't make it the rule.

I think we can agree to disagree on our views.

 

[zorinlynx]

It's one thing what happens nowadays: thieves force the victim to give them the iPhones on the street and coerce him/her to reveal the Passcode, which gives the thieves access to the Apple ID account. Normally, this happens under knife threat.

Maybe the solution is to have Apple implement a "burner passcode".

Basically, a passcode different from your real one which seems to work at first, and seems to allow changes, but doesn't actually make those changes, and after sufficient time has passed (a few hours?) remote wipes the device and leaves it activation-locked so it's useless to the thief.

This would be an awesome feature for people living in areas where they're likely to be mugged. Of course to implement it properly there needs to be no easy way to tell the burner passcode has been used. Everything must SEEM to be available, and changes must SEEM to work, long enough for the victim to make it to safety.

Just a crazy idea. I doubt Apple would ever do it.

 

[LuisNeto]

Maybe the solution is to have Apple implement a "burner passcode".

Basically, a passcode which seems to work at first, and seems to allow changes, but doesn't actually make those changes, and after sufficient time has passed (a few hours?) remote wipes the device and leaves it activation-locked so it's useless to the thief.

This would be an awesome feature for people living in areas where they're likely to be mugged. Of course to implement it properly there needs to be no easy way to tell the burner passcode has been used. Everything must SEEM to be available, and changes must SEEM to work, long enough for the victim to make it to safety.

Just a crazy idea. I doubt Apple would ever do it.

Yeah, I had thought the exact same thing a few times before!

 

[LuisNeto]

Having shared a link to the FIDO spec key page in this comment of mine, I thought I also share an interesting page with a demo of WebAuthn (Passkeys) so we can all see how Passkeys work.
Hopefully this can put an end to the debate and incorrect claims that enabling the use of the iPhone Passcode is a requirement of the password-less / Passkeys technology specification, which has been stated in some previous comments:

Correct, with face id or touch id, and if they fail or aren't available or aren't setup, the device passcode.

The passcode is the single mandatory form of authentication needed for passkeys; biometrics are optional extras on-top for convenience.

Passkeys fall back onto the device passcode when the biometrics fail, not some other security. I suspect that COULD be changed, but likely needs the industry standard specification to be changed to allow it.

If you have a Mac with TouchID and an iPhone, it will make the demo experiment more interesting. I have set up an account on my Mac, then opened the website on the iPhone, clicked Authenticate and the iPhone give me a choice of 3 methods to authenticate:

• Use the Passkey created on the Mac which had synced to the iPhone automatically, unlocking it via FaceID. It never asks for the iPhone Passcode. It only authenticates if FaceID succeeds.
• Use passkey from another device with a camera.
• Use an external security key.

You can find the demo at https://webauthn.io/ .
(The demo is referenced in the FIDO2 WebAuthn page of the FIDO Alliance website).

 

[mrochester]

Having shared a link to the FIDO spec key page in this comment of mine, I thought I also share an interesting page with a demo of WebAuthn (Passkeys) so we can all see how Passkeys work.
Hopefully this can put an end to the debate and incorrect claims that enabling the use of the iPhone Passcode is a requirement of the password-less / Passkeys technology specification, which has been stated in some previous comments:





If you have a Mac with TouchID and an iPhone, it will make the demo experiment more interesting. I have set up an account on my Mac, then opened the website on the iPhone, clicked Authenticate and the iPhone give me a choice of 3 methods to authenticate:

• Use the Passkey created on the Mac which had synced to the iPhone automatically, unlocking it via FaceID. It never asks for the iPhone Passcode. It only authenticates if FaceID succeeds.
• Use passkey from another device with a camera.
• Use an external security key.

You can find the demo at https://webauthn.io/ .
(The demo is referenced in the FIDO2 WebAuthn page of the FIDO Alliance website).

You are completely wrong there.

I have just created the passkey on my ipad. Then, accessing the same site on my iPhone and covering the Face ID camera, I tried to login with the passkey. Face ID attempted 3 times (but failed since I’ve covered the camera) and then prompted for my device passcode. Once entered, I successfully logged in.

Heres how to do it:

Cover the face id camera.
tap to authenticate, you will see a prompt asking ‘use Face ID to sign in?’ Tap continue.
Wait until face id fails (the Face ID icon turns grey).
Tap the face id icon to try again (it’ll fail again and turn grey).
After 3 failed attempts you will get a ‘continue with passcode’ message.
Enter device passcode and you are now logged in.

As I have said repeatedly, your device passcode is the fallback option for passkeys when face or Touch ID fails to authenticate.

You absolutely must keep your device passcode safe.

Also tried creating passkeys using a combination of Touch ID on a Mac and Face ID on an iPhone/iPad and that has no impact on being able to use the iPhone/iPad passcode to login with a passkey.

 

[dewalt]

Craig F did acknowledge this problem and said they're looking into it. Who knows wtf that means.

 

[Mike Boreham]

Best fix I have seen is go to Settings > Screen Time. Turn it on **** . Go to Content and Privacy Settings. Turn it on. Scroll down to Account Changes. Change this to DONT ALLOW. Enter your Screen time 4 digit password

**** - when the pop up appears for the 4 digit numeric passcode enter it, then hit CANCEL when it asks you for your iCloud password. Yes it's confusing, but do that. This disassociates this particular password with your iCloud password - it cannot be gotten around with your iCloud password

Now you have a separate numeric passcode for *just your iCloud password*. You can see the effect this has by going back to Settings, and your name (iCloud settings) at top are greyed out. The only way to enable this is to turn off Screen Time.

Voila, your iCloud password cannot be changed even if a thief has your iPhone password

Unfortunately at least in iOS 16 setting a Screen Time password is not a solution ...see here. I thought it was at first, but try the steps in the link yourself, you can back out at any stage without changing anything.

I had set it up like your **** advice. But that doesn't stop reaching this screen by the steps in my link. Its been a few weeks since I posted that link, so I just confirmed it again:

 

[LuisNeto]

You are completely wrong there.

I have just created the passkey on my ipad. Then, accessing the same site on my iPhone and covering the Face ID camera, I tried to login with the passkey. Face ID attempted 3 times (but failed since I’ve covered the camera) and then prompted for my device passcode. Once entered, I successfully logged in.

Heres how to do it:

Cover the face id camera.
tap to authenticate, you will see a prompt asking ‘use Face ID to sign in?’ Tap continue.
Wait until face id fails (the Face ID icon turns grey).
Tap the face id icon to try again (it’ll fail again and turn grey).
After 3 failed attempts you will get a ‘continue with passcode’ message.
Enter device passcode and you are now logged in.

As I have said repeatedly, your device passcode is the fallback option for passkeys when face or Touch ID fails to authenticate.

You absolutely must keep your device passcode safe.

Also tried creating passkeys using a combination of Touch ID on a Mac and Face ID on an iPhone/iPad and that has no impact on being able to use the iPhone/iPad passcode to login with a passkey.

OK, you are right when you say that, when using an iPhone, the Passkey authentication does indeed fall back to the Passcode if biometric authentication fails.

However, I reiterate that your claim that it does this because it is a requirement of the WebAuthn specification, is wrong.

It falls back to the Passcode because Apple has chosen to implement it that way.

If Apple updated iOS to only ever allow biometric authentication in response to WebAuthn, it would not deviate from the spec.
For Relying Parties using WebAuthn it doesn't (can't, because the RP is never told the method of user verification) matter how user verification happens, only that the authenticator says that it happened.

Please stop spreading that false claim in this thread and other threads.

 

[mrochester]

OK, you are right when you say that, when using an iPhone, the Passkey authentication does indeed fall back to the Passcode if biometric authentication fails.

However, I reiterate that your claim that it does this because it is a requirement of the WebAuthn specification, is wrong.

It falls back to the Passcode because Apple has chosen to implement it that way.

If Apple updated iOS to only ever allow biometric authentication in response to WebAuthn, it would not deviate from the spec.
For Relying Parties using WebAuthn it doesn't (can't, because the RP is never told the method of user verification) matter how user verification happens, only that the authenticator says that it happened.

Please stop spreading that false claim in this thread and other threads.

Being able to use your device passcode, or biometrics, is a part of how passkeys work (i.e., all of the methods that allows the device to be unlocked and thus authenticate you). Passkeys rely on authenticated access to the trusted device, thus all methods of authentication for that device are permitted. Apple can't just unilaterally decide that passcodes are not a valid means of authentication for passkeys else they'd have to remove the ability to unlock a device with a passcode too.

 

[LuisNeto]

Being able to use your device passcode, or biometrics, is a part of how passkeys work (i.e., all of the methods that allows the device to be unlocked and thus authenticate you).

I repeat: it's how Apple has chosen to implement the authentication feature for Passkeys. Apple could very well change it, including giving users the option not use allow Passcode.
This would not be a deviation from the WebAuthn (Passkeys) specification.

If you do not agree, I have nothing further to add besides stating that you are wrong.

 

[mrochester]

I repeat: it's how Apple has chosen to implement the authentication feature for Passkeys. Apple could very well change it, including giving users the option not use allow Passcode.
This would not be a deviation from the WebAuthn (Passkeys) specification.

If you do not agree, I have nothing further to add besides stating that you are wrong.

I think you are wrong, therefore I have nothing further to add either.

 

[LuisNeto]

I'm not.
You've been making that claim without backing it up with anything from the WebAuthn spec, while I've actually been in contact with a WebAuthn expert which confirmed me that your claim is false. (Which is why it took me a few days to write here again.)

 

[mrochester]

I'm not.
You've been making that claim without backing it up with anything from the WebAuthn spec, while I've actually been in contact with a WebAuthn expert which confirmed me that your claim is false. (Which is why it took me a few days to write here again.)

Show your evidence then.

 

[LuisNeto]

Show your evidence then.

Are you asking to provide evidence that I was in contact with a WebAuthn expert who confirmed that using PIN/Passcode with Passkeys is not a requirement enforced by the spec?

I actually sent him a link to this thread and invited him to comment.
He told me that he has read these last messages and suggested me to tell you - I'll quote him here - that

https://www.w3.org/TR/webauthn-2/#user-verification does nothing to require how an authenticator performs user verification, only that it be able to return a simple true/false in the WebAuthn response whether or not user verification happened.

I was also quoting him when I wrote:

If Apple updated iOS to only ever allow biometric authentication in response to WebAuthn, it would not deviate from the spec.
For Relying Parties using WebAuthn it doesn't (can't, because the RP is never told the method of user verification) matter how user verification happens, only that the authenticator says that it happened.

So yes, Apple could very well allow the user to restrict the modalities that can perform the user verification during WebAuthn (Passkeys).