FastMail and sessions

FastMail handles sessions slightly differently to most other web services, and coincidentally I’ve had a few questions about this recently, so I thought I’d write a blog post explaining what we do.

For most web services, the concept of a session is something like this:

  1. A user goes to site http://example.com for the first time in their browser
  2. The server detects that the user has no existing session cookie, so it creates a new session on the server, and sends back a cookie to the browser (simply a string) that uniquely identifies that session
  3. After that, for every page within the example.com domain that the user goes to, the browser sends the cookie back to the server with every request, so the application can get the session data stored on the server

This process is very important, because it allows the server to keep track of things for each user separately, even though they’re going to the same hostname or url path.

Because each cookie is usually associated with a domain, that usually limits you to one session per domain. So for instance when you use google or yahoo, you can only every be logged into one account at a time. There are certain things that work around this, like Mozilla Prism, or Chrome Incognito Window, but these work by creating entirely separate cookie jars, so you can log into different accounts at the same time.

FastMail does things a bit differently. It starts off the same, so when you go to http://www.fastmail.fm, it creates a new session and associated cookie. However when you login to your account, it does two things:

  1. It renames the cookie so the cookie itself has a unique name with a random value (we call this the cookie “salt”)
  2. It redirects you to a new URL that includes the salt value in the URL, and all further URLs as you move around the interface include this salt value

What this means is that if you go to http://www.fastmail.fm and login, and then open a new tab, and go to http://www.fastmail.fm again, you’ll see the login screen again, and be able to login to the same account or a completely different account, and happily access both accounts in the separate tabs with separate sessions at the same time without them affecting each other!

On top of that, FastMail tries to store most “state” information (such as which folder you’re in, what message you’re viewing, etc) in each URL rather than on the server in the session. What this means is that in many places, you can happily right-click a link and select “Open in new tab” or “Open in new window”, and although the newly opened tab/window will share the same session with the original tab/window, they won’t interact with each other.

For instance, if you go to your Inbox and read a message, and then right-click on the “Trash” folder and select “Open in new tab”, you’ll end up with a new tab looking at messages in the Trash folder. You can then switch between the first tab and second tab, moving between folders, reading messages, and neither action will affect what happens in the other tab. (There are a few small situations where this isn’t the case, but these are rarer used functionality, and most people won’t see it)

Session oddities

This difference in approach does result in some things being different to most other websites

  1. If you use the “Long term” login option on the login screen, that doesn’t actually mean you get a long term session (well, you do get an 8 hour session instead of a 2 hour session, but the fact it logs you in automatically forever is separate). Instead a separate cookie is stored on your machine with your username and encrypted password, and each time you go to http://www.fastmail.fm, it creates a new login and new session
  2. Because of browser limits with the number of cookies you can have per-site, if you create many logins and many sessions (eg. open many separate tabs and login separately with each one), then we will start to expire old sessions to avoid you running out of cookies and new session failing. This starts to happen if you have > 10 simultaneous session cookies, we’ll start to expire the oldest ones. This can manifest itself as tabs where you’ve definitely been idle < 2 hours suddenly reporting your session as “expired” on the next link/button you click

Most of the time users don’t need to know about or worry about any of this, things should “just work”, but there are some edge cases where knowing the underlying cause of things can help explain some odd cases.

Posted in Technical. Comments Off

YubiKey Discount for all FastMail Users

FastMail now supports YubiKey.   YubiKey is a hardware-based device that provides two-factor authentication.  Another way FastMail helps you keep your security credentials secure.

To learn more about our YubiKey implementation, read the following post.

As part of our implementation, Yubico is pleased to offer all FastMail users a 25% discount on a Pair of YubiKeys (one black and one white).  Simply enter the name: FASTMAIL in the coupon code upon checkout.

The YubiKey store can be located at: https://store.yubico.com/

Posted in Marketing, News. Comments Off

Yubikey authentication available on production

The Yubikey authentication mechanism we were trialling on on our beta server has now been released to production.

There’s been a few small changes since we first rolled it out on beta.

  1. After feedback from Yubico, we’ve made a few extra internal security improvements. In two-factor mode, the Yubikey one-time value is checked before the password, so a one-time value can’t be reused with the wrong password
  2. On the login screen, you can click the “+ More” link to display the Yubikey login box. Currently the password box will continue to work if you put the Yubikey one-time value in there, but we recommend using the specific Yubikey login box, because the browser won’t prompt you to save the one-time value as a password, which obviously won’t work a second time

We’ve also added some help documentation about Yubikey so people can learn about how it works and how to get one.

Posted in News. Comments Off

ns2.messagingengine.com IP address change

A few days ago, we changed the IP address of ns2.messagingengine.com from 64.34.176.20 to 74.52.187.89. In general, this shouldn’t have affected any users because we tell users to point their domains to our name server records ns1.messagingengine.com and ns2.messagingengine.com.

However we’ve noticed that a few users have slightly esoteric DNS setups where they’ve used the explicit IP address of the old ns2.messagingengine.com server. For those users, you need to update your DNS setup. We highly recommend that if possible, you don’t ever use the explicit IP address, but use appropriate server names or CNAMEs. This allows us to change the IP addresses of ns1 or ns2 without any user changes being required.

Posted in Technical. Comments Off

Restore from Backup

As part of our reliability setup, we take a daily incremental snapshot of all emails and keep them for 1 week. For years, we’ve allowed people to restore emails from our backups by contacting support if they accidentally deleted an email they later realised they needed.

We’re now making this functionality available to all users via an automated interface on the Options –> Restore from Backup screen. You can use this interface at any time to initiate a restore of all emails in your account (including those deleted in the last week) from our backups. For large accounts, the process can take some time, possibly several hours, so please be patient. We’ll email you when the process is complete.

Please read the screen carefully about how the process works, and don’t use it unless you really do need to restore.

Posted in News. Comments Off
Follow

Get every new post delivered to your Inbox.

Join 5,809 other followers