Before July 2011, FetLife.com users were vulnerable to trivial attacks that could completely and irrevocably compromise their privacy. When considering that FetLife’s content often contains highly sexual and thus extremely personal information and the fact that practically all of FetLife’s content is intended to be viewed only by logged in users, it feels even more important to show how “the emperor has no clothes” on FetLife than it does on sites containing less sensitive content. Although I don’t think FetLife acted maliciously, I do think they’ve neglected to adequately protect their users.

(Watch a .mov video of the unmitigated issue as it existed in June 2011. Read a text transcript of the voiceover.)

In order to avoid further risking the privacy of FetLife users—including myself!—I sent FetLife an email on June 14 at 10:57 PM informing them of what I saw and asking them what they planned to do to resolve or at least mitigate the severity of the issue. My email conversation with FetLife is published at the very end of this post. The short version: after my repeated insistence, they took some steps to mitigate (but not exactly resolve) the issue.

I’ll make post-publication updates and clearly mark edits to this post when or if FetLife (or, more accurately, BitLove, Inc., formerly Protose Inc.) addresses the issues discussed here further.

Update, August 17, 2011, 3:53 AM local time: Within a week of this post being published, FetLife announced its SSL support was in the works. They then began rolling out site-wide SSL, beginning with paid subscribers (“supporters”) yesterday, and also turned on the feature for my own account early. Earlier tonight, I noticed the remainder of my various (non-paid) test accounts also got switched to SSL. (Yay!) I haven’t had a chance to look at the site again in any technical depth, but I’m very pleased to see this change.

Update, December 20, 2011, 5:08 AM local time: In a comment, Ian reports that the switch FetLife made to a CDN as part of their migration to site-wide SSL caused a new problem: all of your FetLife profile images are publicly viewable, no login required. This is confirmed.

This post is split into sections. I wrote a plain-English summary describing the issues, their severity, and mitigation in language I tried to keep so simple everyone can understand. The Technical Details section provides another analysis with a step-by-step demonstration, along with references to background information for the technically interested but uneducated reader. Finally, an Editorial section is where I’ll get on my well-worn soapbox about this whole thing.

Plain-English Summary

Due to the way FetLife handled your login status, an attacker monitoring your computer could secretly gain permanent, full, and irrevocable access to your FetLife account simply by observing your browser fetch any page on FetLife.com while you were logged in.

If this happened to you, it meant an attacker could do anything on FetLife that you could, as though they were you. For example, an attacker could be able to:

  • log in as you, whenever they want to
  • read your private conversations, and view all your photos, including the ones you have set to “friends only”
  • view all private photos your friends shared with you
  • post status updates, comment in group discussions, write entries, and upload images as if they were you
  • edit your profile and fetish list
  • send anyone on FetLife a friend request as you, or remove friends from your friend list
  • change all of your account settings, including your FetLife password and email address

There’s only one thing the attacker couldn’t do: find out what your original password was. To the best of my knowledge, this issue affected FetLife.com from its inception several years ago until last month.

After my prodding in June, FetLife changed the way it handles your login status so that an attacker couldn’t retain secret access to your account for more than one month. They also made changes that help prevent an attacker from locking you out of your own account.

How was this possible?

When you log in to FetLife, your browser is sent a “session cookie” that acts like a special key intended only for you. As you use the site, your web browser presents this special key to FetLife every time you load a page. Using session cookies is not bad per se; it’s standard practice, and ensures you don’t have to type your password each time you click another link.

However, since FetLife doesn’t send you this cookie privately, it’s very easy for someone else to get a copy of it. If they do, they get to use it just like you did, and there would be no way for you to find out if someone has done that. Worse, since FetLife didn’t put even basic limitations on the cookie, other people could use their copy of it forever, from any computer, even after you logged out or changed your FetLife password, and there was nothing you could do to stop them.

Thanks to the changes FetLife made last month, changing your password will allow you to regain control of your account from an attacker who may be using your special key (session cookie). Naturally, I’d suggest you change your FetLife password from your home Internet connection as soon as you can. (Do not change your FetLife password at a Wi-Fi café, though! See below.)

But FetLife says they’re secure!

FetLife says they “use SSL to login to FetLife,” which is “the same technology your bank uses when you login to their website.” It’s true that this does mean your user name and password can’t be (easily) stolen while you are logging in. (Your user name and password can, however, be easily stolen when you change your password, since FetLife doesn’t use SSL for that—an equally glaring oversight making the point rather moot anyway.) But since the session cookie (your special key) is not returned to you using SSL, an attacker never needs to see you log in and never has to know your password to gain virtually total control of your account.

Moreover, there are numerous other ways an attacker could get a copy of your session cookie and your special key, ways that not even using SSL can protect you against. One way would be by tricking you into visiting a different, malicious website that could then watch as it makes your computer visit FetLife.com behind your back. And if anyone else has access to the computer (e.g., a family, library, or frenemy’s machine) they can easily save a copy of your session cookie and use it later.

FetLife also says that “at any time, you can delete the cookies that are on you [sic] computer.” This is true, but irrelevant; you can’t delete a copy of a cookie on someone else’s computer.

Mitigation: How can FetLife fix this and what can I do to protect myself?

There are a number things FetLife can do to address the issue, either by more strongly securing the communications between you and FetLife.com or by limiting the usefulness of the special key they give you (i.e., the session cookie). While no single item is a panacea, each significantly reduces the threat. (This is known as “defense in depth.”) So, while FetLife deserves some (faint) praise for finally taking some steps to protect its users, FetLife would take all reasonable steps as soon as possible to maximally protect you if it is, indeed, a priority for them.

First, FetLife could use SSL for everything (not just logging in), so that even if an attacker does see you load some page, they can’t get your key. This is also called “SSL-only browsing” and has long been recommended to be enabled by default for everyone. While they are late in doing so, to their credit, FetLife told me they are working on making this happen in “60-90 days.” If implemented correctly, this will protect you against the simplest (and thus most common) attacks, but not all of them.

Second, FetLife could do a number of things to limit what an attacker could do even if they did get your special key, even without fundamentally changing the way their current system works. In simple terms, industry developers accept several measures as standard security practice:

  • Expiring the special key on its own after a reasonable amount of time, after which it’s no longer good, and you’re given a new one instead.
  • Asking you for your password every time you try to do some particularly sensitive action, like changing your account’s email address or changing your password to something new.
  • Associating the key with the specific computer you’re using so that if it’s used somewhere else, the system will ignore it and ask you for your password again.

Among its recent changes, FetLife began adopting the first two measures. FetLife now limits the lifetime of any given session cookie to 30 days. FetLife will also now prompt you to enter your old password when changing it to something new. That’s a good start, but it leaves an obvious loophole. An attacker could still change your account’s email address to one they control, and then use FetLife’s “Forgot your login information?” feature to reset your password as they wish.

The takeaway is that there are many safer ways to handle your key than what FetLife was (and, arguably, still is) doing with it.

There’s sadly very little you can do to protect yourself, as a user. Since I sometimes still want to use FetLife but I don’t want to risk losing my special key, I registered a second FetLife account. I now use that account instead of my “real” one for reading group discussions, looking at people’s profiles, and doing anything that I don’t have to use my real account for. I only use my real account from my desktop, at home, to reduce the chances of accidentally exposing my secret key to an attacker; my laptop is always logged into FetLife using my dummy account.

What can I do to help?

You can help a lot simply by encouraging FetLife to take even small steps that protect your safety. Every additional security feature FetLife adds makes you that much safer by making it that much harder for an attacker to pretend to be you. Right now, FetLife’s only security focus is at “the gate,” the login page. Adding safety features inside FetLife as well as between it and the outside world is just as important as strengthening its walls (insofar as it is appropriate to have those walls, anyway…).

  • Write to [email protected] and complain. Seriously. All you have to do is air your concern. Just like any other company, FetLife will respond to pressure from its users, but only if its users actually pressure the company into acting. And, just like any other company, they will probably respond first with lip service in an attempt to placate you, but will eventually cave to user demands (if their past correspondence with me is any indication).
  • Tell FetLife you won’t support them financially until they implement multiple, layered security precautions (“defense in depth”). Paying money for a service that’s insecure in the hopes that it will become more secure is as silly as paying for rotten food in the hopes that it will ripen. That’s just backwards.
  • Acknowledge the fact that FetLife intendsto be a business first, and a community hub second (if at all). If you really want to be pro-active, raise funds and tell FetLife you’ll award them a bounty when they implement security and privacy improvements. I don’t have time to manage a campaign like this myself but, I promise you, nothing motivates for-profit companies more than more profit! Here are some ideas you can encourage FetLife to prioritize and implement with the funds you raise:
  • Educate yourself and your fellow FetLife users. Learn about the problems and how to avoid pitfalls, and then share your knowledge freely, generously, and liberally with others; republish or link them to this post, for example.

Ultimately, this is not very complicated, and you can let others make their own choices about how secure or insecure they’re willing to be. But, of all communities, this one should understand the importance of making informed choices.

Technical details

As FetLife says on its privacy page:

FetLife uses cookies for authentication and to store information in between page requests.

When a user requests a FetLife.com web page, FetLife looks for a cookie with the name _FetLife_session and reads its value. Over the wire, a logged-in user’s _FetLife_session cookie looked something like this:

BAh7CjoQX2NzcmZfdG9rZW4iMTRmMjdTcDNqUE9HTXNUdWo0UmlMSmxjOGg4ckxuZzhzTEY1V0QwUEVHS1E9Og9zZXNzaW9uX2lkIiVkOWMyZDYzOGI0ODU4MDI5MDlhNzRjMzRmZjQ1MmJkNzoUY3VycmVudF91c2VyX2lkaQOfow4iCmZsYXNoSUM6J0FjdGlvbkNvbnRyb2xsZXI6OkZsYXNoOjpGbGFzaEhhc2h7AAY6CkB1c2VkewA6FGFiaW5nb19pZGVudGl0eWwrCEq1JAICAA%3D%3D--a8128aa96ed5da1ec9d4fda35f1ad366d8ea21f2

Figure 1 shows Firebug requesting the FetLife home page using the above cookie (which, yes, was valid and belongs to a test FetLife account nicknamed “fetfails”).

Screenshot of Firebug observing a FetLife.com page load.

A _FetLife_session cookie is a Base64- and URL-encoded blob containing several pieces of data, evidently produced by the FetLife Ruby on Rails application. Among the data in the cookie is the current user’s ID and associated session ID, in this case 959391 and d9c2d638b485802909a74c34ff452bd7, respectively.1

Actually stealing a cookie isn’t something I’m going to describe in detail because it’s stupidly easy and I don’t want to encourage that kind of mischief. Suffice it to say that well-known tools like Firesheep make it trivial.2 And while that’s the simplest way to steal cookies, other attack vectors exist as well, particularly against users who browse with Internet Explorer.3

In any case, getting a cookie is far too easy. The stolen session cookie was, in FetLife’s case, functionally equivalent to an automatic, and permanent login. FetLife basically said, “whoever shows me this cookie is logged in as user ID 959391, a.k.a. ‘fetfails’.”

Once an attacker got a logged-in user’s (victim’s) _FetLife_session cookie, they merely need to send that cookie in place of the one FetLife sent whenever they wanted to impersonate the victim. This is possible using a tool like the Edit This Cookie extension for Google Chrome. Figure 2 illustrates how simple an attack might have looked like against my “fetfails” test account:

  1. Navigate to the FetLife home page (using Chrome with the aforementioned extension installed).
  2. Click the “Edit This Cookie” icon at the top right the Chrome window.
  3. Expand the section labeled _FetLife_session.
  4. Copy and paste the (stolen) encoded cookie into the valuefield, replacing the old value. For the next month, you can copy and paste the following session cookie value to try this out yourself: 
    BAh7DDoQbGFzdF9hY2Nlc3NsKwdma0BOOhRjdXJyZW50X3VzZXJfaWRpA5%2BjDjoPc2Vzc2lvbl9pZCIlNmQzNThiZjY1NDRhYzdlZTU2NzQ2NmE4YmI5NzI0NzM6EF9jc3JmX3Rva2VuIjFmVVU3aG15SUU1Slh5cDluQlYxU1F5VXEyZU0yekhBUE5JUXU1VCtiRjA4PToGcyItMWI3MDg1YjAxYzFlNDczMmU3YTAyMjZhOTUyNDc2OWFjMDc3NTk3YSIKZmxhc2hJQzonQWN0aW9uQ29udHJvbGxlcjo6Rmxhc2g6OkZsYXNoSGFzaHsABjoKQHVzZWR7ADoUYWJpbmdvX2lkZW50aXR5bCsHxK8i6w%3D%3D--de0b9e177e21d67d5e345e48dd04604cc4320ac8
  5. Click “Submit Cookie Changes”.
    Screenshot of FetLife home page with Edit This Cookie extension for Chrome.
  6. Reload the FetLife home page.

Voila; that’s all an attacker needed to do to be logged into FetLife as the “fetfails” user. And since FetLife never asked for a password once you’re already logged in, the cookie granted the attacker full access to fetfails’s account. Furthermore, since FetLife didn’t ever expire the cookie, the attacker could continue to use it for as long as they wanted.

On a website that uses server-side sessions instead of cookie-based ones, when you click “logout,” the session cookie you used to log in with would never work again. On FetLife, however, even after the “fetfails” user clicks the “Logout” link, the above procedure continued to work—and it still does, for up to 30 days, if you manage to steal another user’s session cookie. There was nothing a user could have done to invalidate the cookie; lose control of one cookie, and you lost exclusive control of your FetLife account.

This susceptibility to replay attacks against a Rails application (like FetLife) when the default cookie-based sessions are used was discussed way back in 2007. It’s also addressed in §2.6 of the Ruby on Rails Security Guide.

While rolling out SSL site-wide would certainly help, so would a number of other things, like the ones I already described in the mitigation section of this post. Moreover, those things don’t require the kind of expensive hardware overhead that switching away from cookie-based sessions or even implementing SSL do and, further, they should be done anyway. It’s doing those other things that make “defense in depth” actually defense in depth.

Finally, the importance of all this was brutally demonstrated more than 6 months ago.

Editorial

As FetLife’s users, we deserve to know what it is that FetLife is or is not actually doing to protect our privacy, not just what FetLife is saying about what they are doing to protect our privacy. It is the distance between how safe you feel and how safe you actually are that is the threat. If you feel safe when you are not, you’re a much easier target for an attacker than if you are aware of your vulnerabilities.

If you already knew that you currently have little to no protection when using FetLife and you chose not to do anything differently in light of that—if you already knew the emperor is naked and you chose to pretend that he is clothed anyway—then, great! More power to your polite fiction! However, if you falsely believed you were secure because you were intentionally or accidentally misled, then I say shame on those who mislead you.

FetLife knew better, and then dragged their feet. They have and continue to mislead people. This is not news.

Back in March, I described how FetLife’s lack of granular privacy controls meant that anyone who wanted to could gain access to so-called “private” (i.e., not-for-public-consumption) material simply by creating a new account and logging in as any normal user might:

For an individual, FetLife’s primary “privacy” offering is simply that nothing you post will be indexed by search engines like Google. Since there is no way to access FetLife from outside FetLife, it’s like Vegas: what you say on FetLife stays on FetLife. The implicit claim, then, is that the entire container is safe.

However, since all that is required to gain access to FetLife membership is a (free) email address, the claim is farcical on its face. Claiming FetLife is either private or safe for any given individual is like breaking open someone’s back door and then selling them a stronger lock for their front door.

FetLife’s “front door” is its login page. By requiring you to use that login page to view any content at all, what FetLife is saying to laymen users is, “Nobody who tries can enter unless they go through this door.” The implicit claim in this case is that FetLife understands that because what you do inside FetLife is more sensitive than what you do on the public Internet, it needs special protections.

In this way, FetLife has made a claim about their behavior. But the distance between their claim and their actions is considerable, and it is foolhardy at best to obscure or deny the fact that this distance exists.

What’s so interesting to me about FetLife is that, unlike Facebook’s users, among whom only the clearly deluded have any trust in the company, the vast majority of FetLife’s user base seem ardently vocal in their adoration. Could this be due to the extraordinarily personal nature of the content FetLife hosts for them? I can’t imagine a typical user (which I am not) talking openly about their fetishes on Facebook, for example.

Both FetLife and Facebook arguably have monopolistic control over their users’ online social lives. But of the two, FetLife is in a far more trusted position because many people who use it do so precisely to avoid using services that aren’t friendly to sexual expression (like, say, Facebook). In other words, most of FetLife’s adoring fans don’t just treat the company like a friend, they treat it like the friend they send naked photos of themselves to, the friend they ask to pass on the sexually explicit note they wrote to their sweetheart(s). And not just any note, but the note about that totally taboo fantasy. Because, why not? That’s okay here! I mean, it’s FetLife, not Facebook!

And y’know what? That’s actually really cool! No, not just cool, that’s awesome. And not merely awesome, but culturally necessary. Just in case it isn’t clear, yes, I’m actually praising FetLife. But as the only large social network not actively hostile to (most) sexual expression, FetLife has also become the single, giant basket many of us have placed our eggs in. And that makes it even more important for FetLife to go the extra mile to secure us.

FetLife is continuing to develop new features, seemingly pumping them out like crazy. As I was putting this post together, they announced they were “starting to roll out the ability to upload pics via email from your phone to your FetLife profile” and then proudly announced “100% of People Have the Ability to Upload Pics via Email.” While that sounds cool, I guess, I have to wonder whether or not their users’ privacy and security are being taken as seriously as how whatever the next shiny feature is handled.

Moreover, if the FetLife team really is as small as they make it out to be, it’s even more unlikely that they’re developing new functionality while simultaneously spending the same amount of brainpower prioritizing security, no matter what they say. Immediately after I learned of the persistent nature of this issue, I asked the FetLife crew if they were planning on implementing SSL-only browsing:4

Does @FetLife plan to enforce SSL/TLS on all logged-in requests soon? If so, on what timeline? /cc @JohnBaku @JamesGolick #FetLife #security

One of their developers, James Golick, responded in the affirmative:

@maymaym We’re going to do it. It’s on our list, but it’s nontrivial for various reasons. We never make timeline promises though, sorry.

When I asked if security was a priority for them, James responded affirmatively again. This is certainly good to hear. I don’t doubt their skill or knowledge, and I’m heartened to read about James’s security-conscious bullheadedness. Back in February, James found himself in a similar situation to the one I feel like I’m in now:

Despite this being an incredibly serious security issue, nobody really seemed to care. Oh well. […] Yes, [this example] is relatively unimportant security-wise (except that if there’s a man-in-the-middle, he now has credentials to access your [data], which may or may not contain [your] secrets — but I digress). Eventually I remarked that despite the relative unimportance of [this example, the developer] is a leader in the ruby community, and leaders should set good examples.

I strongly agree. As James reminds his Twitter followers, “Broken gets fixed, but shitty lasts forever.” Truth! And that’s a really, really good point.

When it comes to FetLife.com itself, there seems to be far too much talk and not enough walk.

Of course, that wouldn’t be some shocking betrayal, but rather confirmation of what should be a very obvious thing few seem willing to recognize: FetLife is just like any other social media company. By investing far more heavily in new features than in the very basics of security, FetLife behaves just like Facebook. In itself, that doesn’t bother me. (Well, not anymore than I’m bothered by Facebook generally, that is.) What bothers me is that FetLife says they’re behaving differently when they’re not, and then relying on people’s relative technical ignorance to get away with that.

FetLife keeps saying it’s a “community” site for people to meet and network and build stronger community ties. It goes out of its way to distinguish itself from seedy hookup sites, and even claims to limit some of its search functionality to prevent that behavior. But can we trust that FetLife, as a company, cares more about our privacy than about the next new feature? If not—frankly, I don’t—ask yourself: under what circumstances would you prefer FetLife got pressured into prioritizing user privacy and security? Pressure from its own constituents who have its improvement in mind, or pressure from its economic or political competitors, who have its destruction in mind?

FetLife is not a community. FetLife is a business. Only fools confuse the two. Yes, FetLife’s robes are said to be made of the finest cloth. But the Emperor is naked. And the whole people will one day say, “He has nothing on at all.”

Email conversation with FetLife

Subject: Privacy concern: FetLife’s session handling does not invalidate old user sessions
From: maymay <[email protected]>
Date: June 14, 2011 10:57:53 PM PDT
To: [email protected]

To whom it may concern at Protose, Inc.,

I have some concerns regarding FetLife’s handling of its users’ session cookies. Specifically, it appears authentication cookies that I receive from FetLife never expire and thus, if stolen, can be used to access my FetLife account even after I expressly log out of the website. I recorded a brief video that showcases this issue at the following address:

http://maybemaimed.com/tmp/fetlife-cookie-expiry-tests.mov

In the video, I use a cookie obtained from FetLife on June 9th. The video was recorded on June 14th. The video shows that FetLife still considered the cookie valid at the time of recording, even after I logged out of the service. I’ve also been able to log in to FetLife using the captured June 9th cookie from other browsers on other computers.

It is troubling to me that FetLife does not invalidate session cookies when I log out of the service. Shouldn’t that be done to ensure old sessions can no longer be used? Regardless, how long does FetLife consider session cookies valid? Is there any expiry time enforced on the server? If so, what is it?

I could find no evidence of any such expiration and as a result I am deeply concerned that theft of a single FetLife session cookie could theoretically grant unauthorized access to my FetLife account for the lifetime of my account.

If indeed there is no expiration, then this effectively offers session hijacking persistence to even one successful “sidejacking” attack against a FetLife user. As I know you are aware,[0] since FetLife currently does not support HTTPS-only browsing, every request by a logged-in user for a resource on FetLife.com exposes the user’s authentication cookie to the network. Worse, once the attacker hijacks a victim’s session, since FetLife.com never asks users to re-authenticate to perform any action (like changing one’s password), compromising a single cookie effectively fully, silently, and permanently takes over a FetLife.com account.

Given the prevalence of cookie theft,[1] the highly sexual and thus sensitive nature of FetLife.com users’ content, and the persistence of even a single successful attack, I feel it’s critical to address this issue urgently. What, if anything, is FetLife planning to do to resolve or at least mitigate the severity of an account breach like this?

If I understand FetLife’s architecture correctly, then it is possible a resolution to the issue is as simple as a one-line fix, which is documented in §2.8 of the Ruby on Rails Security Guide:[2]

“If you use the popular RestfulAuthentication plugin for user management, add reset_session to the SessionsController#create action.”

I’ve prepared a blog posting describing this issue to non-technical users. My plan is to publish in one week’s time, but if I receive a notice that FetLife is taking steps to resolve this issue, I’ll delay publishing for some more time if you’d like. I’m writing you before I publish specifically because I don’t want to unnecessarily endanger FetLife users (including myself!), especially as there is nothing we can do to resolve this particular concern ourselves.

Thank you for your attention and for prioritizing your users’ privacy and security. I think FetLife.com has become an important cultural phenomenon and I feel strongly that it needs to do everything possible to protect its users from attacks.

Sincerely,
-maymay
Blog: http://maybemaimed.com/
Talk show: http://KinkOnTap.com/
Community: http://KinkForAll.org/

EXTERNAL REFERENCES:

[0] http://twitter.theinfo.org/78611275625676800
[1] https://www.digitalsociety.org/2010/11/online-services-security-report-card
[2] http://guides.rubyonrails.org/security.html

From: James Lennon <[REDACTED]@fetlife.com>
Subject: Re: Privacy concern: FetLife’s session handling does not invalidate old user sessions
Date: June 15, 2011 10:15:27 AM PDT
To: maymay <[email protected]>
Cc: John Baku <[REDACTED]@fetlife.com>

Hey [maymay],

Thanks for emailing in about this issue. Actually, it’s something that we were aware of, but preferred to solve in a different way. Unfortunately, because of the way that we store our sessions, expiring them is a lot more complicated than it sounds. And in any case, it’s the wrong solution to this problem.

The correct solution is to implement site-wide SSL. If the cookies are protected from the network, there’s no particular need to expire them. We do delete them from users’ computers on logout.

We are working on getting site-wide SSL going, but unfortunately, it’s not entirely within our control. We have partners who we have to work with, and their timelines are somewhat out of our control. We are leaning on them as hard as we can, but it’s probably going to take another 60-90 days for us to be ready to start rolling this functionality out to the community.

I’ve prepared a blog posting describing this issue to non-technical users. My plan is to publish in one week’s time, but if I receive a notice that FetLife is taking steps to resolve this issue, I’ll delay publishing for some more time if you’d like. I’m writing you before I publish specifically because I don’t want to unnecessarily endanger FetLife users (including myself!), especially as there is nothing we can do to resolve this particular concern ourselves.

I really appreciate your enthusiasm. It’s clear that like us, you have a great deal of passion for the kinky community. If you really want to help us get this functionality out the door, encouraging your audience to support FetLife would be a huge contribution you could make. Offering SSL to our growing community is a very expensive proposition for many reasons.

So, please give us a couple of months to get all the pieces of this SSL project together; we’re actively working on it. If you do decide to publish the article (obviously we’d prefer that you didn’t), we’d really appreciate some warning.

Thanks again,

James Golick

Subject: Re: Privacy concern: FetLife’s session handling does not invalidate old user sessions
From: maymay <[email protected]>
Date: June 16, 2011 8:49:22 PM PDT
To: James Lennon <[REDACTED]@fetlife.com>
Cc: John Baku <[REDACTED]@fetlife.com>

Hey James,

I’m glad to hear you’re already aware of the problem. I’d hoped you were, since it seems like such a basic issue. That said, I’m disappointed by your response.

You wrote that, “If the cookies are protected from the network, there’s no particular need to expire them,” but I think this is a very dangerous mindset. While it’s certainly the case that implementing site-wide SSL would close the most trivial cookie theft vulnerability (and that’s good!), the fact of the matter is session cookies can be stolen in a number of other ways. Moreover, I fear you have missed the point of my concern when you said that “We do delete [cookies] from users’ computers on logout.” The whole reason for my concern is that, if my cookie is stolen, I can’t delete it from the *thief’s* machine!

Again, I want to stress that my concern is not solely with the lack of SSL and that implementing SSL, while definitely helpful, is not a panacea by any means. If the server never enforces some kind of expiration on session cookies, it is still the case that the theft of just one cookie would irrevocably give an attacker total control over my FetLife account. Just because a session cookie was *transmitted* securely doesn’t mean it’s trustworthy *forever*.

Enforcing some kind of reasonable expiry on these session cookies is not outlandish. I feel that failing to do so exposes me to an unacceptable level of risk when I use FetLife. I believe that if laymen users were aware of the situation, it would be unacceptable to them, too.

I’m also sorry to hear that resetting sessions is not as easy to accomplish in FetLife’s case as I hoped. While I’m sympathetic to the complexity of your situation, I also know this is not an unsolvable problem. Especially considering the expertise the FetLife team has in this area, and the extremely personal nature of users’ content, I feel it’s important that FetLife urgently adopt a defense-in-depth approach here.

There are concrete steps FetLife can take that would frustrate an attacker, even if those steps wouldn’t remove all risk. I feel you are obliged to take at least some of these steps if indeed you want to claim that FetLife is a secure and private place for the average user, especially as most of them are posting sexual content. Doing things like asking the user to at least provide their old password when they change it to something new would significantly mitigate concerns here.

My point in bringing this up is that the lack of security precautions *within* the FetLife walls are equally troubling. FetLife’s reliance on the perimeter security of the login form is dangerously over-confident.

Finally, while I can also appreciate your need for funds, I can’t in good conscience recommend that anyone financially support FetLife while I know it has such lax security practices. FetLife needs to implement appropriate security and privacy measures for its users *before* I’ll feel justified encouraging anyone to pay for it.

Since there are numerous things FetLife can and, as I’ve argued, should do to more adequately protect user privacy prior to going SSL-only, and since you say you’ve been aware of these concerns for some time, I don’t feel comfortable waiting 60 to 90 days before posting about the issue. Unless you show me that you need a reasonable amount of time to implement some basic precautions, I still plan to publish a post explaining my concerns and describing the technical details to non-technical users next week (on Wednesday, June 22nd). It doesn’t seem like implementing session cookie expiry times or at least asking for re-authentication on a request to perform major actions, for example, needs to wait another 3 months.

Thank you for taking time out of your day to correspond with me about my concerns. I really do appreciate that FetLife offers a valuable service. I just also hope you take a closer look at the broad assumptions you’re making regarding your security measures in the context of the unique role FetLife plays in our communities.

Sincerely,
-maymay
Blog: http://maybemaimed.com/
Talk show: http://KinkOnTap.com/
Community: http://KinkForAll.org/

From: James Lennon <[REDACTED]@fetlife.com>
Subject: Re: Privacy concern: FetLife’s session handling does not invalidate old user sessions
Date: June 17, 2011 12:23:47 PM PDT
To: maymay <[email protected]>
Cc: John Baku <[REDACTED]@fetlife.com>

We are working on building another mechanism for session storage, but it’s non trivial, and requires a hardware order for capacity. We’re doing our best to get this out the door as quickly as possible, but again, it’s not a trivial problem to solve to store and then migrate hundreds of thousands of sessions in a durable way (as this is going to introduce 500+ req/s worth of additional load on whatever datastore we choose, we don’t have the capacity to spare on our current MySQL cluster). I very much doubt this is going to be shipped by Wednesday, but we are working on it.

Subject: Re: Privacy concern: FetLife’s session handling does not invalidate old user sessions
From: maymay <[email protected]>
Date: June 18, 2011 4:37:37 PM PDT
To: James Lennon <[REDACTED]@fetlife.com>
Cc: JohnBaku <[REDACTED]@fetlife.com>

Hey James,

It is *very* good to hear that you’re working on another (presumably) more secure mechanism for session storage.

Are you also working on implementing some of the simpler things that doesn’t require new hardware but would still mitigate these concerns somewhat? I already named some: ask users to supply their old password when they perform sensitive actions (like updating their password); add an “expires at” timestamp that gets checked and updated on page load to cookies you send right now so they don’t last forever.

These are just two things you can do without fundamentally re-architecting your session store or making expensive hardware purchases and they would greatly enhance security for FetLife users. If you roll out these two improvements by Friday, June 24th, I’ll wait another month and a half (45 days, until August 8th) for you to implement default site-wide SSL for all users before publishing about this issue. Otherwise, I’ll still publish during June.

Sincerely,
-maymay
Blog: http://maybemaimed.com
Talk show: http://KinkOnTap.com
Community: http://KinkForAll.org

From: James Lennon <[REDACTED]@fetlife.com>
Subject: Re: Privacy concern: FetLife’s session handling does not invalidate old user sessions
Date: June 19, 2011 10:55:58 PM PDT
To: maymay <[email protected]>
Cc: John Baku <[REDACTED]@fetlife.com>

Hi [maymay],

I’ve discussed our practices with a few of my friends who have security backgrounds, and here’s what I’ve come up with.

I’ve deployed a change that expires session cookies 1 month after their last request. We’re working on code to require the current password when changing your password. And when we implement that, we’re also going to expire all of your existing sessions when you change your password by putting a unique token in the session cookie that expires when you change your password. This way, if somebody’s account has been compromised, we can easily expire all the existing sessions at the same time we change the password to ensure that control of the account is restored.

With those changes, implementing another session storage mechanism shouldn’t be necessary. We won’t be able to delete sessions on logout, but once we implement SSL, that won’t really be a relevant concern. If the user’s machine is compromised, the attacker is going to have an easy time getting their username and password anyway. And will almost certainly have access to the user’s email, and therefore our reset password functionality.

– James

From: James Lennon <[REDACTED]@fetlife.com>
Subject: Re: Privacy concern: FetLife’s session handling does not invalidate old user sessions
Date: June 21, 2011 10:15:52 AM PDT
To: maymay <[email protected]>
Cc: John Baku <[REDACTED]@fetlife.com>

All of these changes, aside from SSL have been deployed, tested, and rolled out.

From: maymay <[email protected]>
Subject: Re: Privacy concern: FetLife’s session handling does not invalidate old user sessions
Date: June 23, 2011 2:46:09 PM PDT
To: James Lennon <[REDACTED]@fetlife.com>
Cc: JohnBaku <[REDACTED]@fetlife.com>

Hi James,

I just had a chance to look at the changes you describe. They’re good to see! I’m particularly glad to see you at least asking for a user’s current password when changing their password to something new.

I’ve also verified that you’ve indeed invalidated a user’s session cookie when said user changes their password, but I noticed this is only the case if the cookie data itself includes the new, unique tokens. The numerous cookies I saved before you implemented this change still allow me to access FetLife without logging in, same as before, essentially treating the new cookies with their unique tokens as though they are optional. When will you ensure FetLife session cookies lacking the new unique tokens are invalidated, too?

Thank you for implementing the mitigating features you have so far. I think they’re an important step for FetLife users.

Sincerely,
-maymay
Blog: http://maybemaimed.com
Talk show: http://KinkOnTap.com
Community: http://KinkForAll.org

From: James Lennon <[REDACTED]@fetlife.com>
Subject: Re: Privacy concern: FetLife’s session handling does not invalidate old user sessions
Date: June 23, 2011 3:01:33 PM PDT
To: James Lennon <[REDACTED]@fetlife.com>
Cc: JohnBaku <[REDACTED]@fetlife.com>

Hi [maymay],

We’re going to phase out the old cookies in about 30 days. The last time we mass expired all of our sessions, we received so many support emails that it took our team months to get out from under them. We’re giving our users a month to use their sessions again (as soon as you use your session, you receive both of the new tokens). Then, we’ll make ’em mandatory.

– J.

From: maymay <[email protected]>
Subject: Re: Privacy concern: FetLife’s session handling does not invalidate old user sessions
Date: June 23, 2011 3:11:06 PM PDT
To: James Lennon <[REDACTED]@fetlife.com>
Cc: JohnBaku <[REDACTED]@fetlife.com>

Hi James,

Sounds good. I look forward to no longer being able to use my saved cookies after this July . :) And, shortly thereafter, to site-wide SSL on FetLife.

Cheers,
-maymay
Blog: http://maybemaimed.com
Talk show: http://KinkOnTap.com
Community: http://KinkForAll.org

  1. Here’s how you might start to decode the cookie using Python:

    >>> import urllib >>> t='BAh7CjoQX2NzcmZfdG9rZW4iMTRmMjdTcDNqUE9HTXNUdWo0UmlMSmxjOGg4ckxuZzhzTEY1V0QwUEVHS1E9Og9zZXNzaW9uX2lkIiVkOWMyZDYzOGI0ODU4MDI5MDlhNzRjMzRmZjQ1MmJkNzoUY3VycmVudF91c2VyX2lkaQOfow4iCmZsYXNoSUM6J0FjdGlvbkNvbnRyb2xsZXI6OkZsYXNoOjpGbGFzaEhhc2h7AAY6CkB1c2VkewA6FGFiaW5nb19pZGVudGl0eWwrCEq1JAICAA%3D%3D--a8128aa96ed5da1ec9d4fda35f1ad366d8ea21f2' >>> data=t.split('--')[0] >>> hmac=t.split('--')[1] >>> urllib.unquote(data).decode('base64')'\x04\x08{\n:\x10_csrf_token"14f27Sp3jPOGMsTuj4RiLJlc8h8rLng8sLF5WD0PEGKQ=:\x0fsession_id"%d9c2d638b485802909a74c34ff452bd7:\x14current_user_idi\x03\x9f\xa3\x0e"\nflashIC:\'ActionController::Flash::FlashHash{\x00\x06:\[email protected]{\x00:\x14abingo_identityl+\x08J\xb5$\x02\x02\x00'>>> hmac'a8128aa96ed5da1ec9d4fda35f1ad366d8ea21f2'

    See Wikipedia’s article on HMACs for more detail about that part of the cookie. [↩]

  2. I was able to go from never using the tool to writing a working Firesheep handler for FetLife in under 20 minutes. Here it is. [↩]
  3. For example, since IE won’t honor host-only cookies, it’s more vulnerable to a poisoned DNS cache. It’s also more vulnerable to “cookie jacking” via UI redressing attacks, which is also an example of an attack that site-wide SSL will not protect you against. [↩]
  4. View the whole Twitter conversation on one page. [↩]