{ codebutler }

Exactly one year ago, an article on TechCrunch discussed the potential for Apple to dominate mobile payments, specifically using NFC. Since then, not much has changed.

While Apple didn't talk about retail payments at all last year, Google did rush to launch an unfinished "Wallet" in anticipation of a similar announcement by Apple that never came. More significantly, Android got stuck with Isis, the abomination of major carriers and credit card companies. Although they have no product, Isis had an incredibly successful 2011 sabotaging Android and holding back widespread adoption of NFC in the US.

For example, my unlocked/unsubsidised Nexus S phone can’t use Google Wallet because T-Mobile is part of Isis. Many phones have NFC hardware that has been completely disabled by AT&T because of Isis, and can’t even be used for other non-payment purposes such as contact sharing apps. Isis even managed to destroy the reputation of Google’s formerly “pure” Nexus brand.

Meanwhile transit payment systems compatible with NFC continue to be deployed around the world, and yet you can’t use your phone with almost any of them. There’s a huge potential here for mobile payments without directly involving banks and credit card companies. This was why I wrote FareBot; to demonstrate the potential of integrating NFC phones with these existing systems.

Almost a year later, FareBot only reliably works on two devices (Nexus S and Galaxy Nexus) despite hundreds of new phones on the market. As a developer who was once passionate and excited about both Android and NFC, I now feel disenchanted about both. Maybe the future payments system won’t need NFC at all?

When rumors of an iPhone 5 were buzzing last year, NFC was suddenly a hot topic. But the moment Apple announced the “disappointing” iPhone 4S, interest quickly vanished. The rest of the electronics took a step back leaving Apple a golden ticket to once again dominate a new market.

I’m happy to announce a new version of FareBot is now available on the Android market!

There are two major changes in this release: A totally new user interface designed for Android 4.0 and support for Japanese FeliCa cards including Suica, PASMO, and ICOCA.

For people (like me) who can’t read Japanese, FareBot will display all station and line names in English. For everyone who can read Japanese, the entire app has been localized for Japan.

This release would not have been possible without the help from a bunch of people and open-source projects. I randomly met Makoto Yamazaki at Bar Android in Tokyo back in July who pointed me to the nfc-felica project, which much of the new code in FareBot is based on. I’d also like to thank Dennosuke from the IC SFCard Fan project for providing the station database.

If you think FareBot is awesome and have been enjoying using and showing it off to your friends, please consider supporting the continued development of the project by contributing a few bucks (or yen!) to the Buy Eric a Galaxy Nexus fund. I appreciate it!

When it was announced that the Nexus S would have a built-in NFC radio, I immediately started thinking about the potential of using cell phones with RFID public transit fare systems. The day the Gingerbread source code was released, I picked up a Nexus S and began working on a proof-of-concept application that can read data from transit cards. Though a vacation got in the way, today I’m happy to announce FareBot!

Currently FareBot can parse and display balance and trip history information from Seattle’s ORCA card, and can dump raw data from any other MIFARE DESFire card including San Francisco’s Clipper card. FareBot is open-source and designed to be flexible so that hopefully other developers will add support for other types of cards.

When demonstrating FareBot, many people are surprised to learn that much of the data on their ORCA card is not encrypted or protected. This fact is published by ORCA, but is not commonly known and may be of concern to some people who would rather not broadcast where they’ve been to anyone who can brush against the outside of their wallet. Transit agencies across the board should do a better job explaining to riders how the cards work and what the privacy implications are.

Another common question is if it’s possible to modify data on a card for free rides. As a big supporter of public transit, facilitating fare evasion is absolutely not something I am interested in. This is an especially touchy subject as transit agencies across the country face large budget gaps due to the economic recession, some of which have been forced to cut back service people have come to depend on.

That said, the security of some older fare cards has been compromised possibly allowing someone to alter their balance, though I am unaware of any attacks against DESFire. In general, it’s very important that these systems do not rely on security through obscurity and I believe the more people who learn about how these systems work, through FareBot or other projects, the better.

With budget gaps or not, new technology should be seen as new opportunity to encourage ridership by making transit easier and more convenient. Despite problems during the initial rollout, I think ORCA has already accomplished this in Seattle by eliminating the need for casual (non-pass) riders to deal with change, making the bus an easy choice for quick trips. As a visitor to San Francisco and the valley, Clipper (formerly Translink) saved me from what would have otherwise been a nightmare of juggling BART, Muni, and Caltrain tickets.

Because many of these systems are new, there is often a limited number of places to buy a card and/or add value, especially outside the city center. This presents a great opportunity for NFC-equipped smart phones which, in addition to being able to read cards, also have the capability to emulate a card. No matter how far to the edge of an agency’s service area you are, it should be possible to download the ORCA or Clipper app and hop the next bus, streetcar, train, or boat. Apps could link with existing payment infrastructure such as Google Checkout for quick payments without additional setup, and for international travelers looking to get around, apps could support multiple languages and automatic currency conversion.

Typically there is a tradeoff between a transit fare system’s level of security and the cost of a card, as the cards with better security are more expensive. Smart phones on the other hand already have the capability to do real cryptography, so there’s potential to build a much more secure system while not requiring substantial changes to existing reader infrastructure.

FareBot itself may not appear very useful, but I hope it will seen as a demonstration of what’s possible for the future as NFC becomes pervasive. It can be downloaded now from the Android Market, just keep in mind that the current version is not at all complete. If you’re a developer and interested in exploring what’s stored on cards around the world, I hope you’ll check out the source code and contribute. For everyone else – never worry about if you have enough bus fare again!

FareBot Website | FareBot Source Code

If you're in the Seattle area, come see me and Ian Gallagher speak about Firesheep at the next iSEC Open Security Forum. Full details below... see you there!

In only a few short weeks, Firesheep has captured the attention and interest of hundreds of thousands of people around the world, and has spurred a lot of great discussion. This is the third in a series of posts highlighting and responding to topics I found most interesting.

Previous post in series: Idiot Shepherds

This post was co-authored by Ian Gallagher.

The risks of insecure websites have been known for years, yet over the years little to nothing has been done about what has become an incredibly widespread problem. In the three weeks since Firesheep was released, there has been some encouraging news that companies are waking up to the reality that HTTP is dead, and that full end-to-end encryption (HTTPS/SSL) is no longer optional but rather a requirement of doing business online.

Fourteen years after launching, Hotmail has finally announced support for SSL. While this is a huge step forward, it is currently implemented as an opt-in feature, meaning all of Hotmail’s 300+ million users have to know to turn the feature on, which is unlikely. Hopefully users won’t have to wait another decade for Hotmail, other Microsoft services, and other websites to implement mandatory SSL everywhere. In January of this year the EFF commended Gmail for making all accounts use SSL by default, and urged other websites to do the same.

The list of website handlers included with Firesheep represents a variety of sites that we frequent including some that require unique processing to obtain session/user information. Of these sites, we’ve heard that GitHub, Slicehost, DropBox, and Pivitol Tracker have all taken steps to protect their users since Firesheep was released. Firesheep and any similar tools are no longer be able to identify newly issued sessions on these websites, but users of these services should clear their cookies to ensure that no insecure session is left behind that could be potentially sent out.

Although most of the media attention has been focused on this list of sites, especially Facebook, this remains an extremely widespread problem. Illustrating this point, numerous people have already posted handlers they’ve written for additional websites. Other tools such as Hamster don’t require site-specific code and are capable of hijacking any insecure website they spot. A generic handler for Firesheep could accomplish this too. If you’d like to write a new handler to test your own security on the sites you frequent, see here for basic information.

If you work for a company that recently adopted SSL, or know of another company that did, please let us know. We’d like to learn more about why companies choose not to be secure from the start and what problems are encountered while making the switch. The EFF just posted a great guide on How to Deploy HTTPS Correctly for anyone who is looking to do so.

If one of the websites you frequent isn’t secure, let them know that your privacy and security should be a priority. A campaign demanding that the world’s top 100 websites support HTTPS was recently launched by human rights organization Access. Sign their petition and help spread the word.

Firesheep is not the cause or source of this problem. The clock started ticking for companies to protect their users the day they launched, not the day Firesheep was released. Facebook is already going on 6 years of insecurity, and counting.

In only one week, Firesheep has captured the attention and interest of hundreds of thousands of people around the world, and has spurred a lot of great discussion. This is the second in a series of posts highlighting and responding to topics I found most interesting.

Previous post in series: Ethics and Legality

In addition to all the news articles, blog posts, comments, and tweets, Firesheep has inspired some people to respond with code.

One developer thought Firesheep, as a mostly passive tool, didn’t go far to warn people about the dangers of using insecure websites. He released a new tool called Idiocy which automatically hijacks any Twitter accounts it spots and posts a tweet as them, offering a much more blunt reminder to both the victim and their followers.

Idiocy, at less than 130 lines of code, is an important example of how easy eavesdropping can be.

While Idiocy might offer a useful message, Twitter users have no way to use the website securely without a third party tool like HTTPS Everywhere. Very few people have actually been affected by Idiocy, a search on twitter at this time shows less than a dozen tweets containing the message posted by Idiocy.

Another developer created FireShepherd, which has been widely reported as a way to stay “safe” while using insecure websites on public networks. To understand how this tool works, imagine your friend gets drunk at a bar and starts shouting his credit card number to everyone within earshot. Knowing he isn’t in his right mind and will likely regret his actions in the morning, you decide to intervene by shouting “LALALA” even louder with the hope that nobody will be able to hear what he is saying. While this may prevent some people from hearing the card number, it won’t stop everyone, and will most certainly upset everyone else at the bar even further.

This is essentially what FireShepherd does. FireShephed continuously sends random data over the network in an attempt to confuse session hijacking tools such as Firesheep. To an attacker, this is nothing more than a simple annoyance. FireShepherd does not change the fact that sensitive information is being sent insecurely.

Sending out lots of random data, especially over a wireless network, can disturb everyone else on the network and result in their connections becoming slow and/or unreliable. In addition, FireShepherd by default sends all this data out over the Internet to www.facebook.com, placing unnecessary load on their servers. This is usually referred to as a Distributed Denial of Service Attack, and is probably not something you want to participate in.

FireShepherd provides no real security and is harmful to Facebook’s servers and the local network which it is used on. Nobody should recommend using it for any reason.

In only one week, Firesheep has captured the attention and interest of hundreds of thousands of people around the world, and has spurred a lot of great discussion. This is the first in a series of posts highlighting and responding to topics I found most interesting.

I’ve received hundreds of messages from people who are extremely happy that the issue of website security is receiving attention. Some, however, have questioned if Firesheep is legal to use. I’d like to be clear about this: It is nobody’s business telling you what software you can or cannot run on your own computer. Like any tool, Firesheep can be used for many things. In addition to raising awareness, it has already proven very useful for people who want to test their own security as well as the security of their (consenting) friends. A much more appropriate question is: “Is it legal to access someone else’s accounts without their permission?”.

While the answer to this question is likely dependent on many variables and will almost certainly be debated for months or years to come, it should not matter to anyone reading this. It goes without saying that harassing or attacking people is a terrible thing to do. To suggest Firesheep was created for this purpose is completely false; Firesheep was created to raise awareness about an existing and frequently ignored problem. As I’ve said before, I reject the notion that something like Firesheep turns otherwise innocent people evil.

Reports have been trickling in that Microsoft’s anti-virus software is now detecting Firesheep as a threat, despite the fact that Firesheep poses absolutely no threat to the integrity of the system it’s installed on, and as mentioned earlier, has many legitimate uses. By installing anti-virus, you grant a third party the ability to remove files from your system trusting that only malicious code will be targeted. Microsoft and other anti-virus vendors abuse this trust and assert what they think you should or should not be doing with your computer. This is dangerous, but unfortunately not unprecedented. The same thing has happened over and over with Apple’s iOS App Store.

Firesheep has brought a discussion about very important issues into the limelight. Censorship does not offer a solution to these underlying issues, and will only cause further problems. For many people, code is a form of speech, and the freedom of speech must remain protected. If Microsoft wants to improve security with censorship, it would be more appropriate to block the insecure websites that are exposing user information in the first place.

Mozilla understands being a dictator is not their role and instead offers information about new features coming in the next version of Firefox that companies can use to further protect their users. Of course, companies have to care, and that remains a big problem.

In addition to questioning Firesheep’s legality, some people have questioned the ethics of its release. Similar tools have existed for years, so big companies, especially Facebook and Twitter, cannot claim they are unaware of these issues. They have knowingly placed user privacy on the back burner, and I’d be interested to hear some discussion about the ethics of these decisions, which have left users at risk since long before Firesheep.

Firesheep has generated an incredible amount of discussion and debate. Unfortunately, much of it has been taking place in the comments on this blog where following many threads is difficult or on GitHub which is really intended for bug reporting only. To address this and reclaim my inbox, I’ve created a new discussion group and kindly ask that people move conversations there.

More on the reactions to Firesheep as seen around the web soon.

This was certainly an interesting day. As I told TechCrunch:

I went back and forth trying to predict what the reaction might be. Initially before Firesheep was completed I thought there might be moderate interest, but then after doing more research found a lot of one-off articles discussing this same issue that were essentially ignored. I certainly never expected Firesheep to be the #10 trending search on Google in the US.

Most importantly, I certainly never expected there would be this much attention all at once, and within the first 24 hours.

I’ve received a ton of great messages from people who are happy that this issue has finally received widespread attention, so after day one I’m happy with the result.

Since being released just over a day ago, Firesheep has been downloaded over 129,000 times. Firesheep has consistently been one (if not more) of the “Top Tweets” on Twitter, on top of Hacker News, was at one point the #10 trending search on Google in the US, and is the second suggestion on Bing when you start typing “fire”. Firesheep has been mentioned on countless blogs and news sites in numerous languages, and has received almost universal praise.

The first bug reports have started rolling in:

• "Backend exited with error 1" — This happens on Windows when you stop capturing. This message doesn’t actually indicate a real problem and can be ignored. This was a known issue that I wasn’t able to get to before the ToorCon release.
• "Run --fix-permissions first" — This problem appears to affect only Mac OS X users who are using FileVault. The current release of Firesheep is unfortunately incompatible with FileVault.
• "Funky custom tool bar icon explosion." — This one is actually a bit amusing.

All of these issues will be fixed in the next release.

There have also been a few common problems:

• No results on some Windows systems — Some users have reported that they aren’t seeing any results even when on an open network that has known insecure traffic. This may be because the wrong interface is selected. Click the gear icon at the bottom of the Firesheep sidebar and choose Preferences. From here you’ll be able to change the interface Firesheep listens on.
• Sidebar not displayed — If you’ve installed Firesheep but don’t see it, click the View menu then select Sidebar then Firesheep.
• Install error claiming Firesheep is not compatible with your version of Firefox — Several people ran into this problem because they were unknowingly running out of date (and insecure) versions of Firefox. Apparently Mozilla’s auto-update system is leaving some people behind. Currently the latest version of Firefox is 3.6.11. Firesheep is not yet compatible with the 4.0 beta.
• Compile error on Linux — Firesheep is not currently supported on Linux and will not work. Patches/pull requests gladly accepted!

Keep an eye on this blog as well as my Twitter feed for updates on these issues and other new features.

The real story here is not the success of Firesheep but the fact that something like it is even possible. The same can be said for the recent news that Google Street View vehicles were collecting web traffic. It should not be possible for Google or anybody to collect this data, whether intentional or not. Going forward the metric of Firesheep’s success will quickly change from amount of attention it gains, to the number of sites that adopt proper security. True success will be when Firesheep no longer works at all.

An across-the-board improvement in website security will take time, but people are beginning to see the risks of using insecure websites right now. Unfortunately there has been a lot of misinformation about what people can do to protect themselves. The rest of this post is co-authored by my friend Ian Gallagher (@cdine) who presented Firesheep with me at ToorCon. Ian is a professional software security consultant with Security Innovation in Seattle. Below he explains many of the problems faced when trying to stay safe online, expanding on information that was included in our talk but not in my Firesheep announcement blog post.

Finally if you sent me an email, left me a voice mail, or posted a comment and haven’t received a response, please don’t take it personally. I’ve been sick, traveling, and overwhelmed, but will get back to everyone as soon as I can.

Background on HTTP Session Hijacking

HTTP Session hijacking, as a vulnerability, is nothing new in the year 2010. It is a security vulnerability that people have been aware of for quite some time, with notable tools and papers existing at least since 2004 on this exact subject. OWASP (The Open Web Application Security Project) categorizes the issues responsible for HTTP Session Hijacking in to one of it’s Top 10 Web Security Risks, “A3: Broken Authentication and Session Management”.

Firesheep is by no means the first tool to exploit this issue and raise controversy. "Ferret" and "Hamster" were a pair of tools released by Errata Security in 2007 which let users exploit Sidejacking attacks easily (well, easily for geeks, and undoubtably easy for attackers). In 2008, "Cookie Monster" was released by Mike Perry which lets you again do this same attack. Last year, (around May 2009) Azim Poonawala released the tool FBController which yet again exploited this same issue, though this time specifically targeting Facebook. Very little has changed after each of these tools were released. They got their media hype, and then people forgot or didn’t care. For the most part, the tools were only used by tech-savy people, hackers and geeks.

Firesheep

Firesheep is doing the exact same thing as these other tools, but with a simpler user interface. Firesheep is more generic than FBController, but it still needs to be aware of what sites to target.

Because of its simplicity, Firesheep has already succeeded in demonstrating the risks of insecure websites to a much wider audience than any previous tool, in a single day.

Why is it hard to stay safe?

Websites that don’t have properly designed security architectures and implementations can make it very difficult for users to protect themselves. There’s a few levels of failure here that are worth noting.

• Complete absence of SSL/HTTPS — This is rare nowadays for popular sites, but it’s not unheard of by any means. Until recently, Foursquare fell into this category. Naturally, if you use such sites you’re exposing everything needed to identify your session with the site, potentially even your password. This is particularly bad when you consider many people use the same password for many different accounts. It’s terrifying to think that something as mundane as a Foursquare password could get you in to that person’s email, or even financial websites.
• Charging for SSL - GitHub and Evernote are some examples where you must pay to have full-session SSL. We have not confirmed if this is implemented properly once you pony up the cash but can confirm that on GitHub a free account that is associated with a paying organization leaves that entire company at risk. A basic expectation of privacy should not be a premium feature. UPDATE: GitHub contacted me with a correction: Until recently paid accounts/repositories had no additional protection over free accounts/repositories. Fortunately all GitHub accounts and repositories (paid and free) are now secure.
• Forced SSL/HTTPS for posting of Login/Password credentials only - Most big sites are in this bucket. Facebook, Twitter, Github, etc. Years back, people realized that sending usernames and passwords in plaintext was a bad idea, and so everyone started encrypting the transmission of those particular assets, and boasting how secure they were because they use SSL with 128-bit encryption or whatever it may be, and pictures of locks everywhere. These sites may serve other content over HTTPS if you explicitly request it, but they’ll rarely be opportunistic about serving content over HTTPS. These sites fail to protect you because after you’ve authenticated, you’re issued a cookie that identifies you throughout your browsing session, but if you think about it that’s just as good as your username/password for 99% of the time.
• Full HTTPS for everything — Some sites support full encryption everywhere, but don’t implement it properly by failing to set the “Secure” flag on authentication cookies, negating most of the benefits and leaving users at risk. What that means is that any time you type the URL (e.g. “manage.slicehost.com”) into your web browser (without explicitly typing https:// beforehand, which people rarely do) you will inadvertently leak your cookies with that first request, prior to being redirected to the HTTPS page. Slicehost and Dropbox are good examples of this mistake.

You can’t simply avoid visiting the sites that are being attacked here. There’s an enormous amount of mixed content on the web today, such as the Facebook “Like” button, Digg’s “Digg It” button, twitter widgets, and even embedded images that are hosted on Flickr or other photo sharing sites. Every time you access any web page that includes any of this content, your browser also sends any authentication cookies you have with the request to pull down the widget. TechCrunch is a great example of this, every article has lots of little widgets to share it on numerous social sites.

Even if you’re proactive and think to log yourself out of a website, this rarely does anything but delete the cookies from your web browser - meaning any stolen copies of them are still going to work for accessing the website. Twitter, Amazon, Foursquare, Github, Flickr, Yahoo, Windows Live (Hotmail) and many others do not properly delete your session from their severs when you use their “Logout” features. Facebook, while having other problems, does appear to properly delete sessions on their servers when you “Logout”.

People forget things. It’s easy to be logged in to many of these services, sleep your laptop, and wake it up somewhere where it will instantly associate with an open access point and start spewing your cookies over the air. Hackers even fall victim to this at hacker conferences where everyone knows they shouldn’t be doing anything on the wifi. The DEFCON Wall Of Sheep is a prime example of this.

Suggestions to help protect yourself right now

While companies are implementing fixes (described below) you can do a few things to increase your level of security, but there’s no silver bullet (aside from stopping use of the services which you don’t want hijacked.)

• HTTPS-Everywhere - This is a Firefox extension created by the Electronic Frontier Foundation which makes Firefox use only HTTPS connections for certain websites. Like Firesheep, it only works on a defined list of websites, so it won’t protect you if you use any websites that it doesn’t support. It does not appear to be immediately simple for users to add sites without some development experience. HTTPS-Everywhere is well respected for doing what it claims to do safely.
• Force-TLS - As mentioned earlier, some websites support SSL but don’t implement it properly, leaving you at risk. This Firefox extension is similar to HTTPS-Everywhere but allows you to specify your own list of domain names to force encryption on.
• VPN - In some situations a VPN (or something similar such as an SSH tunnel) can be great. All traffic sent through a VPN is likely secure from your computer to the VPN server. But be aware that this is not a silver bullet and there are potential problems. See below for our warnings on using a VPN.

Things NOT to do (debunking suggestions from other people/sites in response to Firesheep)

Stop using open WiFi

In response to Firesheep, lots of people are quick to say “Don’t use open wifi”. While open wifi is the prime proving ground for Firesheep, it’s not the problem. This isn’t a direct vulnerability in wifi, it’s the lack of security from the sites you’re using. Abundant, free, open wifi is great to have, it can be very useful. Low-risk activities like reading the news, looking up a nearby business or finding a bus route can be done without being logged in to such sites and risking loss of any important sessions, for example.

A password-protected (WPA2) wireless network or even a wired network just requires that attackers perform one more step to carry out this attack. This might be ARP poisoning or DNS spoofing, neither of which are difficult to carry out. Go and download Cain & Abel and try it out on your network, it’s not that much harder than using Firesheep, and it’s been around for nearly a decade. There are other tools that’ve been around longer.

Another problem is that anyone who has your wireless password could set up their own rogue access point. If they have the stronger signal than the “official” access point everyone in the room will automatically connect to it instead and begin sending all their traffic to the attacker. WPA2 Enterprise was designed to solve this problem by allowing clients to verify the authenticity of the access point they are connected to. Unfortunately in addition to being very difficult to configure, a flaw known as "Hole 196" was recently discovered allowing users on the same network to spy on each other.

For these reasons it’s not very helpful to just enable WPA2 and write the password on the wall. Doing so might actually give users a dangerously false sense of security.

Use Tor

Another very bad suggestion is to use Tor.

Tor is designed to protect the identity and location of you, or more specifically, the computer you happen to be using. It does not protect what you are actually saying. Think of a whistleblower: someone who doesn’t want their identity revealed for fear of retaliation but who has a message to spread. Tor is perfect for this scenario, and has likely played a huge role in the recent success of WikiLeaks. For the purpose of protecting free speech, we love tor.

Tor works by bouncing your data all over the world to make tracing it back to you unfeasible if not impossible. After the final bounce your traffic lands on an "exit node", which relays it out to the Internet. Exit nodes are a lot like an open wireless network in that they are often run by random people who decided they're willing to share their connections with strangers in order to help them out.

If the operator of an exit node were to run Firesheep or a similar tool, they would be able to compromise any Tor user who was accessing insecure websites through this exit node.

Use a VPN/SSH Tunnel (Without known risks)

While we metnioned that VPNs and SSH tunnels can be helpful just above this, we want to emphasize that it’s just pushing the problem to that VPN or SSH endpoint. Your traffic will then leave that server just as it would when it was leaving your laptop, so anyone running Firesheep or other tools could access your data in the same way. These are solutions that require at least some understanding of networking and risks at hand. A blind suggestion of “Use a VPN” doesn’t really solve the problem and may just provide a false sense of security.

Another problem with VPNs is that they don’t work all the time. Sometimes they just disconnect, and your traffic is all routed over your normal interface without any notice. The built in VPN clients on OSX, the iPhone, and iPad are particularly bad at this.

How do website operators fix the problem?

The only correct solution to this problem is true end-to-end security. On the web, this is called HTTPS or SSL/TLS. When SSL is used properly, all traffic is encrypted (unreadable by attackers) and integrity checked (can’t be modified by attackers) from your web browser all the way to the website’s datacenter (either their actual web servers, or specialized network equipment such as SSL accelerators/load balancers).

Designing with security as a requirement, rather than bolting it on after the fact, is also important. While it’s not fair to say this is always what happens, it’s not uncommon for sites to be quickly designed and developed while letting security slip by at a lower priority than other things. Design such that when you scale out, you can scale out securely. Adopt and adhere to a Secure Development Lifecycle process to ensure that security is considered at all points during a product/site’s lifecycle.

Reasons operators may say they can’t do the above

• Typically the response to implementing SSL for everything on your website has been that it’s a big performance hit. There’s an awful lot of debate about this, but there are a number of sites that require HTTPS for everything, most notably Google’s Gmail service went 100% SSL earlier this year. While it’s true Google has an amazing engineering team and impressive resources, they outline a system that should be approachable by many other sites.
• Lack of IP addresses for SSL hosts. In the past, an SSL service required a dedicated IP address. This isn’t true any more with the advent of Server Name Indication (RFC 3546) and improvements in TLS.
• Ignorance. Many people believe they are doing things correctly when they simply are not. Forcing HTTPS for everything but not marking cookies as secure is key example.

Many companies make a business, not technical, decision to not implement security due to either perceived or actual costs. It is our opinion that turning a blind eye to customer privacy and security is never good for business, and we hope the people making these decisions will begin to agree.

This post has been updated since it was originally posted.

It's extremely common for websites to protect your password by encrypting the initial login, but surprisingly uncommon for websites to encrypt everything else. This leaves the cookie (and the user) vulnerable. HTTP session hijacking (sometimes called "sidejacking") is when an attacker gets a hold of a user's cookie, allowing them to do anything the user can do on a particular website. On an open wireless network, cookies are basically shouted through the air, making these attacks extremely easy.

This is a widely known problem that has been talked about to death, yet very popular websites continue to fail at protecting their users. The only effective fix for this problem is full end-to-end encryption, known on the web as HTTPS or SSL. Facebook is constantly rolling out new "privacy" features in an endless attempt to quell the screams of unhappy users, but what's the point when someone can just take over an account entirely? Twitter forced all third party developers to use OAuth then immediately released (and promoted) a new version of their insecure website. When it comes to user privacy, SSL is the elephant in the room.

Today at Toorcon 12 I announced the release of Firesheep, a Firefox extension designed to demonstrate just how serious this problem is.

After installing the extension you'll see a new sidebar. Connect to any busy open wifi network and click the big "Start Capturing" button. Then wait.

As soon as anyone on the network visits an insecure website known to Firesheep, their name and photo will be displayed:

Double-click on someone, and you're instantly logged in as them.

That's it.

Firesheep is free, open source, and is available now for Mac OS X and Windows. Linux support is on the way.

Websites have a responsibility to protect the people who depend on their services. They've been ignoring this responsibility for too long, and it's time for everyone to demand a more secure web. My hope is that Firesheep will help the users win.