-
Notifications
You must be signed in to change notification settings - Fork 85
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add legacy_hash_algo
to support backward-compatible hash_algo
changes
#351
Add legacy_hash_algo
to support backward-compatible hash_algo
changes
#351
Conversation
I think it is great to have the option for setting a legacy hash algo, so people can smoothly upgrade cookies, thanks! IMO having the algo set together with the cookie doesn't add much value, we could simply try to sign using algo, and if that fails try legacy algo if there is one, if it still fails then fail the check? Another point, it would be nice if when detecting a cookie signed with a legacy algo, a response listener would be registered to update the cookie with a new signature, that way we ensure that cookies get rotated ASAP, and it's easier to say "we set legacy algo for 30days, and after that remove it", making sure that any user hitting the website in those 30days will be fully migrated. Obviously that response listener should be careful to not overwrite cookie removals, or newly written cookies with older values. Finally just thinking of how we can upgrade the default algo, I guess we'd need to trigger a deprecation if algo is unset to make people set it to something else than sha256, and then in the next major we can change the default. |
114f320
to
15ce1d6
Compare
Thanks for the feedback! Updated this PR and removed the changes that added the used algorithm to the cookie value. Also opened #355 to deprecated the default hash algorithm in the configuration for the next minor. The upgrade listener is a bit trickier because the bundle needs extra information (expiration, path, ...) than it gets from the browser (only cookie name and value). The application will need to provide the other options for this to work correctly and securely. I've explored this in #356. |
src/Signer.php
Outdated
for ($i = 0, $j = \strlen($signature); $i < $j; ++$i) { | ||
$result |= \ord($signature[$i]) ^ \ord($signature2[$i]); | ||
$expectedLegacySignature = $this->generateSignature($value, $this->legacyAlgo); | ||
if (hash_equals($expectedLegacySignature, $signature)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah nice, didn't realize we still were using some legacy version of hash_equals here :D
Thanks! |
The goal of this PR is to allow backward-compatible signed cookie
hash_algo
upgrades. With the current code any existing signed cookies would be rejected when thehash_algo
is changed which makes upgrading to a more secure hashing algorithm tricky.This PR addresses this by;
legacy_hash_algo
to support a previously configured algorithm during verification.This is a stepping stone to address #324 but does not yet fix it. Changing the
hash_algo
default value would still break any existing cookies that don't include the hash algorithm in their signed value yet; thelegacy_hash_algo
would need to be configured manually for them to keep working. I don't currently see a backward-compatible way to change thehash_algo
default value without also (potentially) opening the door for downgrade attacks (e.g. by setting a default value forlegacy_hash_algo
or hardcoding asha256
fallback).This PR also adds a
SignerInterface
to allow for custom signers.