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

[mrochester]

Again, where is that written?
The article I shared even says that Passkeys are about using biometrics.

You cannot setup a device with face id or touch id without first creating a device passcode. The passcode is the minimum requirement for passkeys.

 

[mpavilion]

Imagine if someone breaks into your car, and finds your house key in the glove box – that's what it's like. Bad enough they have your car; much worse that they have your house.

 

[mrochester]

You have been mixing things!

Unlocking the device is one thing.
Authorising the usage of a particular Passkey stored in the device is another thing and requires a separate authentication.

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.

 

[Paddle1]

And when your fingerprint fails, what does your phone ask you to input? That’s right, your passcode!

Face ID/Touch ID is just a more convenient version of your device passcode. If someone knows your device passcode, they can get around any request for face/Touch ID where the fallback method is the device passcode. This includes passkeys.

This doesn't work with banking apps. If biometrics fail it will demand your login information, not a phone passcode.

 

[LuisNeto]

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

No.
Your device can be unlocked using FaceID or Passcode, for example, as it works nowadays.

But you should then be able to specify whether the Passkeys stored on your phone can be used using biometrics, Passcode, or both.

 

[mrochester]

Imagine if someone breaks into your car, and finds your house key in the glove box – that's what it's like. Bad enough they have your car; much worse that they have your house.

That analogy doesn't make sense.

 

[mrochester]

This doesn't work with banking apps. If biometrics fail it will demand your login information, not a phone passcode.

That's correct, but that's not how passkeys have been designed. 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.

 

[mpavilion]

That analogy doesn't make sense.

Why? And what analogy would you prefer?

 

[mrochester]

No.
Your device can be unlocked using FaceID or Passcode, for example, as it works nowadays.

But you should then be able to specify whether the Passkeys stored on your phone can be used using biometrics, Passcode, or both.

I suspect that would require a change to the passkey specification then.

 

[mrochester]

Why? And what analogy would you prefer?

If the car key and the house key are the same, but the only way to get into the car is to break in, that suggests the only way to get into your phone it to break in (i.e., not use the device passcode).

A better analogy would be if you left your car key AND house key on the same keyring, and you lost that keyring as well as a piece of paper that had your address on it. The sort of situation you would mitigate against, the same way you would mitigate against someone being able to both steal your device and see your passcode.

 

[chrfr]

Well it's a lot more secure than our current system of passwords, so I'm not sure what the point of calling it 'bad' is, when it's better than what we currently have.

Google is opt-in for now.

You've conflated the discussion here. It's not about Google and it's not about passkeys.

 

[mrochester]

You've conflated the discussion here. It's not about Google and it's not about passkeys.

People are complaining in this thread about how passkey security works, of course it's about passkeys.

I suspect the issue comes about as a result of 1 of 2 things:

1) people who don't know what passkeys are or how they work.
2) people who know what they are and how they work, but want Apple to implement an off-spec change to how they work.

In both instances, there's nothing for Apple to do/fix/resolve here. There is no point in asking if Apple has 'fixed' this issue in iOS 17 if there has not been a change to the passkey specification that Apple needs to implement.

Either people need to understand what they are or how they work, or they need to direct their request for changes to the passkey specification to the FIDO alliance.

 

[addamas]

If the car key and the house key are the same, but the only way to get into the car is to break in, that suggests the only way to get into your phone it to break in (i.e., not use the device passcode).

A better analogy would be if you left your car key AND house key on the same keyring, and you lost that keyring as well as a piece of paper that had your address on it. The sort of situation you would mitigate against, the same way you would mitigate against someone being able to both steal your device and see your passcode.

I would go with this analogy:
One key to Open your house, Open your car and Turn ON ignition, change who is The Owner of the house, change who is The Owner of car, who Pays for Issurance and Who is letting others come and use your car and house + make useless all replacement keys for this master key

 

[mpavilion]

If the car key and the house key are the same, but the only way to get into the car is to break in, that suggests the only way to get into your phone it to break in (i.e., not use the device passcode).

A better analogy would be if you left your car key AND house key on the same keyring, and you lost that keyring as well as a piece of paper that had your address on it. The sort of situation you would mitigate against, the same way you would mitigate against someone being able to both steal your device and see your passcode.

Apple provides no way to "mitigate against it" other than hope it doesn't happen. They essentially force you to use the same key for your car and house.

 

[LuisNeto]

@mrochester : you added the Passkeys aspect to this discussion and we've been exchanging points of view based on that.
It seems you are denying that there is a problem, saying that it's Passkeys and it's the industry standard now, so everything is fine, etc.
There is clearly a problem.

But also, it seems that you have not fully understood Passkeys.
Nothing wrong with that per se. I have not fully understood them either and I want to read more about the technology.

The problem is that you are making points based on very strict technical details of how the Passkeys supposedly work that I am not seeing specified anywhere.
For example, you claim that no Passkeys implementation can rely solely on biometrics, and they all must use the device PIN (Passcode).
And when I challenged that, you talk about being required to use a Passcode to setup a device.

It's all different things.
Unlocking the device is one thing. Authorising a Passkey is another thing.

Besides that, what we have nowadays on the iPhone is not Passkeys.
Therefore, the issue being discussed in this thread is not caused by Passkeys.

 

[mrochester]

Apple provides no way to "mitigate against it" other than hope it doesn't happen. They essentially force you to use the same key for your car and house.

The 'mitigate against it' is YOUR responsibility, not Apple's LOL. Wowza for thinking Apple should be responsible for your device and passcode security.

 

[mpavilion]

@mpavilion : you added the Passkeys aspect to this discussion and we've been exchanging points of view based on that.

I think you're addressing @mrochester, not me?

The 'mitigate against it' is YOUR responsibility, not Apple's LOL. Wowza for thinking Apple should be responsible for your device and passcode security.

Well you seem to be in the minority, at least in this thread, for thinking it's good to be forced to use the same key for your car and house. I'd be happier with separate keys, even though I am fairly responsible with my device security.

 

[LuisNeto]

1) people who don't know what passkeys are or how they work.

As I wrote above, and don't take it personally, I think you don't understand them very well either.

Either people need to understand what they are or how they work, or they need to direct their request for changes to the passkey specification to the FIDO alliance

You see, I had the FIDO2 (the technology that enables Passkeys) spec page open, and I see this there (note particularly the bold part):

FIDO UAF supports a passwordless experience. WIth FIDO UAF, the user carries a device with a FIDO UAF stack installed. They can then register their device to the online service by selecting a local authentication mechanism such as swiping a finger, looking at the camera, speaking into the mic, entering a PIN, etc. The FIDO UAF protocol allows the service to select which mechanisms are presented to the user.

So the claim you've been making that it would be required to allow using the iPhone Passcode for making use of Passkeys doesn't hold up.

 

[mpavilion]

(And as an avid user of 2FA, I still maintain that what Apple offers to protect Apple ID isn't 2FA. Possessing the device and knowing the PIN are good enough factors for accessing the device, but an add'l factor should be required for changing Apple ID pw.)

 

[LuisNeto]

I think you're addressing @mrochester, not me?

That's right, and thanks! Amended!

 

[mpavilion]

A better analogy would be if you left your car key AND house key on the same keyring, and you lost that keyring as well as a piece of paper that had your address on it. The sort of situation you would mitigate against, the same way you would mitigate against someone being able to both steal your device and see your passcode.

And even this isn't a great analogy, because at least my house has an alarm! It's like Apple is forcing me to carry around my house key, address on a piece of paper, and the code to disarm the security system. (Google's six-hour waiting period, and verification texts, are sort of the "alarm" in this case.)

 

[sk1ski1]

for thinking it's good to be forced to use the same key for your car and house. I'd be happier with separate keys, even though I am fairly responsible with my device security.

The issue is even worse. Not only is your car and house using the same key, this key can permanently lock you out of your house. The thief takes over your house with no recourse.

 

[Lee_Bo]

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.

 

[Paddle1]

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.

You'd think that but Apple wants users to still be able to change it when they forget it and that's where this passcode issue comes in.

 

[sk1ski1]

You'd think that but Apple wants users to still be able to change it when they forget it and that's where this passcode issue comes in.

There are better ways for Apple to allow Apple ID password changes when a user forgets the old password. One way would be using a time delay before allowing a passcode to change it.