Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117744
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.80.82.1.1\))
In-Reply-To: <628518bb.1c69fb81.1deb1.1bd5SMTPIN_ADDED_MISSING@mx.google.com>
Date: Wed, 18 May 2022 17:37:52 +0100
Cc: internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <86A3AC49-1F82-423A-9E66-B334E947E53B@craigfrancis.co.uk>
References: <CA+XhMqw0YmvwXh_pyQgFZcWC1kO7yBrF5pkAhSzB_eHbABFnUw@mail.gmail.com>
 <62841d87.1c69fb81.82a5.8a18SMTPIN_ADDED_MISSING@mx.google.com>
 <9272E23F-F962-4023-B62D-7A70EA08E828@craigfrancis.co.uk>
 <628518bb.1c69fb81.1deb1.1bd5SMTPIN_ADDED_MISSING@mx.google.com>
To: Mark Randall <marandall@php.net>
Subject: Re: [PHP-DEV] Early feedback on encrypted session PR
From: craig@craigfrancis.co.uk (Craig Francis)

On 18 May 2022, at 17:02, Mark Randall <marandall@php.net> wrote:
> Personally I usually just throw the session key through a one-way hash =
so the original session ID never gets written to a backing store.


Good idea, but that's not done by default.


> I'm not sure why reversible encryption needs to take place?



It might provide privacy (if the attacker can read the session files, =
and they contain sensitive information, e.g. some developers store a =
copy of the users entire record in the session to avoid db lookups)... =
and it might prevent edits being made to the session file.

I would hope both are very rare, but I'm still writing up reports about =
developers doing things like `file_put_contents('/tmp/' . $_POST['id'], =
$_POST['message'])`, so I don't have a lot of hope.

Craig