What is meta? ×
Meta Stack Exchange is where users like you discuss bugs, features, and support issues that affect the software powering all 130 Stack Exchange communities.

Firesheep sniffs the network looking for session id's and makes it very easy for an attacker to hijack this authenticated session. It should be noted that Firesheep is nothing new ; it just makes this attack very easy. Many websites like Facebook (EDIT: Actually Facebook has patched this vulnerability) and Stack Overflow violate OWASP A9 - Insufficient Transport Layer Protection. A user can protect themselves by using a plugin like HTTPS Everywhere, but stackoverflow.com doesn't even have a valid certificate. Thus it is trivial to MITM https://stackoverflow.com and users have no way of protecting themselves.

Does the Stack Overflow team not understand the threat of OWASP A9? Do they not care enough to spend the $20 on a certificate to give users the option to protect themselves? Google has not experienced a significant increase in resource consumption by switching to HTTPS. At least give people the option to secure themselves.

Gmail switched to using HTTPS for everything by default. Previously it had been introduced as an option, but now all of our users use HTTPS to secure their email between their browsers and Google, all the time. In order to do this we had to deploy no additional machines and no special hardware. On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10 KB of memory per connection and less than 2% of network overhead.

Source: VeriSign

share|improve this question
29  
For sites the size of SO/SF/SU it is A LOT more than a 20$ certificate –  Zypher Nov 1 '10 at 22:47
4  
@Zypher true story, but my complaint is that i can't even use https everywhere. –  Rook Nov 1 '10 at 23:33
23  
Someone is already trying to hijack stackoverflow using firesheep (and asking a question on stackoverflow about it) stackoverflow.com/questions/4089665/… –  Zach Johnson Nov 3 '10 at 17:38
1  
@Zach Johnson very interesting. –  Rook Nov 3 '10 at 18:17
2  
@Zach I'm definitely not trying to hijack Stack Overflow. Using this plugin you can only hijack one persons account, and only if there happens to be another Stack Overflow user coding in the same Starbucks and using the WiFi. –  nevan king Nov 3 '10 at 19:58
14  
This is a reasonable question, but the hyperbole is unnecessary. –  Craig Stuntz Nov 17 '10 at 15:18
7  
@Craig Stuntz yes making sure your users don't get hacked is frivolous and decadent. Such a luxury is only enjoyed by twitter, github, gmail... ect. –  Rook Nov 17 '10 at 17:10
33  
@Rook, I hadn't realized that hyperbole was your first language. Sorry! –  Craig Stuntz Nov 17 '10 at 17:55
4  
Related historical incident: Protecting Your Cookies: HttpOnly (hoping Jeff, a moderator, or maybe even any 10k user will never be fooled into logging in to SO using some wifi on some conference). –  Arjan Jan 23 '11 at 14:59
3  
@Arjan We'll 2 things here. For one, httponly cookies does not prevent an attacker from sniffing your HTTP traffic and obtaining the cookie. Further more, httponly cookies can still be exploited by using XHR to "ride" on the session in an attack similar to CSRF. HttpOnly cookies is by no means a complete solution. –  Rook Jan 23 '11 at 17:09
2  
(@Rook, I know, but I was merely referring to the SO Über Admin account having been compromised two and a half years ago...) –  Arjan Jan 23 '11 at 17:12
1  
@Arjan oooooooah, thats a good point. –  Rook Jan 23 '11 at 17:37
2  
@DanBeale - even with WPA you can still ARP spoof, ICMP redirect spoof or run a rogue DHCP server to trick users into routing everything via yourself. Coffee shops are typically open too and a "password on the wall" WPA approach would allow you to run a rogue AP with the same SSID... –  Flexo Oct 13 '11 at 21:54
7  
I would like to see HTTPS on StackExchange. You can get 2 years of all-you-can-sign universally trusted extended validation certificates including unlimited alternative names and wildcards for about 200$ nowadays. TLS being a resource intensive thing simply isn't true anymore. –  aef Nov 10 '12 at 10:34
1  
@aef I'd even accept to trust a SE root CA certificate, but as Zypher said the problem is more about performance than about the certification. Although I'd argue that shouldn't be that much trouble after all. –  Tobias Kienzler Feb 12 '13 at 12:31

10 Answers 10

I was going to post this as a comment, but ran out of space.

For @Kop and @Rook:

For a site the size of Stack Overflow/Server Fault/Super User as well as the Stack Exchange network, you CANNOT just slap a $20 certificate onto your web servers and call it a day. You would kill the performance of the websites as SSL processing is a network-overhead intensive operation. Even though it is not as CPU intensive as I once knew to be true, you still do need to account for CPU in your planning, and implementation - because it does add overhead and when you are dealing with 10MM Monthly uniques that can start adding up quick.

To do this properly we would need to implement a highly available SSL load balancer/proxy that could handle the inbound SSL connections and not choke. To handle the load of the Trilogy in Four parts alone that would probably require (and I'm guessing here because we haven't run the numbers for obvious reasons) at least 4-6 very beefy servers, at about 6-8k a piece, plus Kyle's and my time to design, implement and test the solution.

Running SSL on a large website is NOT a cheap $20 certificate, and you don't just go slapping SSL certs onto your web servers and call it a day. For the amount of traffic we receive it is a lot more expensive and involved to get SSL running properly without degrading the performance of the site.

EDIT: Just to clarify BUYING THE CERTIFICATE IS NOT THE ISSUE

share|improve this answer
26  
It should be noted that you are one of SE's sysadmins. blog.stackoverflow.com/2010/09/… –  jjnguy Nov 1 '10 at 23:28
44  
to play devil's advocate: SSL isn't that expensive any more. –  Jeff Atwood Nov 2 '10 at 0:18
3  
Maybe you misunderstood my comment, but I simply meant the possibility of using https, not it being automatic on every page for any user. –  Andreas Bonini Nov 2 '10 at 11:16
13  
@Kop no I understood you, but you have to realize that engineering for the possibility of using SSL is the same as for forcing SSL, You need to solve the latter problem in case you find a large number of your users opting in to using SSL. –  Zypher Nov 2 '10 at 11:45
11  
I wonder if it would be an option to enable HTTPS for users with a reputation over 1000? That would solve the large number of users problem and be an incentive to use the site. It's like turning off ads for users with a higher rep. –  nevan king Nov 3 '10 at 21:07
4  
@nevan except the SSL connection is negotiated before anything else, so we would have to still have to design for a large amount of SSL traffic, and then redirect those under 10k –  Zypher Nov 3 '10 at 21:18
6  
@Jeff indeed, just ask google when they implemented https for everyone in gmail... without adding new hardware etc. the total performance degradation was a whopping 1%! –  alexanderpas Dec 10 '10 at 1:38
6  
@alexanderpas please re-read my post, the majority of it had very little to do with CPU overhead most of it was about following the 7P's. I'm not sure how much more i can emphasize you do not just throw certificates onto a very busy server and say "cool, all done let me rake in the money." The cost of the cert is definitely not the issue here. –  Zypher Dec 10 '10 at 2:17
3  
@Zypher, true, but isn't that cost associated with every change in hardware/software, and/or new features. Adding SSL should be handled just like adding any other feature -- also: The belief that switching to using pure SSL/TLS is any burden was obsoleted years ago with the addition of SSL/TLS Session Resume. Session Resume allows a particular client and server to perform the high-overhead public key negotiation just once quoted from the link in @BlueRaja post. meaning the more a user uses the site, the less an impact the negotiation has on the server. –  alexanderpas Dec 12 '10 at 6:40
9  
So what is preventing you from picking one of the newer low volume sites, perhaps security.stackexchange, and collecting some performance data? You seem to think it is a huge problem, but if you could actually provide proof, you would be a lot more convincing. –  Zoredache Jan 3 '11 at 22:16
6  
BTW, buying a $20 certificate completely and totally fixes my problem because i can use HTTPSEverywhere and not get hacked. Everyone else is still screwed. –  Rook Jan 8 '11 at 18:15
13  
It's not as simple as buying a $20 cert, sure. But in order to run a site like SO, you've no doubt had to solve a lot harder problems. Why is HTTPS proving to be such an obstacle for you? –  intgr Mar 30 '11 at 12:17
6  
It's worth noting, from Google again: "On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead." So, the increased network usage was also insignificant. –  Brendan Long Nov 9 '12 at 22:45
9  
If 2% of your effort is not worth spending on security, then you deserve to be hacked. This is disgusting. –  Rook Feb 18 '13 at 18:11
4  
This post makes SO look bad, perhaps it needs an update. –  Rook Apr 14 '13 at 21:14

We will be purchasing certificates for the network this week (dev is already in place), but there's still a lot left to do on the move to SSL. If you're curious about the details, you can read a recent blog post I wrote about it here.

It's far from a trivial task, but we're moving towards making SSL available and then the default. I'll continue to blog about the SSL implementation as we go (websockets may be interesting for example).

If there are current questions, I'm happy to answer them. As for this one: why aren't we doing anything? Well we are now... Why weren't we? Because it's complicated and wasn't even a possibility before now. Third party content (ads, MathJax, etc.) had to support it, and it didn't until very, very recently.

Update #1 Jun 20th, 2013: The setup/test procedures of the migration to SSL configs was much more involved when we saw how to do it safely on production. We will be testing our internal/virtual load balancers very early next week then prepping to deploy certs to production. The site code will take longer (making https:// the default, 301, canonical, etc.), but this will make SSL available soon as we can.

Notes: websockets are almost complete unknown on our intended setup, you may see intermittent connectivity with real-time as we figure out what fun times are involved with our setup and how SSL sockets will best work.

share|improve this answer
1  
+1 awesome news! –  Rook Jun 5 '13 at 2:06
    
@Nick, any update on this... Just now, while using Ask Ubuntu, I noticed that it defaulted to https:// for me on Firefox 26 (Win 7) but defaulted to http:// on IE 11 (Win 7)... I am not using any such add-ons which enforce https.. –  Aditya Jan 20 at 11:20
    
@Aditya we only use https:// for a login form, you have an addon in play if you're getting https:// links. –  Nick Craver Jan 20 at 13:44
    
@NickCraver: I don't use any such addons which enforce https://, it automatically defaulted to https for me for that session while the browser was open.. I have restarted the browser and it has gone back to its normal ways - only using http:// by default... I don't know what happened at that point of time :-) –  Aditya Jan 20 at 13:51
3  
What's the status on this as of Feb 2014? –  bmike Feb 11 at 16:04

Here's a setting I made for getting Stack Overflow cookies. Please note that I don't even know how to write "leet" and I made this by just looking at other settings in Firesheep, and asking on Stack Overflow about how to traverse the page HTML to get the user name. If I create an open Wi-Fi network at home, sign out of Stack Overflow on one computer (with Firesheep running) and then look at a Stack Overflow page on another computer (which is already signed in) I can get access without the login.

I don't think it's a huge deal for Stack Overflow. The worst you can do is impersonate a user and call other people names. Even deletes can be rolled back. It's much more serious for Gmail. That said, I'd like to be able to see what IP addresses have accessed my account.

Using this plugin, I've noticed that it's hard to use Google search on an open Wi-Fi without exposing your Google cookie. Even going to https://google.com redirects you to the insecure site. Worse, Google seems to ping home, exposing your Gmail account (even without visiting gmail, even if you have the "always use https" set in Gmail). If you want to search securely, you can use HTTPS anywhere, but I found it very buggy.

I hope you don't think I'm being irresponsible for posting this. Don't forget, ANYONE CAN DO THIS. Look at how simple the code is. It took me very little time to create, and very little knowledge (copying the template from another setting, looking at cookie names in Firefox, some JavaScript help). I actually started thinking about this after seeing this question on Meta Stack Overflow and finding nothing under the Firesheep tag on Stack Overflow.

register({
  name: 'Stack Overflow',
  url: 'http://stackoverflow.com/',
  domains: [ 'stackoverflow.com' ],
  sessionCookieNames: [ 'usr', '__utmz', '__utma' , '__qca' ],

  identifyUser: function () {
    var resp = this.httpGet(this.siteUrl);
    this.userName = resp.body.querySelectorAll('a')[3].textContent;
  }
});
share|improve this answer
2  
+1 great work, hopefully this will persuade the developers to take responsibly for their design. –  Rook Nov 3 '10 at 21:50
19  
"I'd like to be able to see what IPs have accessed my account." this has been visible on your user page for 2 years already -- search your user page for the words "last activity:" –  Jeff Atwood Nov 3 '10 at 22:10
10  
I'd prefer a list of the IPs, more like the way gmail shows the last 10 IPs that accessed your mailbox. With only 1 IP shown, you have to always remember to check it. –  nevan king Nov 3 '10 at 22:36
10  
@Jeff Atwood but if you are on wireless network then you'll have the same IP and there will be no evidence of the attack. –  Rook Nov 4 '10 at 0:28
4  
@Rook I don't think Stack Overflow can do anything about that. –  Yuhong Bao Nov 4 '10 at 7:30
3  
@Yuhong Bao this is 100% caused by developers. gmail solved this problem years ago, github fixed this last week, facebook is soon to follow. –  Rook Nov 5 '10 at 5:43
3  
@Rook Um, you seem to have interpreted something wrong... I'm pretty sure Yuhong Bao meant that SO can't do anything to show the user which of the computers from the same wireless network (with the same IP) have accessed your account. –  Ilari Kajaste Nov 19 '10 at 13:00
1  
@Ilari Kajaste your right, thats why So should at least have the option of SSL. –  Rook Nov 19 '10 at 16:01
10  
@Jeff: All I see from last activity is the obvious - my own activity from 43 seconds ago. What about a list of previous IP addresses. Maybe the last 5. I use SOFU at home and work. So anything other than those IP addresses would cause concern. –  IAbstract Dec 10 '10 at 12:59
    
encrypted.google.com securing against firesheep will imply making the website access https only like gmail. an opt-in trial run for interested SO or metaSO users won't hurt. –  abel Jan 7 '11 at 20:36

If you have a "man in the middle" then there are deeper problems, like, you're using a compromised network.

We do actually cycle part of the cookie every so often, so if someone has an old cookie of yours it probably won't work. That's assuming they stop listening, and you keep using the site.

Also, we don't think the risk of someone stealing your Stack Overflow account is very dangerous compared to, say, your online banking account, or your gmail (remember email is the de-facto skeleton key for all online logins that I know of).

share|improve this answer
7  
While I agree, I also agree with the OP's point about the $20. How can having a valid certificate hurt anything? It will make the paranoid people happy. =) –  Andreas Bonini Nov 1 '10 at 23:05
13  
@rook why don't you direct your outrage to the other 99.99% of the web which also has this "problem"? –  Jeff Atwood Nov 1 '10 at 23:55
30  
@Jeff Atwood "but there's lots of sql injection on the web, why should I patch my application?" –  Rook Nov 2 '10 at 0:26
9  
@rook not the same thing; you're complaining about the way the web works, not the way our code is written –  Jeff Atwood Nov 2 '10 at 1:23
37  
@Jeff Atwood What is so bothersome is that this issue doesn't affect you, it affects every single one of your users. This callus attitude towards others safety is what is so deeply offensive to me. It is trivial to provide https to the ones who want to use tools like https everywhere to protect them selves, but your response is so iconic of people who are hacked: "Why would anyone hack me?". –  Rook Nov 2 '10 at 1:36
11  
@rook so use a https proxy -- you already have a way of doing this. stackexchange.com/search?q=https+secure+proxy –  Jeff Atwood Nov 2 '10 at 1:46
42  
@Jeff Atwood I wish I could vote down comments. –  Rook Nov 2 '10 at 1:50
25  
"If you have a "man in the middle" then there are deeper problems, like, you're using a compromised network." - That is, if you assume every internet backbone, and all the links between them, are trustworthy and uncompromised. :) Just sayin' –  BlueRaja Nov 5 '10 at 15:34
27  
Do the airport and Starbucks count as compromised networks? Seriously, though, SO is not exactly my bank. If you can hack my SO account the worst thing you could do is post garbage that the mods would have to clean up. As far as this being "the way the web works", I think companies like Twitter and Facebook should be leading the way in this department. SO will be here to answer their technical questions while they're working on it. And once the web works a different way, SO can follow suit. –  user27414 Nov 8 '10 at 16:28
14  
I agree with Rook on this. It doesn't matter how the site is coded if my identity is transmitted in clear text. Sure the impact of a stolen account is relatively small, but that's not the point. The fact that SO could easily combat this and choose to do nothing while telling people to lobby the website operators is, quite frankly, baffling. –  Chris Lively Nov 15 '10 at 17:09
7  
@chris it's a fundamental architecture issue with the web, and we are not your bank. Read more: codinghorror.com/blog/2010/11/breaking-the-webs-cookie-jar.html –  Jeff Atwood Nov 15 '10 at 20:27
11  
@Jeff: I read the blog, which is what drove me here. Two things you said come to mind. First: "I sure do care if they somehow sniff out my cookie and start running around doing stuff as me!" Second, "this is not an unreasonable thing to ask your favorite website for." –  Chris Lively Nov 15 '10 at 20:35
7  
@Jeff: "there is nothing social here" Er, what? I would consider this exact thing were doing here, discussing, quite social indeed. Sure, we don't connect to other identities here, but so what - I've done a lot more social activity here than in LinkedIn. Maybe you have a different definition of social? –  Ilari Kajaste Nov 19 '10 at 12:51
42  
@jeff I read your blog why are you recommending: "Lobby the websites you use to offer HTTPS browsing.", When this is exactly what I'm doing and you shot me down. –  Rook Nov 19 '10 at 16:05
11  
This thread is kind of like finding out Santa Claus isnt real. –  Dubyaohohdee Mar 22 '12 at 17:50

For what it's worth, Jeff now appears to believe that "maybe encrypted connections should be the default for all web sites."

ENCRYPT ALL THE THINGS

I know that Jeff is leaving Stack Overflow in March 2012, but this post of his may be one indication that full HTTPS support is not all that far off.

share|improve this answer
3  
it is a hairy technical problem.. not a 6-8 weeks thing, will probably eventually happen –  waffles Feb 24 '12 at 2:37
    
@waffles, 6-8 weeks?! He's only got 5 days! :) –  Benjol Feb 24 '12 at 6:28

I agree that you should fix this right, with TLS/SSL.

In the meantime, Ben Adida's proposal/code for "SessionLock Lite" offers an inexpensive interim approach that looks like it at least protects against persistent hijacks by passive attackers. Of course it offers no protection against eavesdropping. There is also a short and worrysome window of vulnerability to a tool like firesheep, which you should take other server-side approaches to mitigating. But it can reduce the exposure while you engineer your SSL solution: http://benlog.com/articles/2010/10/25/keep-your-hands-off-my-session-cookies/

By the way - do you at least actually expire cookies on the server side when users log out?

share|improve this answer

May I suggest a compromise?

I think that the information which is not available publicly should be served over secure connections. These can include:

  • when a moderator visits a page which is only accessible to moderators
  • when a user visits his/her own userpage
  • when a user logs in using the log-in page

This shouldn't create a performance problem since the number of visits to these pages is limited. Also this is consistent with what large companies like Google used to do: user account setting pages were served over secure connection even when the https was not default for GMail.

Let me add that I think these pages should be served securely since they contain private information about users and SE should make sure that the information on these pages remains private.

share|improve this answer
1  
Nice, but I think that would imply one needs to explicitly log in when first accessing the HTTPS pages? (Or, more likely: make the login pages HTTPS too, killing 2 thingies with one stone.) But when done, it would indeed disallow others from locking you out or from adding an additional OpenID. Above all: I very much like the idea to protect moderator actions. –  Arjan Apr 25 '11 at 9:41
5  
Right, but what i care about is having my session hijacked. If someone does this then they will view all of my information in https. –  Rook Apr 25 '11 at 15:53
9  
@Kaveh you are missing the point of OWASP A9 and Firesheep. Every request you make to SO has your session id, if you are on an open wifi network (which i am right now), then everyone else on the network can see this session id. Firesheep sniffs the network and lists every sessoin id it finds. You just click on the hijacked session and then you become them. HTTPS for the entire life of the session is the only way to prevent this. –  Rook Apr 25 '11 at 17:54
3  
-1 I fail to see how this improves the security of so. –  Rook Apr 25 '11 at 17:55
2  
Also gmail uses https for everything because of attacks like firesheep. –  Rook Apr 25 '11 at 17:56
1  
@Rook, as I said this was the practice of GMail up until a few months ago, and their switch to complete https was quite recent, I don't know the exact reason but I don't think firesheep like attacks was the main reason, I think issues with suppressive middle eastern governments may have been more part in their decision. –  Kaveh Apr 26 '11 at 2:53
2  
@Kaveh It is all or nothing. You either prevent ease dropping style attacks, or you succumb to them. Google switched to https for many of their services because governments where engaging in firesheep style attacks. –  Rook Apr 26 '11 at 2:59
2  
What you are proposing is an owasp violation. On SO I always downvote violations. –  Rook Apr 26 '11 at 3:11
2  
@Rock, of course you can, that is your vote! :) Btw, I am not suggesting violating anything, I would personally prefer if every page was served on https. But since it seems that SE is not ready to do it at the moment, I would prefer an improvement. And what I said is also correct, what I suggested is a significant improvement over the current situation and is the current practice of many of super large sites like Amazon. –  Kaveh Apr 26 '11 at 3:15
1  
@Rook, I'm quite sure that every page in Gmail has privacy sensitive information on it: email! Here on SE, not so much. Even the SE Inbox shows public information. Apparently, the team thinks that the traffic of logged-in users is not small enough to use HTTPS for every logged-in request. Then I agree with Kaveh that a limited set of data and actions (that are deemed personal or dangerous) could be secured by enforcing HTTPS for those pages (obviously requiring a secure cookie too). –  Arjan Apr 26 '11 at 11:48
2  
@Arjan @Kaveh Wow so you guys could care less if a child could hijack your account? Really? Am I really having this conversion? –  Rook Apr 26 '11 at 15:48
2  
@Arjan I know that any time you transfer an authentication credential over plain text you have a vulnerability it doesn't matter the protocol. The most expensive part of SSL/TLS is the handshake, all further requests use a the cached "master secret" and the overhead is minimal. It is all or nothing. –  Rook Apr 26 '11 at 16:39
2  
@Kaveh The name is rook, like the bird in my icon. The most expensive part of TLS/SSL is the handshake to establish a master secret. This master secret is then cached and used for the life of the session. Facebook is now pure https because Mark Zuckerburg was hacked by Firesheep. When a large company does this they buy an appliance that just takes care of handshakes. This does cost money, and the SO team likes money more than security. –  Rook Apr 26 '11 at 16:50
2  
@Kaveh the only thing your propose is only a waste of resources. What is more concerning is that you think that it helps. No doubt you are a respected and well accomplished developer, that unfortunately is very convincing and doesn't understand security. Please read the OWASP top 10. –  Rook Apr 27 '11 at 8:20
2  
@Arjan it boggles my mind that you think that this helps at all. Do you have like a 2 foot fence around your house that people just step over? –  Rook Apr 27 '11 at 8:23

My first guess is that advertising won't support HTTPS therefore making a mixed session and the user having to deal with the browser "do you want to continue" dialogs

More information: Google Ads doesn't support HTTPS. What alternatives are there?

Perhaps SO had a different way of dealing with advertisements.

share|improve this answer

Why doesn't the Stack Overflow team fix the Firesheep style cookie theft?

Because even the high-rep users have rate limits, so if the accounts are broken into, there's very little damage that can be done to Stack Overflow at all, and what damage is done is easy to remedy.

It's likely something that will be addressed more completely at a later date, but it would take a concerted effort to pull something like this off.

For instance, go to CES with a few friends and set up their notebooks to sniff and report the cookie information to a central server. That server then figures out which accounts it's gathered, and sets up a controller so that a single user can insta-close questions, post questions and insta-vote them up, etc. using several accounts.

However, Stack Overflow already has significant monitoring, rate limiting, and firewall blocking for abusers, and chances are good such a simple setup (as above) would be blocked with the current setup.

The biggest danger is if someone gets the cookie from a moderator, at which point they can do some damage that can't easily be rolled back.

share|improve this answer
2  
No more CES and the like for moderators and Jeff ;-) –  Arjan Feb 2 '11 at 20:17
4  
I'm still left wishing that SO cared about secuirty. –  Rook Apr 26 '11 at 16:42
3  
Boo for a response that says "It only causes damage to the hacked user, so SE et. al doesn't give a crap". Glad my bank doesn't take that approach to security. –  Lawrence Dol Jan 19 '13 at 21:08

There are ways to prevent cookie leaks without using SSL and that will add very little load.

When session is created, generate a random number (R) and associate it with the session. Pass this number back to the browser as part of the login process (so it's covered by SSL, and is therefore secret).

Then for each request over HTTP:

  • browser generates random number Q.
  • browser calculates S = SHA1(Q + R)
  • browser includes Q and S in the request along with the session cookie

  • server receives request, verifies SHA1(Q + R) = S and if so, session is valid.

Not hard to do, adds about 40 bytes per request header, and increased server load is negligable. Breaking this requires some sort of XSS flaw which reveals R, breaking SHA1 or guessing the random number sequence, none of which are going to be quick.

share|improve this answer
    
So the way to prevent using SSL is... to use SSL? I don't get it. –  Aarobot Nov 8 '10 at 16:38
2  
SO never use SSL, not even for the login process. They rely on a 3rd party OpenID provider to handle the secure login, so your solution still adds a new SSL piece to the mix. –  heavyd Nov 8 '10 at 16:45
1  
Ah, well there's not me using StackOverflow much. Actually at all. The solution allows only the original login to be done over SSL but the rest to be done over HTTP, which is a lot cheaper than moving the whole site to use SSL. But yes, it still needs the initial connection to be done via SSL. –  user153246 Nov 8 '10 at 16:47
3  
-1 you're transmitting the secret used in a MAC in plain text, thus defeating the whole point of MAC. Further more, if the hacker can modify html and javascript used to generate the page and thus obtain your secret Q. Don't build security systems, this suggestion is horrifying. –  Rook Nov 17 '10 at 17:13
1  
You need ssl and don't let anyone tell you otherwise. –  Rook Nov 17 '10 at 17:14
2  
But how would that secret number R be stored in the browser for subsequent requests...? –  Arjan Dec 10 '10 at 9:18
1  
Intriguing. Though this does not fully protect against a MITM attack since the attacker can just pass along the value for SHA1(Q+R), and do anything else they want with the request. –  nealmcb Jan 2 '11 at 1:17
2  
@rook - Q is only in the browser, fresh for each request, not sent over the network. A MITM attacking the javascript sent to the browser is a clever idea - I wonder if it is possible in the browser to somehow rely on javascript sent in the initial secure session, saved in local storage via HTML5. But I agree - at best a pretty risky, fragile and tenuous proposal. See more discussion at security.stackexchange.com/questions/1322/… –  nealmcb Jan 2 '11 at 1:39
2  
@nealmcb a message digest function cannot solve this problem. As the top answerer of cryptography questions on SO I'm telling you that SSL is the only solution to this problem, do not tell people otherwise. –  Rook Jan 2 '11 at 4:02
    
@rook yes - we agree this is certainly no substitute for ssl, and overall a foolish direction to go at best. I'm just curious to know if the server with html5 could prevent the MITM from stealing a reusable session identifier. Not that that would help the user very much given all the stuff an MITM could still get away with. And I was just clarifying that the proposal here didn't "transmit the secret in plain text", even though most likely the MITM could also pry it out of the browser as noted earlier unless html5 has good facilities to allow a great javascript programmer to prevent that. –  nealmcb Jan 2 '11 at 6:41
1  
@nealmcb your solution makes the attack window smaller. There is still the problem of loading the html/js to begin with. If there where a way to sign this content then this solution may hold water. But as it stands if i protocol is insecure at any step, it is unusable. –  Rook Jan 2 '11 at 18:45
    
@rook: yup - it would need to be secure all the way, I've seen no evidence it could be made secure, and there be dragons at all turns.... Plain SSL would surely make more sense. Thanks for helping clarify this stuff. –  nealmcb Jan 4 '11 at 3:27

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .