Upgrade password hash in an existing system: Pbkdf2( salt , OldSha1Hash )

Question

Background [Updated]
Consider a situation where a website was created over a decade ago and user account password storage was done by storing SHA1(password) into the database.

It would be great to upgrade the system to use Pbkdf2(salt, password) with a large work factor of say 50000 for the password hashing using HMACSHA256 as the prf. The resultant hash | salt could be stored in the database and used to validate the visitor when they return and supply a password. This approach seems to be well regarded here on crypto.stackoverflow.com.

It would be great to be able to improved the hashing for all the existing accounts without needing users to reset their password. So I'm wondering if the following approach is good from a security perspective.

  OldHash = SHA1(password)
  UpgradedHash = Pbkdf2(salt , OldHash )

  StoredInDatabase = UpgradedHash | salt

One desirable property of this approach is that all existing password hashes can be upgraded to using Pbkdf2, salt and a high work factor without needing to have the passwords reset. All the new passwords could even be handled the same way just to keep all the hashes consistent. So new passwords could work like this:

  Hash = Pbkdf2(salt , SHA1(password))
  StoredInDatabase = Hash | salt

Rational for Upgrading the Hashes
The need to upgrade the password hashes is because the SHA-1 hashes don't include salt and SHA-1 has since been reported as broken. The goal in upgrading the password hashes in the database is to reduce the likelihood that a hacker with access to the database of password hashes could obtain the corresponding passwords for those accounts.

Question
Does this seem like a security valid approach for upgrading the password hashing approach in an existing system?

Answer 1

Yes, mostly

But wait, isn't SHA-1 broken?

It is. SHA-1 has collisions found as of 2017. But this isn't important for our usage, since we only require that SHA-1 won't collide for our inputs. Difference is that with 2017 attack attacker knows plaintext and tries to find another plaintext that gives same hash, in our case attacker doesn't know anything (not even hash). And we can assume that SHA-1 won't collide for real-life passwords, since if this was case it would be very major breakage of SHA-1 (that would have been found earlier).

There is however one catch: SHA-1 will limit your security to 80bits, since it has 160bit output and birthday attack can "limit security" to half of output bits (in our case). This is in fact reason PKDBF1 was abandoned in favor of PKDBF2, but most passwords are far from 80bits in security.

Note: I didn't take any of other problems into account in my answer. Choice of PKDBF2 might be considered outdated by this point too. I personally would suggest Argon2 (but some would call it too new to be adopted). Also PKDBF2 doesn't have one input, as others noted, but I'll assume it's just overlook.