Is session ID hashing more secure than plain storage?

Question

I have a PHP/MySQL app where I store session data in my database. Here's some pseudocode for the relevant handlers:

function session_read($sessionId) {
    $result = query('select session_data from sessions where id = ?', $sessionId);
    if(!$result) $result = array('session_data' => '');
    return $result['session_data'];
}

function session_write($sessionId, $data) {
    query('replace into session_data set data = ? where id = ?', $data, $sessionId);
    return true;
}

It occurs to me that for the duration of a session, that the session ID can be as sensitive as a user's password. I am wondering if hashing the session ID before evaluating it would afford additional security?

function session_read($sessionId) {
    $sessionId = hash('sha512', $sessionId);
    $result = query('select session_data from sessions where id = ?', $sessionId);
    if(!$result) $result = array('session_data' => '');
    return $result['session_data'];
}

function session_write($sessionId, $data) {
    $sessionId = hash('sha512', $sessionId);
    query('replace into session_data set data = ? where id = ?', $data, $sessionId);
    return true;
}

In this way, even if an attacker managed to retrieve a dump of the sessions table they would not easily be able to craft a cookie to hijack any user sessions.

Is this a useful practice?

EDIT: The site is served over HTTPS, and the cookie is HTTPONLY.

Answer 1

If the database is compromised, and you always hash the user's session ID value before using it in the database, then yes this does make it more secure. This assumes the extent of the database leak is only view access to the session table. If they have write access, or access to manipulate the PHP source, all bets are off.

The more important thing to worry about is ensuring the session IDs are generated randomly so they cannot just brute force or otherwise guess what a valid session ID is. So no sequential session IDs, nor IDs generated from weak PRNGs (earlier versions of PHP were afflicted by this) or other easily deterministic values such as time.

Depending on your setup, you may wish to restrict the session ID to the IP address of the user at the point the session started. This helps protect against session IDs being leaked by the user, either inadvertently through poor session handling (eg some servers rewrite URLs to include session IDs, which can then be leaked in http referrer headers), or malware on the users device. This has it's own share of pros and cons; an attacker can't exploit any session IDs that they find without coming from the same IP. However if your users are behind some interesting load balancing setups them their session can legitimately come from several different IPs and placing an IP restriction in this case would deny them service.

OWASP provides an in-depth summary of more session do's and don'ts: https://www.owasp.org/index.php/Session_Management_Cheat_Sheet

Answer 2

I am wondering if hashing the session ID before evaluating it would afford additional security?

Yes, it does. But only for the case an attacker can only read arbitrary data from the database, eg, via an SQL Injection, and wants to hijack an active session. In that case finding the input value (ie, the transmitted session ID) of the hash function's output value (ie, the stored session ID) would constitute a pre-image attack . And one major goal of cryptographic hash functions is pre-image resistance .