Could have, and perhaps should have, but I haven't seen anyone claim that it act...

jjnoakes · on March 8, 2016

> 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".

nkurz · on March 8, 2016

Possible, but still awkward. If the network failure is between the server and the password database, it would still need to distinguish between "password permanently incorrect" and "password temporarily incorrect".

But my stronger point was that there is no need to speculate, since someone with an iPhone can verify what actually happens. Set up backups, change the password, verify that it fails, change the password back, and report what happens.

kiallmacinnes · on March 8, 2016

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.

chime · on March 9, 2016

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

jjnoakes · on March 9, 2016

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.