Question: I am looking into using Ansible to manage my systems and going through its documentation I found a recommendation to run the Ansible commands on a cloud image rather than my local laptop.

My understanding is that Ansible basically acts like an SSH user to the systems it manages. So wouldn't this recommendation mean that I would be storing authorized keys to all my systems (with sudo-enabled users!) all in a single cloud image?

In other words if that cloud image is ever compromised I am royally screwed.

Is this a correct risk assessment or am I not understanding something?

Answer: 
Let's break this down into two questions:

1. How to preserve the session and why storing a hashed password is not a good idea.

Session information which allows a user to authenticate without a password is often stored in the cookies in the form of a "session token". A good session token is an unpredictable string (e.g. cryptographic random) which associates with a user on the server. So in case of cookie leak, it can be used in malicious activity until a user will terminate a session or it will be terminated automatically. PHP frameworks have a default security tools to implement it.

Naturally, a user and a website are exposed to certain threats.

The user, from the one side, can lose control over the confidentiality of his cookies by means of different factors: viruses, browser security vulnerabilities, physical access. All these things are happening from time to time and your mission is to minimize the risk of losing some valuable data. Of course, there might be a virus which will gain a total control over PC or will be logging keystrokes, but there are a lot of less harmful scenarios, where access is limited (e.g. Safari's recent bug with executing arbitrary JS code in any tab)

The website, from the other side, can also have security vulnerabilities like XSS and others which might result in cookies exposure. A funny thing is that **every** web site was or will be vulnerable at some point of the time so the mission is, again, to minimize bad impact.

Now, if we are storing a password in the cookies, we let a hacker who has stolen it to have a permanent access and freedom of info reading or modification despite user logging out (which would terminate old session token if we had one) until a user will change the password.

By the way, giving a user the same session token every time he logs in is the same as storing his passwords in cookies.
2. Why session timeout is a good practice.

Given bad scenarios I've described in p.1, the longer the session is active, the longer a potential attacker can perform malicious activity. So the solution is to limit the life of the session to a "security relevant" timeframe. For example, a banking app will probably log you out after 20 minutes of inactivity. Facebook will store your session for months, but you have an ability to trace all your logins and terminate any active session.

I don't know the specifics of your app, but if it doesn't store any financial or private info, a month for a session to live will be just fine.
Allowing user's to remain logged in for less sensitive access is fine like stated, Amazon does it. However, websites like ProtonMail do not allow this option.

> 
> storing a hashed password in a cookie
> 
> 
> 

This I have an issue with, I can only see two methods for this to work:

1. [Pass the hash](https://en.wikipedia.org/wiki/Pass_the_hash)
2. Treating the hash as an authentication token

Both methods are vulnerable. Pass the hash is essentially the equivalent to storing a plain text password within that cookie file. Instead, use the cookie to store an [authentication token](https://stackoverflow.com/questions/1354999/keep-me-logged-in-the-best-approach). Many approach the token differently, I will use MD5 for demonstration purposes only, please note that it's a *deprecated* hashing function, and should not be used for confidential information. This is a common base idea for implementing authentication tokens *["md5(salt+username+ip+salt)"](https://stackoverflow.com/questions/1354999/keep-me-logged-in-the-best-approach)*. Then you can revoke the session token upon compromise without the need to change the password. Furthermore, you can set the tokens to expire after X days, ensuring old cookie tokens are less likely used to be an attack vector.

People leaving their workstation unlocked is a legitimate concern. You must either use a restrive OS or educate the frontend users about OpSec. Compromised programs accessing and copying the authentication cookies could also pose an issue. And accessing the storage drive (if not using encryption) when powered down. All are legitimate concerns, but training the staff about Operation Security is an important factor.