8 Replies - 1082 Views - Last Post: 01 October 2020 - 08:02 AM Rate Topic: -----

#1 Splashsky   User is offline

  • D.I.C Addict
  • member icon

Reputation: 16
  • View blog
  • Posts: 629
  • Joined: 25-August 13

Using Cookies for Sessions

Posted 30 September 2020 - 02:47 PM

I already know how dumb it is - that's not the point here. My question for this topic is - when a user logs in, can I store the password they input into their session cookie, and use password_verify() to check it against the hashed password from the database? Is that safe enough for a small-scale project?
Is This A Good Question/Topic? 0
  • +

Replies To: Using Cookies for Sessions

#2 ArtificialSoldier   User is offline

  • D.I.C Lover
  • member icon

Reputation: 2837
  • View blog
  • Posts: 8,206
  • Joined: 15-January 14

Re: Using Cookies for Sessions

Posted 30 September 2020 - 03:15 PM

If you store it in the actual session that's fine, the session is stored on the server. If you put it in a cookie, that's not a good idea, it can be intercepted or gotten hold of through various exploits.

The session cookie only contains a session ID, PHP uses that to look up the actual session data. The session data is stored on the server, not in a cookie.
Was This Post Helpful? 2
  • +
  • -

#3 benanamen   User is offline

  • D.I.C Regular

Reputation: 44
  • View blog
  • Posts: 252
  • Joined: 28-March 15

Re: Using Cookies for Sessions

Posted 30 September 2020 - 06:50 PM

*
POPULAR

Quote

If you store it in the actual session that's fine,


No, it is not fine.

A plain text password should never be stored ANYWHERE EVER. PERIOD!

A hash of the password is the only thing that should be stored and the only place the hash should be stored is in the Database. There is no reason whatsoever to store a plain text password ANYWHERE EVER.

This post has been edited by benanamen: 30 September 2020 - 06:56 PM

Was This Post Helpful? 5
  • +
  • -

#4 Splashsky   User is offline

  • D.I.C Addict
  • member icon

Reputation: 16
  • View blog
  • Posts: 629
  • Joined: 25-August 13

Re: Using Cookies for Sessions

Posted 30 September 2020 - 08:42 PM

So then my implementation would be like so;

- Login, verify password matches hash, create SESSION with user id and a random token that's put in a database
- On every request, verify the token in the SESSION against the one in the database with the same user id
- If it checks out, authorize the user
- If remember me is TRUE, then create a COOKIE with the token and user id, and match it, creating a SESSION upon success

Would that be about right?
Was This Post Helpful? 0
  • +
  • -

#5 Ornstein   User is offline

  • D.I.C Regular

Reputation: 118
  • View blog
  • Posts: 273
  • Joined: 13-May 15

Re: Using Cookies for Sessions

Posted 30 September 2020 - 11:50 PM

As benanamen said, doing this would/could result in passwords being stored on your server in a way that is accessible to an attacker.

Out of interest, what problem are you trying to solve? I'm not seeing what you gain from storing anything like this in the session. Taking your token idea for example, do you plan to invalidate those tokens at some point? (e.g. when a user changes their password or chooses some kind of "log me out everywhere" option and you want to invalidate all existing sessions)

This post has been edited by Ornstein: 30 September 2020 - 11:51 PM

Was This Post Helpful? 0
  • +
  • -

#6 DarenR   User is offline

  • D.I.C Lover

Reputation: 733
  • View blog
  • Posts: 4,725
  • Joined: 12-January 10

Re: Using Cookies for Sessions

Posted 01 October 2020 - 04:30 AM

word to the wise:
google is phasing out the use of cookies.

Google says it will 'phase out' cookies in Chrome in the next two years. Google says it will "phase out" one of the main tools that allows companies to track you across the web. The company plans to eliminate support for third-party cookies in Chrome over the next two years


google cookies
Was This Post Helpful? 1
  • +
  • -

#7 Splashsky   User is offline

  • D.I.C Addict
  • member icon

Reputation: 16
  • View blog
  • Posts: 629
  • Joined: 25-August 13

Re: Using Cookies for Sessions

Posted 01 October 2020 - 05:46 AM

I want to implement "remember me" for logging in. But if cookies will eventually be disabled, how would I go about it?
Was This Post Helpful? 0
  • +
  • -

#8 CTphpnwb   User is offline

  • D.I.C Lover
  • member icon

Reputation: 3844
  • View blog
  • Posts: 14,019
  • Joined: 08-August 08

Re: Using Cookies for Sessions

Posted 01 October 2020 - 07:23 AM

View PostDarenR, on 01 October 2020 - 06:30 AM, said:

google is phasing out the use of cookies.

Since Google makes its money by tracking you, this is ominous. It seems highly likely that whatever they replace cookies with is going to be far more intrusive.
Was This Post Helpful? 0
  • +
  • -

#9 Ornstein   User is offline

  • D.I.C Regular

Reputation: 118
  • View blog
  • Posts: 273
  • Joined: 13-May 15

Re: Using Cookies for Sessions

Posted 01 October 2020 - 08:02 AM

Importantly, it's third-party cookies which are being phased out. ;)

For the ol' "remember me" login option, it should already be apparent that nothing you store in the session will be of much use to you here? Given that once the user has lost the session cookie, that data is lost to the void - and by extension, cannot be used to re-authenticate them.

There's obviously the usual (arguably recommended) option of using some existing package/library. If you're using a framework, it may already support this (I believe Laravel's authentication package does).

If you do want to implement this yourself - or just understand the process better - you should be able to Google around for some (up-to-date) suggestions on the best ways to do so; there's a lot of traps you might accidentally walk into, some tricks you can use for extra security, etc.

It will likely end up looking something like this:

To create a cookie for re-authenticating a user...

1. Generate a cryptographically-secure random string.
2. Either generate a second cryptographically-secure unique identifier - or use an otherwise suitable publicly-available identifier - for the user. Really you should only need to do this once (e.g. at registration), but you may choose to refresh it every time instead.
3. Hash the string from #1.
4. Store the identifier from #2 and the string from #1 in the cookie. (Make sure the HttpOnly flag is set on the cookie)
5. Store the hash from #3 and the identifier from #2 on a table in the database.

To re-authenticate a returning user...

1. Get the identifier and the random string from the cookie.
2. Use the identifier to look up the appropriate row in the database.
3. Hash the random string from #1.
4. Verify the hash from the database against the hash from #3 (being wary here of timing attacks i.e. use something like PHP's hash_equals function).

Obviously you only need to do this re-authentication if no session exists; you don't need to do it on every request.

To briefly cover what all of this is meant to accomplish: The random string is obviously the "token" of sorts. The reason for storing it as plaintext in the cookie and hashed in the database is so that an attacker with read access to the database cannot craft a cookie to log into user accounts. The reason for querying the row using an identifier (instead of just using the hash) is to avoid potential timing attacks when querying the database.

There's other layers of security/assurance you could wrap around all of this. You may want to consider things like having tokens expire / be refreshed at appropriate times, for example.

Feel free to ask any followup questions.
Was This Post Helpful? 3
  • +
  • -

Page 1 of 1