Is It Secure to Store a Password in a Session

Is it secure to store a password in a session?

Keeping plaintext passwords anywhere in any capacity is usually a bad idea. Sessions are safe as such, but only as safe as the rest of your server environment. Administrators or other users both legitimate and nefarious may have access to data stored on it. You never want to handle the secrets of your customers if you can avoid it; that also means you want to avoid seeing the user's password under any circumstances and you should build your code in a way that the plaintext password is as short lived as technically possible.

If you need to use the password for something during a session, you should architect your app so it never uses the plaintext password, but use a key derivation function to derive a key from the password which you then use for your sensitive tasks. This way there's a lot less chance to expose the user's password. Remember, the only security the user has is the secrecy of his password that only he is supposed to know.

How 'exposed' do you store a password in a session?

Why would you need to store the user's password in the session at all? I can't see any particular need for it, and it's just creating a potential security risk for no reason at all.

Instead, just store the username and, possibly, a flag stating that the user has been authenticated. Of course, you should clear the flag (and/or just wipe the entire session data) when the user logs out, so that an attacker who somehow gets access to old session cookies can't resume the session after logout.

You may also want to store a "last access" timestamp in the session, so that you can let old stale sessions time out. Or you could rely on your session framework's built-in session expiration behavior, but it may still be a good idea to have a backup mechanism fully under your app's direct control.

Ps. Obviously, whatever you do, make sure your session identifiers are generated using a cryptographically secure random number generator (e.g. Crypto.Random.random), and that they're long enough to be unguessable (at least 64 bits = 16 hex digits, although 128 bits is better). If, for some reason, you can't do that, an alternative is to generate such a random token yourself, store it both in the session and in a cookie, and verify that the session and cookie tokens match before using any actual session data.

Most secure way to temporarily store a password

Separate the password encryption key and the encrypted password:

1. Generate and store a random key (and nonce / salt)
2. Encrypt the password (e.g. AES-256-GCM) with the random key
3. Store the encrypted password on your backend
4. Send the random key with the request to temporarily decrypt the password
5. Delete the encrypted password on the backend when the session expires

That way:

• The random key stored in the browser can only be used within the current user session and is useless on its own
• The encrypted password on your backed can only be used with the random key stored in the browser and is useless on its own

Is it secure to store passwords in cookies?

It's NOT secure to store passwords in cookies because they are available as plain text.

A good place to find some answers about cookies is Cookie Central. For membership usually is used a cookie with a long string called 'token' that is issued from the website when you provide your user name and password. More about the process you can find in this article.
When using forms authentication in ASP.NET you can set the authentication cookie like this:

FormsAuthentication.SetAuthCookie(userName, isPersistanceCookie);

The second parameter is used for "Remember Me" functionality - if true it will create persistent cookies that will last after you leave the site. You can also programatically manipulate the cookie like this:

HttpCookie authCookie =
  HttpContext.Current.Request.Cookies[FormsAuthentication.FormsCookieName];

Can I securely store username and password in PHP session variables?

As long as you're not storing session state on the REST API server, only on your client webapp, it seems fine from an architectural point of view.

If you really must use the username and password and can't get a disposable token, you may encrypt them with a server-side key, and decrypt on-the-fly when you send them to the API, so even if someone can hijack a session they can't obtain the username and password without the server-side key, but you should be a lot more careful with leaking your php session anyway.

PHP Session Security.

Follow the steps outlined in the answer for that question, except that you should use HTTPS for all interactions, between the user and the webapp, and between the webapp and the REST API.

Store password hash in session. Good Idea?

1. The scenario about simultaneously changing the password sounds extremely rare and not a core premise to build a session architecture around. The scenario can also be better prevented with optimistic locking and other concurrency solutions.
2. You can invalidate sessions when a password is changed explicitly, you don't need to store the password in the session for that. This is trivial if you use a database to store sessions (preferably an in-memory database like Redis or memcached), but it's not impossible using standard PHP file-based sessions either. Just proactively nuke all active sessions by the given user when the password is changed, done.
3. The password is a secret and should stay out of circulation as much as possible. The hash is just a shadow of that secret, but even it you should keep secret. Storing it in the session is one step closer to accidentally leaking it than it would be when keeping it purely in the database.
4. There is a performance impact of doing a database lookup on every single page load.

Is storing login and password hash in session secure?

Storing a password hash is secure whichever way you go. The idea of hashing the password is so that it can't be reverse engineered into the password. That is why hashed passwords are recommended practice and commonly stored in databases (ie ASP.net membership provider). Youc an use encryption, but IMHO that is less secure than hashing.

Storing a hash password in session state, either inProc, sqlserver or session server is fine. Storing the raw password should be a hanging offence.

You would avoid exposing the hashed password to the world either via form or url information as SHA1 has been determined to be insecure. I would recommend SHA256 but in any case don't publish the hash.

I would be wondering why you want to keep this information at all. I can't think of any value it has. Once the password has been hashed, it can't be used to re-authenticate the user onto a different site.

---

Related Topics