1
0
Fork 0
mirror of https://we.phorge.it/source/phorge.git synced 2024-12-29 08:50:58 +01:00
phorge-phorge/resources/sql/patches/20130530.sessionhash.php

8 lines
352 B
PHP
Raw Normal View History

<?php
Upgrade sessions digests to HMAC256, retaining compatibility with old digests Summary: Ref T13222. Ref T13225. We store a digest of the session key in the session table (not the session key itself) so that users with access to this table can't easily steal sessions by just setting their cookies to values from the table. Users with access to the database can //probably// do plenty of other bad stuff (e.g., T13134 mentions digesting Conduit tokens) but there's very little cost to storing digests instead of live tokens. We currently digest session keys with HMAC-SHA1. This is fine, but HMAC-SHA256 is better. Upgrade: - Always write new digests. - We still match sessions with either digest. - When we read a session with an old digest, upgrade it to a new digest. In a few months we can throw away the old code. When we do, installs that skip upgrades for a long time may suffer a one-time logout, but I'll note this in the changelog. We could avoid this by storing `hmac256(hmac1(key))` instead and re-hashing in a migration, but I think the cost of a one-time logout for some tiny subset of users is very low, and worth keeping things simpler in the long run. Test Plan: - Hit a page with an old session, got a session upgrade. - Reviewed sessions in Settings. - Reviewed user logs. - Logged out. - Logged in. - Terminated other sessions individually. - Terminated all other sessions. - Spot checked session table for general sanity. Reviewers: amckinley Reviewed By: amckinley Subscribers: PHID-OPKG-gm6ozazyms6q6i22gyam Maniphest Tasks: T13225, T13222 Differential Revision: https://secure.phabricator.com/D19883
2018-12-13 19:52:54 +01:00
// See T13225. Long ago, this upgraded session key storage from unhashed to
// HMAC-SHA1 here. We later upgraded storage to HMAC-SHA256, so this is initial
// upgrade is now fairly pointless. Dropping this migration entirely only logs
// users out of installs that waited more than 5 years to upgrade, which seems
// like a reasonable behavior.