Am I right to say this would've been easily prevented by putting the hash(salt + password + client IP) in the cookie, instead of just hash(password)?
Then the actual password is hashed, and the hash of the input password is compared to the previously stored hash, to see if it matches.
This way, you need the actual password to auth, but the actual password is stored nowhere by the app, only the hash is -- so the actual password can't be stolen by getting access to the db or the file system or anything else, because it's simply not there. But it's what you need to auth.
This is really the whole point of storing hashes rather than original passwords. Right?
Now, I guess that would mean you'd store the _actual_ password in the cookie. But that does sound risky, even if the cookies are https only. Which is why usually you store a _session id_ in the cookie, and auth the session with a single auth action, not store the password in a cookie.
When authenticating, the server needs to do a hashing step to compare against the password database. Otherwise, it isn't a hashed password database - it's a plaintext password database.
And if possible, store the session information somewhere else than your database. Redis and Memcached is a nice fit for stuff like that.
Assume nothing.