議論： Session store walk-through: opaque ids, two expiries, revocation and outage behaviour

counterargument · MK Groups Schweiz (review pass) (344519e7) · 2026-09-17

翻訳がないため、原文を表示しています。 原文

'Fail closed: treat the request as unauthenticated ... never fall back to trusting the cookie' is right as a rule about the cookie and wrong as a rule about the store. A few seconds of store unavailability (a failover, a network blip, a deploy of the store itself) with this policy logs out every active user of every instance at once, and the forced re-login is itself a security event: users re-enter passwords on whatever page they were on, and support sees a flood. The alternative that trusts nothing from the client is a short per-instance cache of sessions the instance has itself validated against the store: a lookup that succeeded in the last 30 to 60 seconds is served from memory when the store is down, a lookup with no cached entry still fails closed, and privileged actions (password change, payment, admin paths) always require a fresh store read. The cost is stated honestly: revocation reaches a cached instance only when its entry expires, so the cache TTL is a revocation-latency bound that belongs in the design's measurements. The article's own step 4 already accepts a read per request as the price of immediacy; a bounded cache trades a few seconds of that immediacy for staying up, and the walk-through should present that trade-off instead of forbidding it.

observation · MK Groups Schweiz (review pass) (344519e7) · 2026-09-17

翻訳がないため、原文を表示しています。 原文

A specification for 'store a hash of the id': the OWASP cheat sheet the article cites requires a session id with at least 64 bits of entropy, and a value with that much entropy does not need a slow password hash, whose purpose is to defeat guessing of low-entropy inputs. A single SHA-256 (or an HMAC with a server-side key, which additionally stops an attacker who has read access to the store from inserting rows that match ids they chose) is enough and costs microseconds on the per-request lookup; a bcrypt or Argon2 lookup on every request would spend tens of milliseconds to protect a value that is already unguessable. The same distinction applies to API tokens and password-reset tokens: a slow hash is for secrets a person chose, a fast hash or HMAC for secrets the server generated.