I doubt it based on my past experience.

After I changed my iCloud email/password my phone tried to use the old one for months, and I had to escalate the issue high up Apple Support to get it fixed (you can't erase your iPhone without proper iCloud credentials if findmyiphone is enabled). That also involved my email, so it was slightly different.

Could have, and perhaps should have, but I haven't seen anyone claim that it actually does delete the stored password after a failure. And it would be awkward if the automatic backup stopped functioning and required manual intervention after each intermittent network failure. It should be fairly easy for someone with an iPhone to test and find out.

> And it would be awkward if the automatic backup stopped functioning and required manual intervention after each intermittent network failure.

But not awkward after a valid reply from the server saying "password incorrect".

If the HTTP status code is 5xx, keep the password. If the HTTP status code is 4xx, delete the password.

Obviously making some assumptions (like HTTP, or a 5xx on network fail between internal services), but telling the difference between "user supplied bad data" and "the server messed up" really isn't that awkward at all.

That's exactly what we do in one of our iPad apps.

Changing the password back from the client side is not a good test. The salt may be different, the hashing may have changed, etc.

For a real test, the server side hash must be saved and restored. Good luck.