Let's assume that you're correct, that the most common case is the user putting in the password correctly the first time.
Just to get some other numbers, let's assume I sleep 7 hours a day on average, and look at my phone every 5 minutes the rest of the day.
Then we're looking at 204 extra writes a day (17 * 12), and ~74.5k extra writes a year, and ~150k writes over the lifetime of the phone.
This isn't a negligible change, but seems within the acceptable number of writes for the phone to perform over its lifetime to properly implement a key piece of security.
I'd disagree that it's needed. An explicit sync() before returning a notification that the password is invalid would stop this attack as well, and again wouldn't require any additional writes for the most common case of the user entering in the password correctly.
They don't need to write anything. They just need to impose an increasing delay after every failure when the code is being supplied via USB or bluetooth. First failure, wait two seconds, fifth failure wait 30 seconds, eigth failure wait 90 seconds.
If they really wanted to write it to flash, they could make it so that the first failure isn't written at all, the second has a 50% chance, the third a 100% chance.
Or make it so that if the device has only been running a short period of time, then all failures require a thirty second wait until you can retry.
There are plenty of ways to make it impractical without necessarily reducing the lifetime of the device.
Just to get some other numbers, let's assume I sleep 7 hours a day on average, and look at my phone every 5 minutes the rest of the day.
Then we're looking at 204 extra writes a day (17 * 12), and ~74.5k extra writes a year, and ~150k writes over the lifetime of the phone.
This isn't a negligible change, but seems within the acceptable number of writes for the phone to perform over its lifetime to properly implement a key piece of security.