If a database of passwords is compromised, but the passwords are properly hashed and salted (server-side, not client-side), then you would need a rainbow table for each salt in order to actually get something usable from the compromised data.
Ignoring all the other benefits of HTTPS, it means you can securely transfer the password itself to the server, or a deterministic hash of the password which the server hashes again. Not to mention that you can use a stronger hashing algorithm, like bcrypt. There might be other ways to do this, but https is definitely the most practical.
who cares if you need a rainbow table?
If the passwords are moderately strong and you are using a good hashing algorithm (that is salted), then creating a big enough rainbow table (or brute forcing) is intractable.
Comments
If a database of passwords is compromised, but the passwords are properly hashed and salted (server-side, not client-side), then you would need a rainbow table for each salt in order to actually get something usable from the compromised data.
Ok, how does HTTPS help with that?
And who cares if you need a rainbow table?
Ignoring all the other benefits of HTTPS, it means you can securely transfer the password itself to the server, or a deterministic hash of the password which the server hashes again. Not to mention that you can use a stronger hashing algorithm, like bcrypt. There might be other ways to do this, but https is definitely the most practical.
If the passwords are moderately strong and you are using a good hashing algorithm (that is salted), then creating a big enough rainbow table (or brute forcing) is intractable.