Today marked the start of Daylight Saving Time (DST), the day of the year with the most missed airline flights.1 There's an esoteric ASP.NET issue that centers around Daylight Savings, and affects websites both at the very start of Daylight Savings and at the very end. ASP.NET's forms authentication feature assigns a forms authentication ticket to a user once they sign in, with the ticket serving as an identity token. This ticket is, by default, stored as a cookie on the user's browser and is sent back to the web server on each subsequent request to the site until it expires. The ticket's expiry is specified both in the Set-Cookie header and within the ticket itself. The expiry specified within the contents of the ticket is an absolute time that the ticket expires in terms of the web server's time zone. Can you see the problem? When DST starts or ends the expiry in the ticket remains constant, but the web server's clock is shifted. For a person signing on right near the start or end of DST, the the ticket is either rendered expired an hour earlier than expected or an hour later than expected.
I describe this issue in Forms Authentication Configuration and Advanced Topics, one of the tutorials in my Website Security Tutorials series:
The expiry stored in the authentication ticket is an absolute date and time value, like “August 2, 2008 11:34 AM.” Moreover, the date and time are relative to the web server’s local time. This design decision can have some interesting side effects around Daylight Saving Time (DST), which is when clocks in the United States are moved ahead one hour (assuming the web server is hosted in a locale where Daylight Saving Time is observed). Consider what would happen for an ASP.NET website with a 30 minute expiry near the time that DST begins (which is at 2:00 AM). Imagine a visitor signs on to the site on March 11, 2008 at 1:55 AM. This would generate a forms authentication ticket that expires at March 11, 2008 at 2:25 AM (30 minutes in the future). However, once 2:00 AM rolls around, the clock jumps to 3:00 AM because of DST. When the user loads a new page six minutes after signing in (at 3:01 AM), the FormsAuthenticationModule notes that the ticket has expired and redirects the user to the login page. For a more thorough discussion on this and other authentication ticket timeout oddities, as well as workarounds, pick up a copy of Stefan Schackow’s Professional ASP.NET 2.0 Security, Membership, and Role Management (ISBN: 978-0-7645-9698-8).
Happy Programming!
[1] This is a total guess, but based on some emperical evidence from a sample size of one. Back in 2001 I would have missed a flight on the day Daylight Savings Time started had my girlfriend at the time (now my wife) had not called me that morning to ensure that I was aware of the time change.