An application uses server-side sessions and stores the full user object (including password hash) in the session. Why is this a bad practice?

• A.Storing sensitive data like password hashes in the session creates unnecessary exposure: session stores (Redis, memcached, files) become high-value targets, session serialization bugs could expose data, and the data becomes stale - if the password changes, the session holds the old hash. Sessions should store minimal data (user ID, role) and fetch current data from the database when needed
• B.Storing the full user object makes the session record too large for cookie-based stores (the 4KB limit applies to server-side stores too), and each request must deserialize the entire object, slowing the application; sessions should hold a user ID (and a role) and fetch the rest from the database when needed, an approach that keeps the record small in Redis and cuts the memory used by each active user
• C.The password hash is sent to the browser in the cookie (the session ID encodes the user object), and a stolen cookie reveals it directly; sessions should hold a signed cookie, a pattern that keeps the hash on the client side where the user controls it, with the signed cookie verified by the server on each request