0

To become a more well-rounded developer, having a better understanding of security concerns and best practices will help me endeavor to build web-apps that are both user-friendly as well as secure.

I'm currently working with cookies using PHP for a login script and have heard that storing a hashed password in a cookie is not a good practice. The only scenario where I thought this would be an issue would be if someone left their computer unlocked and an intruder was able to impersonate the computer owner during the login process. I told him Amazon does this- where users are logged into their account while they shop for things- but my friend countered, citing how Bank of America kicks the user out after being idle for a few minutes.

I Googled my question where I found only implementation methods instead of providing different scenarios of how staying logged in would be a bad thing.

  • The pros are that they'll interact more with your site, the cons are that anyone with access to the computer can act as that person and can commit fraud. If your service is interaction based, and low fraud risk, keeping users logged in might make sense (Amazon, Stack Exchange). If interactions are brief, and fraud risk is high, you should log users out (Banks). – Steve Sether Jul 19 '18 at 16:47
  • Could you please describe in pseudo code the authentification algo? – curiousguy Jul 19 '18 at 19:43
  • @curiousguy what do you mean? like describe in words in how the user would be authenticated? – hnewbie Jul 19 '18 at 20:12
  • Describe 1) how the cookie is generated from the password and 2) how the authentication is done using the cookie value. – curiousguy Jul 19 '18 at 21:53
2

I'm working with cookies in PHP for a login script and my friend thinks storing a hashed password in a cookie is bad news.

Your friend is absolutely correct, there is no reason to do this. It's not a matter of staying logged in, it's a matter of needlessly exposing the password hash (side note: please use PHP's password_hash function for hashing passwords).

While exposing the password hash over an encrypted connection (you are using HTTPS aren't you?) isn't the end of the world, the real problem is that it indicates to me that you're probably authenticating sessions by comparing the cookie's value against the stored hash. This means you have no way to invalidate session cookies, if the password hash is ever exposed, that's all an attacker needs to access someone's account!

Use PHP's built-in session management, which uses a sufficiently long random value to keep track of users (at least in recent versions, old versions have had problems with this).

To answer your original question of how long sessions should last, it varies wildly. My desktop is indefinitely logged into my Gmail account, but most bank sites expire sessions after 15-30 minutes of inactivity. For a site that doesn't have anything too important, long lasting sessions are fine, though it's good to allow users to see existing sessions on their account and expire them manually.

| improve this answer | |
  • the application will go on a web server with HTTPs, but I'm actually not authenticating sessions by comparing the cookie's stored hash. I'm authenticating the session by comparing hashed password in a database. I just started using cookies, I'm just trying to figure what they are good for, other than...authentication and storing preferences. I guess I conflated using cookies as allowing users to stay logged in. Sorry! The initial question was to find out what the pros and cons of allowing users to stay logged in an application. – hnewbie Jul 19 '18 at 16:48
  • "I'm authenticating the session by comparing hashed password in a database" - Isn't that what I said? You're comparing the value from the cookie against the hash stored in the database? – AndrolGenhald Jul 19 '18 at 16:52
  • I'm not using the cookie value... I'm using what the user enters into the password field and comparing that with the hashed password stored in a database. – hnewbie Jul 19 '18 at 17:03
  • They don't type in a password every time they load a page though, that's what cookies are for. How do you authenticate the cookie? What's the purpose of the cookie containing the password hash? – AndrolGenhald Jul 19 '18 at 17:06
  • 1
    That depends what you mean by "automatically log someone in." If you just mean that when you visit the site tomorrow you don't have to log in again, then cookies are the correct solution, you just have to use them properly. – AndrolGenhald Jul 19 '18 at 17:43
0

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
  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. 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)". 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.

| improve this answer | |
  • Did you read the "Security Notice" at the top of that answer? There are several problems with it, even if you (ab)use a secure hash like SHA256. Session cookies should be generated from a CSPRNG. – AndrolGenhald Jul 19 '18 at 16:55
  • Yes, I read it. I was providing additional material for reading without repeating a thread otherwise, this thread would need to be closed. Also, I was intentionally vague about how to implement and instead gave ideas concerning security. So readers can access a thread this has already been heavily debated on. Simply throwing in CPRNG when the user needs more background knowledge will not help anyone grow their knowledge and wisdom. – safesploit Jul 19 '18 at 17:07
0

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.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.