This is Signal vs. Noise, a weblog by 37signals about design, business, experience, simplicity, the web, culture, and more. Established 1999 in Chicago. Follow us on Twitter for more information on our products.

My guess is that it dates back to some framework from way back. People usually stick with the defaults.

The first site I remember doing that was GMail. My guess: one week was too short and three weeks was too long.

David, when you created the ruby asset pipeline you set something about 7 felt right, but 8 was too much… or something like that.

Somewhere along the line some idiot middle manager (at a popular site) probably said… “Let’s let the user not have to sign in all the time, but you know what, not forever, so only allow them to sign in for awhile.” (The middle manager would not have actually said how long, because that would entail him making a decision, middle managers don’t do that).

Then some programmer, who had to program the thing thought, well, what feels right… 1 week is too short, 3 seems to long, so i will go with 2 weeks. That went up on that popular site, others saw it and were like we need that too. And everyone started doing it.

Glad you thought enough to remove it from your stuff, and just go with “keep me signed in”. Hopefully others will see the stupidity in it as well.

Some guy may have thought that people were afraid to be signed “forever”? (back in those times were internet was frightening, with all those evil cookies ready to stab your PC)

I think that is the reason why Google beat Yahoo back in the day.

The amount of times I wanted to use Yahoo (e.g. mail) and couldn’t remember my password, and didn’t have it handy, and I ended up going to Google cos I knew the cookie would work.

One week too short, 3 weeks too long according to what? It really must have been arbitrary, I don’t think Google went all “lets test 41 shades of blue” on it, if they really where the first ones. It must have been an engineer that thought it was a good idea to limit it an some managers agreed.

I agree that it’s mostly cargo-culting when you see it – but I’d be fascinated to see an actual study on how that option changes anyone’s behavior (as opposed to the other options: no choice at all, choose to stay signed in forever, sign out all the time, never sign out, etc).

I wouldn’t be surprised if the rational is something like “well, asking someone if they want to stay signed in FOREVER might scare people because of privacy/security/whatever fears…let’s reassure them that it’s less permanent by only making it two weeks”. I’m not sure there’s any validity to that thinking, but that’s my guess about why whoever first came up with this chose to do it that way.

OK, so maybe periods longer than 2 weeks would cause users to forget their passwords?

I think Matt is probably right. If Google ASKED users ahead of time, the users probably said stuff like “don’t leave me logged in forever, thats too scary!” But the reality was that when they started using the app, they complained about having to log in each day, so the setting got pushed out to a point where they weren’t asked to log in enough to piss them off, but it felt a little “safer” than a permanent login.

I would think that it has to do with resource management on their end for maintaining “active” accounts. Maybe 2 weeks is a safe default for refreshing account information so the resource doesn’t bloat to the point of crashing the system.

I’m just guessing at this as I have no knowledge of how these things work but it sounds good doesn’t it?

I’m pretty sure that the origin of this was (at least partly) technical in nature, not (merely) the whim of some engineer or middle manager.

The issue is that when you allow for cookie-based logins that don’t expire, you must keep every login cookie that is created in your authentication database forever. And those cookies have a way of piling up quickly. Every time a user clears the cookies on their computer, or uses a different browser or computer or mobile device, a new cookie must be created. But you also must hang onto all of their old cookies too, otherwise every time they sign in via a new device, it would log them out everywhere else (which would be infuriating).

Back in the days of more limited storage and computing power (i.e. just a few years ago), keeping all the authentication cookies around and letting them pile up would lead to a painfully slow authentication system as the database size kept growing and growing with the continuous stream of new login cookies. By setting the login expiration for something like 2 weeks, it ensured that users wouldn’t have to log in every time they visited your web app, but that the authentication db wouldn’t grow to an unwieldy size either.

If you make the assumption that everyone seems to be making about “forever” posing a faux security concern, and constant re-credentialing posing an annoyance that would drive people away, they you’re left with logical increments of daily, weekly, bi-weekly, and monthly. Any longer may well be perceived as “forever”. Daily is practically the same as for each session. Monthly is so long that it risks users forgetting their passwords in between sign-ins. That leaves weekly and bi-weekly, and to me if you’re going to go this route it’s a toss-up, so go with the longer one.

Of course, the entire concept is just plain silly. There are plenty of sites that I sign up for, use heavily for a week or two, then abandon for a few months before I need them again. Then I need to go through the annoying “change password” process. Countless hours wasted… all while working on the same machine in the privacy of my home.

I don’t mind it for banking or investment sites or other things that I need to make sure are secure for my personal purposes, but the majority do not fit this case at all.

I think my first encounter was with Gmail.. It probably caught on…

Easy stuff guyz! The 2 weeks duration comes from the Fortnight unit, which is some kind of old english for 2 weeks.

A single Fortnight is 1209600 seconds, or 1209600000 millisecond, which was a technical limit in some older systems.

Trust me or not, I do not provide any references to that ;-)

@Brent This can be easily solved by adding a cryptographic hash to the cookie. This allows the server to send and forget the cookie and still verify it’s authenticity each time it encounters one.

In TCP it is used with SYN cookies since 1996.

If verifying the hash with each request puts too much strain on the server this can even be combined with a session cookie. This would allow the server to verify the hash once uppon each visit but use the temporary cookie for the rest of the page loads in the same session.

It would be interesting to know whether the `original` implementation did really expire the session identifier as some kind of security measure or simply set the expiration date for the cookie – which would really make this a pointless annoyance.

It’s likely a security semi-concern. For some systems, a login shouldn’t last very long, because if you need to remove that user’s access, they shouldn’t be able to access anything. Say you have a website with payroll information to which an employee has admin access, and that employee leaves the company. If they’re still logged in with their cookie, nothing is stopping them from accessing the system even if their login has been deleted. The two-week limit probably arose at some point as a compromise between security and convenience.

@37signals

So how long are your cookies set for?

Perhaps they worried that if they set it to forever, users might lose the password to an accout they use all the time and be unable to access it without the cookie.

Maybe some sites could have two radio buttons, instead of a checkbox:

Keep me logged in
( ) for two weeks
(•) until I say otherwise

That way you avoid scary words like “permanently” and “forever”.

All cookies used to seem like they were set ‘forever’ just a few years ago.

Then there were some reports about public computers (cafes, campuses) running into issues of users forgetting to sign out, and nasty things being done to/from their account.

How 2 weeks was picked, I don’t know, but I do remember Yahoo! being the first company I noticed doing it.

Remember the guy who invented the question mark? Same guy invented this standard…

Why does your credit card have an expiry date? Your passport?

It’s standard security practice that any credential needs to expire. The longer a credential exists, the bigger the window is for it to be stolen and used against you.

Browser exploits that lead to the ability to steal cookies across domains are pretty common. Cookies are stored in a plain-text file in a semi-predictable location that could be lifted by any number of other security bugs. If somebody steals your GMail cookie, they have a less-than-two-week window in which they can read your email. This is bad, and might lead to deeper exploits if there’s some way to find your password by searching your email, but it’s much better than them being able to read your email indefinitely.

Ideally passwords would expire too, but in practice expiring them leads to people choosing more easily guessable passwords, so the solution leads to a less secure situation than the problem it was trying to solve.

I suppose it’s to force people to re-enter the password. If someone steals or borrows your computer he’ll only be able to snoop on your web service accounts for no more than two weeks.

It’s an awkward compromise between (perceived) security and usability.

This is a loaded question. It doesn’t have to have had one single origin.

What I saw is that iWork says “Two weeks” in letter while iCloud says “2”.

Remember Apple had love with Digit 2 always. So it should be the reason then kept 2.

I was thinking you guys would also be disappointed that the iCloud login is like a badge for big company/government people. Kinda corporate, I thought.

I never thought about it before, but it annoys me.

Is there any reason to log a client out of most websites? The only one I can think of is a bank or something, but even then…

You can login anytime you want, but you can never leave.