Timeouts and Reprompts

At IIW 2008b, one topic was "OpenID UX State Machine Improvements." The discussion centered on best practices for websites around password timeout/reprompt policies. The following is a summary of some of the suggested best practices for website administrators (either stand-alone sites, or sites using federated login).

Website runnings its own login system

Persistent or Session Cookies: When a user logs into your site, you have the choice of setting a session cookie or persistent cookie to identify their account. A persistent cookie is kept on the user's computer even if they restart their web browser, while a session cookie is removed when they restart their browser. Thus, a persistent cookie tends to be more user friendly, and a session cookie has the potential to provide higher security. Many websites let the user decide which type of cookie to use by providing a "Remember Me" checkbox, but even in that case the website needs to decide whether to have the box checked by default, or not. The general best practice for all but the highest security websites (like banks or online health records) is to default to using persistent cookies. The potential security value of session cookies is very small because it requires a user to login on a computer shared by many people (like a web cafe), and be smart enough to close their web browser, but not logout of the OS session, and then requires the next person to notice this fact and decide to do something malicious. The actual reports of this happening are incredibly low as compared to other security problems like malware on web cafe computers, or shared family computers which remember a user's password to make logins easier in the future.

Cookie lifetime: For either persistent or session cookies, it is possible to stamp them with the time they were issued, and then decide to force the user to re-authenticate after a certain time period. For the highest security websites (like banks or online health records), a timeout period of a 1-2 hours is common. For a few other higher security applications (like E-mail) a timeout period of 2 weeks is common. For most any other application, timeouts are generally not needed, though it is good practice to invalidate existing cookies if a user's password is changed (though this can be hard to do on large websites that run across multiple data-centers). It is also good practice to update the timestamps on the user's cookie every time they re-authenticate.

Risk based security: Some applications use more fine grained controls to decide when to force a user to re-authenticate. The most common is that if a user wants to change their password, they usually have to re-authenticate as part of that process using their old password. Other uncommon actions like making large purchases can also be good points at which to force a user to re-authenticate.

Last logins: While it is not common, some websites will keep a persistent cookie in a browser with the names of the accounts that have previously logged into the current website. However, now many web browsers have built in functionality similar to that as part of their password management features.

Website that is a relying party to Federated Login

Last Login: If a user is authenticated via federated login, their browser's password management feature may not auto-fill the required information about their identity provider. In that case, it is helpful to keep a cookie with the user's identity provider and use that as the default value.

Persistent or Session Cookie: If the user's IDP supports invisible logins (meaning they will assert the user's identity back to the RP if the user is already logged into the IDP), then the simplest approach is to always use session cookies to track login state, but use a permanent cookie with the user's IDP, as well as a flag to indicate whether the user had previously manually logged out of the RP site. If the session cookie is missing and the manual-logout flag was not set, then the RP can attempt to do an invisible login via the IDP. Otherwise the RP can show its login box pre-filled with the last known IDP.

Cookie lifetime: If the user's IDP supports an option to force a re-authentication (or require it if the user had not re-authenticate in x minutes) as well as invisible logins, then when the potential timeout period has been met, the user can be redirected to the IDP to see if they have more recently re-authenticated, and if so then the timeout period can be update based on that last re-authentication time. If the user's IDP does not support an option to force re-authenticate, then the RP should do its own "best effort" timeout, and show a login box after that time with the last known IDP entered if possible.

Risk based security: This require's the user's IDP to support the option to force a re-authentication , and if so it can be used as described in the previous "risk based security" section.

Google has a policy of not allowing relying parties to force a re-authentication. To prevent account abuse, it is important for Google users to not become familiar with entering their login credentials in the context of another site. If this became commonplace, it would be much more straightforward for criminals to get users to enter their credentials on phishing sites that masquerade as the Google login page. Additionally, providing the capability to reauth a Google user may become overused and create a bad experience for Google users.