I was once involved in helping diagnose a race condition in a website whereby a user could change another user's password if they changed their password at approximately the same time. When looking at the code it was not at all obvious that there was even potential for the issue until you knew it was going on...
Some on this thread are acting like these are trivial problems to avoid. I think they are wrong...
The problems aren't trivial, and sometimes the solution isn't trivial, but that doesn't mean there aren't strategies that automatically mitigate some of the issues. Using database transactions, verifying things worked correctly, rolling back transactions with unexpected results, not making assumptions like "two users won't change passwords in the same millisecond", and so on can protect your product. PHP and MySQL are largely to blame as so many web developers started out building sites on a database that didn't support transactions if you used the default engine.
Basic software quality assurance is missing from the majority of web development businesses.
Yeah, this is my question exactly. I've dealt with MANY race conditions over the years and the idea that two different user requests could update the same user account password seems... unlikely at best. Not saying it's impossible, but more detail would have been appreciated.
I've seen this before in a Java system. A MVC Controller populated the HTTP params into a Bean, which it assigned to an instance field, and then used that subsequently to grab the value to update (don't think it was password, might have been email address iirc). This would work fine if the controlled was request scoped, but it turned out to be a singleton - so the field was shared across all requests!
Some on this thread are acting like these are trivial problems to avoid. I think they are wrong...