1

So I have my database with the standard usernames and hashed passwords (password_hash).

There's a login form on my site, where users type their details and a session gets created based on that.

<?php
    session_start();

    //if the username and password is valid 
    if(validLogin){
        $_SESSION['account'] = $username;
    }

    //$_SESSION['account'] is used from now on for backend user activities

?>

If the credentials are correct, an account session variable is created pointing to the username.

I have increased Session lengths to 1 month (as users complained they kept getting logged out before)

What can I do to increase security here?

If I go into Dev Tools, there is only a single cookie called PHPSESSID, which holds a 26 character value.

However, anyone can just copy and paste that value into their own browser and hijack someone's account - if they had the value.

I am not sure what to do and quite lost.

How can I improve the security here? Besides logging out users every 24 minutes

fewjio
  • 15
  • 7
  • 2
    *"if they had the value"* - Sure, they can also login to the user's account anytime they want by using the user's password... if they had that value. Users shouldn't share those values. Encourage your users to not stay logged in on public workstations, for example. If someone *does* get that session ID then the primary line of defense is its time limit. Which is why *1 month* is a bit excessive for a session timeout. 20 minutes is common, users should expect to be logged out if they don't interact with the site for some time. For really demanding users, 1 day should really be the max. – David Feb 17 '21 at 01:00
  • You can also add a rotate IP control: save the user's IP at login, and after that check in every page load if client IP remains the same or has changed. If changed, you can force logout the user. – José Carlos PHP Feb 17 '21 at 01:02
  • @David Thanks for the input. The majority of sites I use (small/medium sites) keep me logged in for around a month, even if I haven't used it in a while. How are they able to do so, whilst maintaining security - for example, sites like Notion – fewjio Feb 17 '21 at 01:04
  • @JoséCarlosPHP That would prevent the user from being logged in on more than one device though right? As an alternative, I could go for that approach though however. Is there a specific way to force log them out, or do I just run `session_destroy()` – fewjio Feb 17 '21 at 01:06
  • 1
    @fewjio: One approach I often see is a "trust this computer" checkbox during login. That could differentiate between a long-lived cookie and a short-lived cookie. – David Feb 17 '21 at 01:07
  • Side note: What you're describing has nothing to do with CSRF. While CSRF is an important thing to learn about and handle, it's an entirely different security concern and mixing the two will only confuse you. – David Feb 17 '21 at 01:09

1 Answers1

1

Firstly, The concept of a session (originally) implied:

The session begins when you open an application, continuous as long as you work on it, and ends when you close the app.

Since the nature of apps changed and for convenience reasons, this basic pattern has been extended, and sessions kept alive much longer, even if the user is not actively working on it. However, if security is your main focus use a more strict approach, i.e. shorter expiration time and forced logouts.

Secondly, PHP sessions have been invented to solve many of the problems that plague regular browser cookies (stored on the client as text, limited to 4KB, rather accessible, sent along with every request, hence bloating the HTTP request). A PHP session only sends a hashed ID to the browser, and stores all data on the server. If an attacker owns the client security is indeed compromised. But this may be out of your hands if you cannot control the client device security. Security is a multi-layered concept that implies varying degrees of trust..

This answer gives more context on PHP session security and has some useful security recommendations. However, I have one additional recommendation: If you do not need to work with the PHP session id in your client code (i.e. JavaScript) disable session.cookie-httponly in your php.ini (or alike).
If this all is not 'good enough' you will need to implement a more secure protocol, use multi-factor-authentication, or alike. In general, session ids are probably your least concern; having a properly configured web server and following best practices is more important.

wp78de
  • 18,207
  • 7
  • 43
  • 71