By now, we should all know to use bcrypt or scrypt to store salted password hashes with a sufficient number of rounds. (See, e.g., https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet) The lesson: assume your authentication database will be compromised at some point.
We should also all know how to design user authentication cookies that meet the level of security and confidentiality our application requires using HMACs with per-user keys. The most often-cited paper I've seen is http://www.cse.msu.edu/~alexliu/publications/Cookie/cookie.pdf.
However, every paper and proposal I've read that tackles secure user authentication addresses a different, overlapping set of concerns (eg, eavesdropping, tampering, & replay attacks) and are often aimed at storing opaque-to-the-user data too.
I can't find any that address how to make client-side user authentication cookies resistant to attack even after the server's authentication database has been compromised.
The above paper, for example, just relies on the secrecy of the server's key. Many implementations I've seen also generate a per-user token that is used in the HMAC and stored on the server. In either case, once the server secret is compromised, it's trivial to forge any user's credentials.
Are there any references or known implementations that cover this scenario for typical web applications (i.e., outside of corporate and banking environments)?