Cookies, if done correctly, will store a string that the server offered after a successful authentication - that string should have nothing to do with the password (it might contain some user information for logging/cross site tracking) but nothing sensitive.

With said cookie you can absolutely impersonate a user for while (potentially needing to evade user agent string checks and the like but often not)... but it will expire and then your access should be ended. If the site is well designed actions like password changing should also re-require the user's password instead of allowing anyone with just the cookie from proceeding with the action.

If it is done right cookies are pretty decently secure at keeping your secrets safe but, for convenience they do lower the security that could be accomplished with more involved techniques.

As an aside Oauth's key -> token approach is basically identical to password -> cookie (assuming best practices are in place).

There are (illegal) marketplaces initial access brokers sell session cookies on. Some companies try to defend against that by e.g. checking whether it's even possible that you travelled from place A to place B within a certain timeframe and, based on that, might invalidate your cookie. But then again attackers, depending on their sophistication, find their ways around it by ensuring they proxy their traffic via geographically close residential proxies, use the same OS and browser versions, etc.

Google now wants to bind credentials to a device by storing the secret in the TPM: https://blog.google/security/protecting-cookies-with-device-...