Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:117743 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 81164 invoked from network); 18 May 2022 14:22:10 -0000 Received: from unknown (HELO localhost.localdomain) (76.75.200.58) by pb1.pair.com with SMTP; 18 May 2022 14:22:10 -0000 To: internals@lists.php.net Date: Wed, 18 May 2022 17:02:56 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Content-Language: en-GB References: <62841d87.1c69fb81.82a5.8a18SMTPIN_ADDED_MISSING@mx.google.com> <9272E23F-F962-4023-B62D-7A70EA08E828@craigfrancis.co.uk> In-Reply-To: <9272E23F-F962-4023-B62D-7A70EA08E828@craigfrancis.co.uk> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Posted-By: 149.241.131.223 Subject: Re: [PHP-DEV] Early feedback on encrypted session PR From: marandall@php.net (Mark Randall) Message-ID: On 18/05/2022 16:23, Craig Francis wrote: > If the Session ID continued to work as the Identifier, but the client was given the Session ID and a Random Key (could be concatenated together for the cookie)... that means the Random Key would not be stored on the server, and could protect the session if there was a vulnerability on the server/website (e.g. attacker being able to see the directory listing of session files)... I'm not sure how much of a benefit that will actually provide, vs the risk of it going wrong (e.g. future PHP changing encryption algorithm). 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. I'm not sure why reversible encryption needs to take place?