The danger with that approach is that the hashed password has become the password. If the hashes are leaked, they can be used to login.
Actually, I've seen this done -worse- elsewhere, where they were actually encrypting the password, using a symmetric key. So if you sniffed the traffic and never loaded the website, I guess, you'd not know the actual password...but you wouldn't need it; it as as good as for the purposes of logging in. If you did load the website, you could still determine what the plaintext password was.
It was really irritating, since I had to figure out what the encryption scheme of a backend app was doing (when I only had access to the frontend code, and the datastore).
login_token = hash(pwd_hash + nonce)
its nothing too wild, especially considering the age of yahoo mail.
As is, then, it really is just making the hashed password the new password. If I can get the hashed password out of the DB, I can load the login page and simply skip the initial hashing step that's done on the frontend. I now have access to the account without ever knowing the original password.
The only thing you need in order to authenticate at any given time is the hash of (hashed password + nonce). The latter you get for free, at any time, from the server, so you only need to know the hashed password -- not the password itself. Since the hashed password is directly stored in the DB, if you get your hands on that you can authenticate.
The server will give me random_string and I know hashed_password from the DB leak.
Obviously this assumes the login process actually works as described in the earlier post.