Couldn't you hash the old hash with the new one even if they didn't log in? I.e. hash the password with the old SHA-1 first, then bcrypt that. I'm not sure if that would work or not.

In theory you could, but then the code has to support both login procedures forever (hashing once with scrypt or hashing with SHA1 and then scrypt). That's why, if it were me, I'd likely set it up so if someone with a SHA1-hashed password logged in, it first did the SHA1 comparison, and if that succeeded the login process dropped an scrypted version into the DB.

You could just always do a hash using SHA1 then feed that to bcrypt. This way you only have one code path, for all users.

Except that for some people, you only have a SHA1 hash, and for others, you only have an scrypt hash. Since they (I hope) weren't storing the plaintext (pre-hash) passwords alongside the hashed versions, the only time they can change the initial hashing mechanism is when passwords are provided to them during a password change or user login.

Hash all the sha1 passwords with scrypt. Hash all new passwords with sha1 then scrypt.

Your new hash mechanism is sha1 then scrypt.

There is no excuse to do otherwise :)

(ADJUSTED:) Yes, if when you said "hash the password" you meant the result of what they'd done originally and that was stored in their databe. They don't have a copy of the password until and unless the user logs in again. These are all "one way" or "trapdoor" functions, plaintext -> irreversible cyphertext.

Irreversible in that we think mathematically you can't go back.

Read his comment again. Hash the password to SHA-1 using the old system, then apply bcrypt to it. It's a migration pattern I've seen in practice a few times.

Thanks! And updated to try to clarify.