How Facebook Responded To Tunisian Hacks

jamie writes "Facebook's security team opens up, shedding light on a revolution that could become a parable for Internet activism. Quoting: 'After more than ten days of intensive investigation and study, Facebook's security team realized something very, very bad was going on. The country's Internet service providers were running a malicious piece of code that was recording users' login information when they went to sites like Facebook. By January 5, it was clear that an entire country's worth of passwords were in the process of being stolen right in the midst of the greatest political upheaval in two decades. Sullivan and his team decided they needed a country-level solution — and fast. Though Sullivan said Facebook has encountered a wide variety of security problems and been involved in various political situations, they'd never seen anything like what was happening in Tunisia.'"

Comments

Duh

[Locke2005]

How badly does Facebook's password encryption suck if a man-in-the-middle attack can easily steal everybody's password?

Re:Duh

[Anonymous Coward]

I believe the ISP changed the facebook login page to execute additional javascript to grab the entered password before it was sent off, encrypted, to the fb server. But then again I didn't RTFA...

Re:Duh

[h00manist]

I wonder how they're going to fix it now that the passwords are all stolen already.

Re:Duh

[Sponge Bath]

Send flowers to the funerals of the oppressed exposed by this security breach?

Re:Duh

[reaper]

As bad as every other site that doesn't require https:// for login.

Re:Duh

[Yvan256]

Add the character "2" at the end of all current passwords?

Re:Duh

[whoever57]

How badly does Facebook's password encryption suck if a man-in-the-middle attack can easily steal everybody's password?

The attack may have been a little more sophisticated. Most pages are loaded over a non-encrypted connection. Just the pasword may be sent over an https connection. However, the use of unencrypted pages for everything else allows man in the middle attacks that insert a javascript keylogger into the reply that logs keystrokes directly from the source PC, not from packets as they cross the wire.

That's why FB's response was to respond to all requests from Tunisia using https. That's why GMAIL now defaults to 100% https.

Re:Duh

[Locke2005]

A valid point -- end-to-end encryption in both directions is required. Meaning the calls to always use https actually make sense.

Re:Duh

[91degrees]

Inform the user that their password is very likely compromised. Leave it up to the user to change it. They could even deliberately force the user to change their password via an email link.

Re:Duh

[chemicaldave]

How badly does Facebook's password encryption suck if a man-in-the-middle attack can easily steal everybody's password?

How exactly was Facebook supposed to encrypt the users' passwords before receiving them? If you know how to do this then I'll write you a check right now.

Re:Duh

[by (1706743)]

I could have stolen innumerable facebook passwords when I was in college. When you register your computer for the campus network, you can choose your hostname, which would then be a FQDN -- ..edu . So I registered the "facebook" hostname, and any time someone on the campus network typed in "facebook" (without the .com), it would resolve to me. I ran a redirect to my profile page on facebook.com, just for the hell of it (I eventually got, um, told that I should find better ways to amuse myself...).

It would have been trivial for me to host a false facebook login page, capture the credentials and then redirect to the real facebook login / invalid password page; I would have the password, they would get to log in (I'd like to stress that I didn't actually do this). I haven't R'd TFA, but I suspect you could do something similar on a much larger scale.

Re:Duh

[Critical Facilities]

Agreed, but this part of the article had me intrigued:

It wasn't a totally perfect solution. Most specifically, ISPs can force a downgrade of https to http, but Sullivan said that Facebook had not seen that happen.

I do not know the ins and outs of internet routing well enough to understand this, but I was alarmed by it. Does anyone with more technical expertise in the area have any insight?

Re:Duh

[Anonymous Coward]

Anyone who logged in during the period of time where passwords were being captured was presented with photos and asked to pick the ones featuring their friends. Then they were asked to choose a new password.

Re:Duh

[kalaudio]

It looks to me the attack either wasn't that pervasive, or the solution wasn't that thorough:

Sullivan's team rapidly coded a two-step response to the problem. First, all Tunisian requests for Facebook were routed to an https server. The Https protocol encrypts the information you send across it, so it's not susceptible to the keylogging strategy employed by the Tunisian ISPs.

Https would still be suceptible to keylogging. I won't detail how the attack would be laid out (wouldn't want to inspire potential attackers ;) ), but https won't protect from a keylogging javascript being attached to the login page by an ISP. Do your research on MIM attacks if anyone wants to find out. So, either the solution won't work, or the attack wasn't as cleverly implemented. And let me say which one it is: both. I've just inspected facebook's login page, and it transmits passwords in the clear (in a POST request), protected only by a MIM-vulnerable https implementation. Yet, the article says facebook reports that their workaround "seems to work". It would only work if the attack was poorly implemented.

Re:Duh

[rjstanford]

The good news is that the answer to your question is spelled out explicitly in TFA...

Re:Duh

[rwven]

Facebook doesnt use an SSL login page.... It was totally unencrypted.

Re:Duh

[Anonymous Coward]

I'm sorry, obviously you have nevver heard of HTTPS. You are a moron, perhaps?

Re:Duh

[JoshRosenbaum]

They may just mean that an ISP can modify the HTML delivered to the user so that the form submit action is set to the http address vs https.

Re:Duh

[Jahava]

Agreed, but this part of the article had me intrigued:

It wasn't a totally perfect solution. Most specifically, ISPs can force a downgrade of https to http, but Sullivan said that Facebook had not seen that happen.

I do not know the ins and outs of internet routing well enough to understand this, but I was alarmed by it. Does anyone with more technical expertise in the area have any insight?

I think it's simple: Facebook allows HTTP logins, but defaults to HTTPS. The ISP could respond to the initial HTTPS request with a redirect to the regular HTTP version.

Re:Duh

[MichaelSmith]

The ISP can run a proxy which pretends to be the user from the point of view of facebook and pretends to be facebook from the point of view of the user. It can run an https connection to facebook and forward it to the user as a plain http connection. That way it can record or change anything in the facebook session and the user probably won't be aware that the proxy is there.

The proxy could also run an https connection between the proxy and the user but that is more difficult because encryption software in the browser would alert the user that the proxy is not facebook. However if the browser has been fiddled with its game over for the user on many levels. Lots of people in the third world access the internet from internet cafes. One place I used in Malaysia has a single windows image which is booted across the LAN when a workstation is started. If the Government got their own software on to the server with that image, or changed the template for all the internet cafes then it would be impossible to guarantee security.

Re:Duh

[chemicaldave]

I'm sorry, obviously you have nevver heard of HTTPS. You are a moron, perhaps?

HTTPS relates to the connection between the users and Facebook. It has nothing to do with the way Facebook encrypts the passwords themselves, which is what I was pointing out.

Re:Duh

[Anonymous Coward]

https://www.facebook.com/ would disagree with you. As would TFA.

Re:Duh

[jdogalt]

Agreed, but this part of the article had me intrigued:

It wasn't a totally perfect solution. Most specifically, ISPs can force a downgrade of https to http, but Sullivan said that Facebook had not seen that happen.

I do not know the ins and outs of internet routing well enough to understand this, but I was alarmed by it. Does anyone with more technical expertise in the area have any insight?

Not like I've RTFA or anything, or even an expert, but my guess is simply the issue of- facebook _allows_ http logins, so all a nefarious government/network need do is break https for the site. I.e. the solution is to not have an unencrypted option, such that if a gov/net breaks https, instead of falling back to an insecure login, people get pissed that they can't use the site at all, and thus it becomes a high profile news story, etc.

Re:Duh

[Frosty Piss]

Feel lucky you didn't end up in front of a judge.

Re:Duh

[MichaelSmith]

Good evening Mr By I represent the Government of Tunisia. A new future awaits you as an employee of the fastest growing security establishment in Africa...

Re:Duh

[Anonymous Coward]

Facebook (and pretty much all websites) have at least one regular HTTP page that you get when you go to http://www.facebook.com. This is necessary to respond to people visiting the site as http://www.facebook.com, and even if this page is an automated redirect to https://www.facebook.com, it presents the following problem.

Someone between you and Facebook could create a transparent proxy that interacts with you through HTTP and with Facebook through HTTPS. To you, this would mean you never see the little lock on the browser and all the URLs you visit on Facebook will start with "http://". The proxy would intercept and convert any HTTPS links Facebook sent you to HTTP links in the HTML document, and would perform its own HTTPS interaction with Facebook using whatever information you provided through those links returning the response to you as HTTP.

This is likely observable on both ends if it occurs. On the client side, as mentioned, formerly HTTPS operations would all be done through HTTP. On the server side, they would probably see a small pool of IP addresses performing HTTPS connections to them. I suspect it is possible to fake out the servers by setting up the transparent proxy and routers to intercept HTTPS communications to client IP addresses such that it would appear to Facebook that the clients themselves are performing these communications. It should always be evident to clients that HTTPS is not being called by their web browser, but this isn't obvious if you're not looking for it.

Re:Duh

[rwven]

Log out of facebook and go here:
http://www.facebook.com/index.php The login page is not secure by default (though you can manually type https if you want). Unless you explicitly tell facebook to be HTTPS, it won't be. How many users do you know who would do that? I can't think of a single one....

An ISP could easily inject a javascript keylogger into this page. It would be downright trivial.

Re:Duh

[realityimpaired]

Obviously you've never heard of a MITM attack. HTTPS is vulnerable to it.

It *is* possible to encrypt the password for real before the password gets passed to the server, by means of using some javascript with a one-way encryption (think pgp) and a public key, but that would require disclosing the public key as well as the encryption algorithm being used, which isn't very good mojo.

Re:Duh

[Magic5Ball]

To encrypt users' passwords before receiving them, you could run (parts of) your cryptographic algorithms on the client, as TLS, SecurID and umpteen other implementations do. That would render the credentials differently vulnerable to interception via MITM than sending them as clear text.

No professional would sell you such a point solution though, because attaching it to a system that implements the security model you imply would be detrimental to one's reputation if discovered. To my knowledge, as confirmed by TFA, Facebook implements more robust security for authentication than "encrypt[ing] the users' passwords".

Re:Duh

[JoshRosenbaum]

I think I can help a little here. If you aren't using https for logins, then you can do some password hashing tricks to make things much more secure. I developed a similar solution for this at my last job. I checked some other sites to see if they used it when I developed my solution and found that yahoo email did pretty much exactly the same thing when they were using http (non-secure) logins.

Basically the idea is something like this:

*) Server sends a random long string along with form. This string has a time component (either via additional encrypted serialized string or via server-side session storage) and will expire after an hour or less to prevent it being re-used by someone else for a submission. (Can also be expired once used by user to login.)
*) clientside javascript hashes this random long string (possibly more than once) along with password and sends to server. (This protects from rainbow table attack of password using the hash.)
*) server verifies that the hashed values match.

This is a basic overview. I did some other tricks and what not to increase security. I think I looked into using the PKCS standard for some stuff, but can't remember. There are probably some other ways to do this. I think I looked into actual encryption (years back), but javascript was too slow at the time. That might not be the case as much anymore.

Re:Duh

[icebike]

https won't protect from a keylogging javascript being attached to the login page by an ISP.

It would protect if there was no http login page. You have to get the javascript installed before you launch https because you can't get it installed later.

With most browsers, simply having the http page remap to the https page leaves the keylogger free to continue to run. But if you start your session with https you are reasonably safe from key loggers done in javascript.

Re:Duh

[TheMidget]

Meaning the calls to always use https actually make sense.

Indeed. Most (all?) those online services, whether it be yahoo, facebook or myspace have their login box accessible from their main (non https) page. Even though login itself may be encrypted, the user is not supposed to enter the https himself, but he is instead redirected to a https page once he clicks login.

... which makes it easy to hijack this first step, and unless the user doublechecks the URL just before login for https, he will fall for it.

It's scary how easy this is (I once did it for a friend who wanted to spy on his estranged wife), and you don't even need any funny javascript. Just have a proxy that substitutes https://login.service.com/ with http://login.service.com/ and you're set.

This also makes those obnoxiously scary "bad certificate" warnings so pointless: the smart man-in-the-middle will avoid the certificate issue entirely, and just redirect everything to non-encrypted http.

The only solution to this is to make the user aware of the process. Make it explicit that in order to login, you need to go to https://www.facebook.com/ or https://yahoo.com/ . That way, the user is forced to "do the right thing" if he wants to log in, and an interloper will have much more trouble intercepting. Instead of just hacking up a quick proxy perl script, he'll actually have to ask TunisCert to issue a fake certificate...

Re:Duh

[DavidRawling]

It *is* possible to encrypt the password for real before the password gets passed to the server, by means of using some javascript with a one-way encryption (think pgp) and a public key, but that would require disclosing the public key as well as the encryption algorithm being used, which isn't very good mojo.

WTF? There's nothing wrong with disclosing the public key (hint: it's right there in the name. You can encrypt with the public key, publish the key on websites, in newspapers, hell broadcast it on national radio - it doesn't matter. That's the point. Just don't publish the private key.

Re:Duh

[jonbryce]

If you RTFA, they required people to identify pictures of their friends to prove they were the real account holder.

Re:Duh

[jonbryce]

The conncection from home computer to ISP proxy server is by http. The connction from ISP proxy server to Facebook is by https. The proxy server can then modify the page before sending it unsecured to the home computer.

Re:Duh

[Fulcrum of Evil]

and without a client key, you can spoof the login page (redirect to http if you like), add some JS that hands you the password, and you're done. Not sure what you expect to do with the token.

Re:Duh

[TheMidget]

The ISP can run a proxy which pretends to be the user from the point of view of facebook and pretends to be facebook from the point of view of the user.

Wouldn't work if the user connects directly to https (as in, "enters https URL into address bar" or "has https address bookmarked").

Unfortunately, in the name of the sacrosanct "user friendliness", that's not how most sites work. Most sites ask the user to go to a plain http address, which they then redirect to https. This is vulnerable to a malicious proxy, which just makes sure that that redirect doesn't happen...

However, a properly set up https (i.e. to which the users connects directly) cannot be thwarted in such a fashion, as far as I know.

Re:Duh

[WaffleMonster]

I think I can help a little here. If you aren't using https for logins, then you can do some password hashing tricks to make things much more secure. I developed a similar solution for this at my last job. I checked some other sites to see if they used it when I developed my solution and found that yahoo email did pretty much exactly the same thing when they were using http (non-secure) logins

The very first rule when it comes to security is under no circumstances should you ever even think about rolling your own.

*) clientside javascript hashes this random long string (possibly more than once) along with password and sends to server. (This protects from rainbow table attack of password using the hash.)

This would be the reason why. Your essentially asking a liar to be truthful. What would prevent an advasary from providing their own client code to ship your plaintext elsewhere?

Re:Duh

[JoshRosenbaum]

Good point. The solution I mentioned only works when ISP or middleman isn't injecting things. Sorry about the unnecessary reply.

Re:Duh

[TheMidget]

but my guess is simply the issue of- facebook _allows_ http logins

No, the main problem is that facebook expects the user to enter a http URL, and then redirects to https. All a malicious man in the middle man has to do, is disable this redirection.

Having no plain http login won't help, because the middle man can always present a http login page to the user, and translate the user's response to https and forward it to the server. The browser won't notice any mismatched certificate, as the connection at that end is still http. And the server doesn't check for certificates (unless client certificates are used, but that would be really cumbersome for a free service such as facebook...)

Re:Duh

[psyclone]

Um, the whole point of Public Key Cryptography is that the public key and the algorithm can be known by the attacker.

If this was implemented over plain HTTP, the problem would still exist. The attacker (government in this case) would overwrite Facebook's public key in javascript with their public key, decrypt the password, then pass it on to Facebook just like any old Man In The Middle attack.

Re:Duh

[TheMidget]

That's why FB's response was to respond to all requests from Tunisia using https.

That would still leave those users out in the cold that don't know that they're now supposed to enter https://www.facebook.com/ . Unfortunately, that would be 99% of the users...

Re:Duh

[JoshRosenbaum]

This solution only works against listeners, not injectors. So it provides a defense for those cases. It is not any less secure, but I admit to it being useless in this case where they probably were doing injection. (Didn't read article, probably should've.)

Re:Duh

[TheMidget]

I'm sorry, obviously you have nevver heard of HTTPS. You are a moron, perhaps?

Welcome to the real world... where most people couldn't care less whether a connection is http or https. And where most web services have a "user friendly" entry page accessible via http (which then may, or may not redirect to https for login purposes). But as the entry point was http, a man in the middle can then just disable https from that point on, and insert his own http-to-https proxy. As most users are unfortunately morons, they won't notice the missing lock icon, and the missing s after http. And no noisy "bad certificate" warning either, as the connection between browser and man-in-the-middle is still http...

The world would be a safer place, if we had set up our secure sites such that user needed to enter the s after http explicitly, rather than pandering to the morons who can't be bothered. By "helpfully" redirecting http to https, we have educated a generation of users that they don't need to care about those finer points...

Re:Duh

[oogoliegoogolie]

I guess Facebook needs to hire another 500 engineers.

Re:Duh

[TheMidget]

It *is* possible to encrypt the password for real before the password gets passed to the server, by means of using some javascript with a one-way encryption (think pgp) and a public key, but that would require disclosing the public key as well as the encryption algorithm being used, which isn't very good mojo.

That could still be subverted by a MITM. Actually Tunisia pulled off their hack by inserting extra javascript into Facebook's pages. If they can insert javascript, they can also remove javascript. So the encrypting javascript would be removed from the page, and the encryption run on their man-in-the-middle server instead. Neither browser, nor the server would be none the wiser.

With https, you have at least some subtle cues such as the lock icon, and the https in the URL, which allows the more observant users to spot that some monkey business is going on...

Re:Duh

[batkiwi]

It can if you load a rogue root CA, and sign your OWN certificate for a MITM to facebook.com

Re:Duh

[TheMidget]

Actually, the login data is transmitted via https (although the form itself is in an http page). Go to your page, and do a view source.

Around here, it has "<form method="POST" action="https://login.facebook.com/login.php?login_attempt..." in it. Do a view source yourself, search for login.facebook.com, and see for yourself!

If you do indeed see a non-https action URL, chances are that you are in a non-democratic country running a malicious proxy which changed it into http to spy on you... and that is the real danger of facebook's setup (and yahoo's, and many others' ...).

Facebook went to the expense of using https for each login, but unfortunately then they bungled it in such a way that the user has to do a view source to make sure it hasn't been tampered with...

Re:Duh

[chedderslam]

It worked for "hunter".

Re:Duh

[T.E.D.]

Shame that.

What they really did was redirect all logins from Tunisia to an https connection, and force them to verifiy some of their "friends"' photos.

Re:Duh

[whoever57]

That's why FB's response was to respond to all requests from Tunisia using https.

That would still leave those users out in the cold that don't know that they're now supposed to enter https://www.facebook.com/ [facebook.com] . Unfortunately, that would be 99% of the users...

I assume that Facbook sends back a a re-direct in response to a connection attempt to their http site from Tunisia. However, if the code that intercepts and re-writes the webpage is updated, it could intercept the re-direct and proxy the connection, with an https connection to facebook and an http connection to the poor Tunisian's client PC. So, facebook's response won't be very effective.

Re:Duh

[rwven]

Yes, the login is submitted via HTTPS, but that's not the issue here.

They injected a javascript KEYLOGGER into the homepage. As you typed your username and password, it would detect the keystrokes and transmit them.

Submitting the login form is irrelevant at that point.

Re:Duh

[Mysteray]

Right, because Facebook would never let anyone know who your friends were.

Re:Duh

[rwven]

Also:
http://www.businessinsider.com/tunisia-facebook-2011-1

Quote:
"They did this through keyloggers, a piece of software that records the keys you hit on your computer.

When Facebook realized this was going on, they quickly switched the entire Tunisian site to https..."

Re:Duh

[Mysteray]

Actually, the login data is transmitted via https

But you don't actually know that when the page is downloaded via plain http. It can be trivially modified in transit, as the attackers did here.

Re:Duh

[jimrthy]

That's why you need both. Always assume the system's been hacked and do what you can to minimize the damage.

Re:Duh

[petermgreen]

The "multiple trusted CAs" model is only as secure as the least trustworthy CA. Browsers use this model and have a disturbingly long list of trusted CAs.

The reasonable assumption is that most significant governments have a "trusted" CA they can lean on to sign certificates for whatever domain they want. So if you want to secure stuff against them do not use browser based SSL.

There is also the issue someone else mentioned that most people go to the non-SSL site first, unless the person is paying a lot of attention they can be diverted to a different domain and/or kept on non-ssl with the original domain.

Re:Duh

[petermgreen]

Or just find a CA that is either sympathetic to your cause or subject to your coercion.

read and weep. A list this long and spread through so many different countries is not the way to run a tight ship security wise.

Re:Duh

[jdogalt]

I don't think you are really disagreeing with what I said, though highlighting that there is a subtle issue with 'encryption wrapped inside an http login page'. I.e, whether the real issue is exactly as you described (https utilzed after redirection from http), or an alternate scenario that seems plausible- some custom encryption implemented with javascript within an http page, the problem is the same, and the solution is still just as I described- disallow any login via an http page. If you had carried your description of things through to a proposed solution, I don't see any other alternative than only having https login pages.

Note, when you go to facebook.com (i.e. www.facebook.com, i.e. http://www.facebook.com/ you are presented with a login page with user and password text entry. There is no redirection to an https login page involved.)

Re:Duh

[shutdown -p now]

Imagine if that central ISP would have automatically redirected all HTTP traffic to its own gateway, which simply did HTTPS requests on user's behalf, injected the script, and then served the response to user as plain HTTP. Sure, a techie might notice that they're on a non-secure connection, and wonder why. Most casual users would just see everything working as usual.

Re:Duh

[volcan0]

Your argument was actually quite valide. The only thing I would add to it, is signing the page. Let me explain:

1. Do all the above steps
2. Hash ( and store ) the output buffer ( PHP ) before flushing it to the browser
3. When preparing the POST to send the auth to the server, have the JS include the hash of the current page

If they do not match: you know code was injected in the page.

Re:Duh

[Anonymous Coward]

Anyone who logged in during the period of time where passwords were being captured was presented with photos and asked to pick the ones featuring their friends. Then they were asked to choose a new password.

they should do this in america. with people who have 5,000 facebook friends. purge the masses!

Re:Duh

[Billlagr]

Maybe the ones MySpace put off?

Re:Duh

[definate]

Fuck. Well I logged in during that time, and got that prompt, but it didn't say why, and so I set it to the current password.

Either way, I've since setup LastPass and am now running an insane uber strong password which is different on every site I visit.

Problem solved!

Really annoyed at that though. However, this solution will make sure if I get pwned somewhere, I don't get pwned everywhere!

Re:Duh

[definate]

Wait a minute. That must have been something else, since I don't live in Tunesia, and it would make no sense for my traffic to go through there.

Though I did still have that prompt a while back.

Perhaps they were running it generally.

Re:Duh

[Anonymous Coward]

Down the road this is one of the things DNSSEC fixes if we move the SSL certificates into DNSSEC rather than using the existing "trusted" CAs

In DNSSEC when you visit foo.bar.baz the CAs involved are the root CA, which is just a bunch of bearded Unix guys who take this very seriously and hardly ever issue new certs, then the baz CA (which might be a country, or an international organisation) then the bar CA, which might be a company. Running slashdot.org or even .fr doesn't give you any authority over facebook.com

In this world "www.facebook.com" would only be subject to interference by Verisign (CA for com) and Facebook itself. Not by some random Tunisian government agency, nor by some script kiddies who found a hole in a bargain basement DNS business in Taiwan.

Re:Duh

[Anonymous Coward]

In this world "www.facebook.com" would only be subject to interference by ICANN, and (with enough pressure) through them some random US government agency, Verisign (CA for com), and (with likely far less pressure) through them some random US government agency, and Facebook itself. Not by some random Tunisian government agency, nor by some script kiddies who found a hole in a bargain basement DNS business in Taiwan.

"Trust the US government" might be better than "trust half the governments of the world"... but let's not pretend it's that much better.

Re:Duh

[_0xd0ad]

Have the javascript hash document.body.innerHTML and return that too.

Different browsers might handle it slightly differently, but there's a finite number of hashes you should expect. Any modification of the HTML done by a MITM will show up as an invalid hash.

Re:Duh

[TheMidget]

I don't see any other alternative than only having https login pages.

Exactly. And the user should be required to enter that https himself, or else he will forget to check that it's there.

Note, when you go to facebook.com (i.e. www.facebook.com, i.e. http://www.facebook.com/ you are presented with a login page with user and password text entry. There is no redirection to an https login page involved.)

Sorry, my mistake, my language was a little bit sloppy. Facebook doesn't actually use a redirection to https, but instead just uses a https URL as the form action. Same reasoning still applies: as the form itself is served via http, it is trivial for an interloper to change that https in the form action into an interceptable http.

Other providers, such as yahoo, do use a redirection to https. This has the advantage that the observant user can see at a glance that the connection is not being tampered with (whereas with Facebook, the user would need to view source to make the same assessment)

Re:Duh

[JoshRosenbaum]

I don't think this would work, because the javascript could be modified as well. This means the modified man in the middle javascript could just return the expected hash.

Re:Duh

[JoshRosenbaum]

I replied to a similar post above with: I don't think this would work, because the javascript could be modified as well. This means the modified man in the middle javascript could just return the expected hash.

Re:Duh

[Fulcrum of Evil]

It's like sci.crypt in the old days!

Require HTTPS for all connections...

[Cryect]

Really is annoying that Facebook defaults to http

Re:Require HTTPS for all connections...

[Pojut]

I'd say baffling is more appropriate...as huge as the website is, and with as much personal information being slung around, you'd think they would make it ONLY https at this point...

Re:Require HTTPS for all connections...

[choongiri]

Precisely. This attack should have been impossible.

Re:Require HTTPS for all connections...

[Anonymous Coward]

Agreed. As annoying is the fact that the whole site doesn't work over https -- e.g. chat seems to have serious problems.

I'm sure everyone knows HTTPS Everywhere already, it certainly helps me. Unfortunately a non-default solution is useless for the people who most need help, the ones who have no idea what https means...

Re:Require HTTPS for all connections...

[Anonymous Coward]

Yeah, it is. At least login is encrypted, though. I would copy/paste in the form code from their page if Slashdot's comment entry form didn't dislike chrome on mac.

Re:Require HTTPS for all connections...

[91degrees]

But even if it doesn't, you could simply use a non-encrypted proxy site and assume that most users won't care that ther's apparently no secure connection.

Re:Require HTTPS for all connections...

[I8TheWorm]

Sadly, https://www.facebook.com/ does work, but you have to force it... and continue to force it because each request sent over https generates a response as http.

Re:Require HTTPS for all connections...

[rjstanford]

Except that all the interceptor need do is force an HTTP connection to themselves, then make the HTTPS connection outbound. How many people would actually check for an HTTPS connection before logging in to Facebook?

Re:Require HTTPS for all connections...

[tkprit]

I use https and FB just doesn't work well with it: not only do you lose chat, you lose push notifications and profile editing.

Re:Require HTTPS for all connections...

[Anonymous Coward]

you lose chat, you lose push notifications and profile editing.

Awesome! HTTPS actually makes the application less annoying?!?!

Re:Require HTTPS for all connections...

[Anonymous Coward]

HTTPS is too much of a performance hit in order to scale.

It's just not viable for gigantic sites (much like google still doesn't push to https either).

From a serverside standpoint generating, the extra calls, every part of what makes the security feasible, is not performant.

Re:Require HTTPS for all connections...

[sustik]

So some websites (still?) send login and password info as cleartext?

Why do we enable incompetent people to get rich?

Re:Require HTTPS for all connections...

[smart.id]

Could a greasemonkey script be written to update all links to HTTPS?

Re:Require HTTPS for all connections...

[Darinbob]

It's facebook though. Who would be dumb enough to put vital information there? You shouldn't need high security when the stuff you're protecting is trivial.

That's the theory anyway. Turns out users are dumb; the put important info on public sites that they don't want anyone to see, they use the same password for multiple sites, they have auto login, etc. So it does make sense to have https, in hindsight. So all the fluff sites should beef things up.

Re:Require HTTPS for all connections...

[I8TheWorm]

Erm, embarassing moment... someone already has.

Re:Require HTTPS for all connections...

[BitZtream]

I'd say baffling is more appropriate...as huge as the website is

Its size makes it pretty clear why they don't do it.

For something like facebook, enabling SSL would be probably their single largest use of processing power in one chunk.

Limiting it to login only would obviously make it a much smaller load, but SSL would still likely be their largest use of CPU power (assuming you count crypto accelerators rather than ignore them)

SSL is expensive in terms of CPU power especially without dedicated crypto hardware.

Re:Require HTTPS for all connections...

[Darinbob]

Heck, Windows does this too somewhere. Ie, at work a third party training site send me email about my account and password. And the password they included in the email was my corporate password (one behind the current one at the time, but very recognizable). I have never given this password to anything but Mac OS and Windows remote desktop. Yet somehow it shows up in clear text at a third party...

My only guess is that someone in IT sniffed some passwords, or else active directory (or whatever windows uses now) is able to retrieve the passwords (rather than the unix method of having them stored in an unrecoverable way). So if you can't even trust the OS...

Re:Require HTTPS for all connections...

[sl0wp0is0n]

It's not that easy. HTTPS means that a non-trivial increase in hardware resources used on the server-side.

Re:Require HTTPS for all connections...

[grcumb]

Could a greasemonkey script be written to update all links to HTTPS?

Ask and you shall receive: HTTPS Everywhere is a Firefox plugin that forces HTTPS not only on Facebook, but Google and numerous other sites, with the ability to configure still more.

Re:Require HTTPS for all connections...

[Anonymous Coward]

HTTPS is too much of a performance hit in order to scale.

At least this *was* a good excuse.
http://en.wikipedia.org/wiki/AES_instruction_set

Re:Require HTTPS for all connections...

[TheMidget]

Really is annoying that Facebook defaults to http

Actually most of these sites' entry page are https... including banks.

Yes, facebook (and many other services) fortunately do transmit the actual login data over https, but in order to make sure that no man-in-the-middle has tampered with the form action URL, the user needs to do view source! How many people are going to do that?

Re:Require HTTPS for all connections...

[TheMidget]

So some websites (still?) send login and password info as cleartext?

Only niche web sites such as gayromeo.com . They do have an https option, but that's only for paying customers.

Most mainstream sites (such as facebook, yahoo, etc.) do transmit their passwords over https, but their entry page is http, which makes it trivially easy for an attacker to just change the form, and use http instead.

Why do we enable incompetent people to get rich?

Well, in gayromeo's case, not using https is not really "incompetence", but one way to get rich... One more argument for taking a paying subscription rather than using the free service.

Re:Require HTTPS for all connections...

[TheMidget]

How many people would actually check for an HTTPS connection before logging in to Facebook?

... especially since it takes a "view source" to do this check...

Re:Require HTTPS for all connections...

[Mysteray]

Sadly, https://www.facebook.com/ [facebook.com] does work, but you have to force it... and continue to force it because each request sent over https generates a response as http.

Which is basically another way of saying "it doesn't work", no?

Re:Require HTTPS for all connections...

[vanyel]

Inexcusable, I would say...

Re:Require HTTPS for all connections...

[TubeSteak]

I'd say baffling is more appropriate...as huge as the website is, and with as much personal information being slung around, you'd think they would make it ONLY https at this point...

Most anonymous proxies do not support https

Re:Require HTTPS for all connections...

[Anonymous Coward]

RTFA. HTTPS doesn't matter when your government terminates and downgrades to HTTP, like Tunisia did. That's why FB had to respond by forcing social auth.

Re:Require HTTPS for all connections...

[dragin33]

This would have 0 effect on a country wide attack.. If you control the gateway to the internet you can main in the middle the SSL handshake and nullify the security. Then you could carry on with your password stealing.

Re:Require HTTPS for all connections...

[dragin33]

man*

Re:Require HTTPS for all connections...

[Civil_Disobedient]

The problem with that is most browsers don't respect cache headers. The spec is a little vague on what's supposed to happen with HTTPS... some say "cache nothing!" but that's convention and not due to any restriction from the spec. If the stuff you're sending out is static (images, css files, external javascript, etc.--i.e., the stuff that takes the longest amount of time to download) the site should be able to set the expiration cache to a year and expect the browsers to respect that.

That simple action alone would speed up https traffic to a level where people would fine it completely tolerable, and in most cases virtually no different than regular http. The problem is, most browsers see HTTPS and they ignore all the explicit headers and you're back to requesting that same stupid 150K background JPG image over. and over. and over. and over... it's fucking infuriating.

Seriously, browser makers: fix this shit and we can ditch unencrypted HTTP. The most insulting thing is that Internet Explorer is the only browser that gets this right.

Re:Require HTTPS for all connections...

[I8TheWorm]

Not exactly. I gathered from the PP that there was no https available. It is available, but not configured to give http_responses in SSL for some odd reason.

Re:Require HTTPS for all connections...

[Mysteray]

That sounds kind of unusable to me. I'm not on FB so I don't know. Perhaps someone can answer:

Is the FB interface usable in a practical sense over https, or not?

Re:Require HTTPS for all connections...

[tkprit]

This is probably redundant by now on this huge page, but https connections to FB are good for ONE PAGE; you have to manually type in every URL on FB.

Of course the biggest FB annoyance you lose when using https is ADS! LOL! Yes, if you don't want freakin ads on FB, you don't have to use ABP or another blocker, just use HTTPS.

Of course, THAT'S probably why FB won't 'fix' its security.

Kudos to facebook

[operagost]

When Facebook does something right, they should be commended. They easily could have shrugged their shoulders and said, "Not our problem!"

Re:Kudos to facebook

[Anonymous Coward]

Like they shrug when the CIA snoops all their traffic.

Re:Kudos to facebook

[$RANDOMLUSER]

When Facebook does something right, they should be commended.

Please wake me when that happens.

Re:Kudos to facebook

[Yvan256]

The Chinese Intelligence Agency?

Re:Kudos to facebook

[gparent]

When they prevent HTTP login and switch to HTTPs, they'll have done something right. This is just PR. Their shitty security allowed this in the first place.

Re:Kudos to facebook

[Anonymous Coward]

But the CIA is so good at keeping their raids secret it's not even known they go around oppressing people with that information, right? It's not like other countries, where the entire world knows they imprisoned their population... nah, the CIA is far too skilled for that. Fuck, I bet they clone the people they catch to impersonate them! Go America... where even our oppressors are the best.

Re:Kudos to facebook

[Anonymous Coward]

Unfortunately, moving from a shitty implementation to a standard implementation is not cause for praise either.

Re:Kudos to facebook

[LateArthurDent]

The Chinese Intelligence Agency?

You fucked that up. "Chinese Intelligence in America" was the Simpsons joke.

Re:Kudos to facebook

[Yvan256]

D'oh!

Re:Kudos to facebook

[Anonymous Coward]

Yeah, it caused such a scandal at Langley when they saw you post a drunken picture of yourself posing out in front of your NWA "Fuck Tha Police" poster.

That alone would probably be enough to put you on the "Reservations at Gitmo" list. Not to mention the fact that you're clearly trying to hit on every female age 16 and up in your "network". That'll get the child porn agents involved.

Your facebook account is not a special flower that the CIA gives a shit about.

Re:Kudos to facebook

[CrazyDuke]

Warning! Explicative filled rant:

You know, I really don't give a fuck whether or not the CIA, NSA, or whatever happens to have access to my pizza orders, crybaby rants of the moment, and pr0n downloading habits. I don't give a fuck if I spot someone following people around in the general vicinity of a military base or major terminal. Heck, I might smile and wave unless it would alert someone else to their presence. I don't give a fuck about any computers processing and filtering down telecommunications traffic. And, I actually have some respect for any analysts that would actually have to rummage through all the false positives spat out by the machine and the guys that possibly end up tailing dumb-ass tourists that won't pay attention to the "No Cameras!" sign.

What I do care about is that one dick-head out of 100 that loves to fuck with random people because it's fun (...or the one in 25 or so that wants to force some "respect for power" down peoples' thoughts. ...or, for that matter, the one in 100 that will pull random shit just to make him/herself look good. ...or the one in 25 that will blow shit out proportion just to get attention.) And such dick-heads typically end up in positions of organizational and/or political power where they carefully remove any possible controls or oversight that might interfere with their entertainment. Those are the assholes I have a problem with. Everything else is a casualty of that. It only takes one of these dick-heads with a magnifying glass to pick you out as an ant to fry for a mere moment of entertainment to make your life Hell on Earth. Whether or not the ant has an abrasive political ideology, likes pr0n, or whatever is largely irrelevant.

It will only be an issue if they start or are colluding with these wonderful politicians (political suppression, scapegoating, etc...), private interests(industrial espionage), or law enforcement (fishing expeditions, prejudicial biases, etc...). Again, mostly because of the assholes. People love to leave these fuckers in power and then wonder why everything goes to hell. So, it would be wise to not depend on the general populace to actually do something about these guys.\0

Re:Kudos to facebook

[jpmorgan]

As someone else pointed out, HTTPS doesn't necessarily help. A MITM proxy can easily connect to facebook via https but rewrite URLs sent to the client to http.

Re:Kudos to facebook

[c0lo]

When Facebook does something right, they should be commended. They easily could have shrugged their shoulders and said, "Not our problem!"

But,,, it was their problem... and a serious threat to the business.

Assume the Tunisian clique would be still in power: with such a trove of private data in their possession, it was unfair competition for FB! As the owner, FB has and need to maintain the monopoly on how this data is to be exploited. Anything else is just communism.

(wink)

so who's to blame for this one?

[lagi]

makes you wonder why a country is able to steal it's Facebook user's passwords.

Re:so who's to blame for this one?

[Anonymous Coward]

"makes you wonder why a country is able to steal it's Facebook user's passwords."

It's because all those extra apostrophes.

Re:so who's to blame for this one?

[rwven]

It was very easy... Rtfa

Wake up call

[h00manist]

If they are doing it, I would be surprised if lots of others aren't too.

TL;DR?

[Anonymous Coward]

Could someone post the executive summary for this?

The author doesn't get to the fucking point, and I'm not going to read all that garbage to learn how Facebook's authentication sucks wrt security (assuming that's even mentioned in the article).

Re:TL;DR?

[Svenne]

Facebook switched to HTTPS for Tunisian users. Yep, that's about it.

Re:TL;DR?

[the eric conspiracy]

The WTF was that they weren't using https in the first place.

Re:TL;DR?

[Nadaka]

The wtf is that they only switched to http login for tunisian users. Everyone else still gets good old fashioned unencrypted http.

Security an authoritarian government could love

[serano]

The second technical solution they implemented was a "roadblock" for anyone who had logged out and then back in during the time when the malicious code was running. Like Facebook's version of a "mother's maiden name" question to get access to your old password, it asks you to identify your friends in photos to complete an account login.

Hmm, you're trying to log in... Please help us identify your friends first.

This is going to be a great new fake verification for a future authoritarian government.

HTTPS

[gambino21]

Article Summary: They switched facebook to use https in Tunisia.

I wish facebook would consider just switching all traffic to https.

Re:HTTPS

[mlts]

+1. I know FB would rake in the bucks if they offered a premium service that had https by default, no ads, and the ability to use a VASCO or SecurID keyfob (with OATH certification when logging from PCs, and for non-PCs, the FB app has the ability to set a PIN.)

I'd pay the usual $20 a year for this easily, mainly because FB is a good tool for keeping track of band and other events going on locally.

Re:HTTPS

[MichaelSmith]

The ISP could still proxy the connection though. Proxy to FB and Proxy to client would still be encrypted but the proxy would get the username and password. The client may have to click through a warning about a mismatched certificate but I reckon most would.

Re:HTTPS

[ThatMegathronDude]

Most browsers give you a very big and mean looking error message when certs mismatch. The kind that make people unversed in security call their computer geek friends before doing anything; I suspect that this won't be too huge a problem.

Re:HTTPS

[MBCook]

They don't have to play Man-In-The-Middle. They can just make sure that HTTPS doesn't work (return error codes, drop packets, etc) such that it becomes unusable and people's only choice (if they want to keep accessing FB) is to use standard HTTP.

Re:HTTPS

[NoSig]

At which point it will be apparent that something is up.

Re:HTTPS

[MichaelSmith]

True but say the user in Tunisia is using IE from Windows. Maybe the government looks the other way when people steal the version of windows with the "right" binaries. Or he's running firefox but Tunisia has a special localised version which you automatically get when you download it from one of their ISPs.

Re:HTTPS

[jschmitz]

They are already raking in the bucks - you aren't the customer you are the product

Re:HTTPS

[Anonymous Coward]

That's as far as Facebook's responsibility goes. If the users decide to ignore the big warning screen (thinking FF, I have no idea how other modern browsers do it), that is their problem. Facebook doesn't have to babysit it's userbase, as long as they take reasonable precautions (ie HTTPS as default protocol).

Re:HTTPS

[LWATCDR]

Wow $20 a year? You and five other people. They rake in more than that in ad revenue from each "prime" user. Also most people just don't care enough to pay for this service.

What I find amazing is not that Facebook isn't secure but people expect it to be. This is a place where you "publish" information on the internet. It is not now and never should have been considered a secure communication channel.
Why doesn't facebook default to https:? My guess is cost. It takes resources to encrypt data and for face book moving everything to https probably would cost a few million dollars in resources.
And nothing stops you from using https://facebook.com/ does it?

Re:HTTPS

[Anonymous Coward]

Hardware costs would soar if they switched entirely to HTTPS. There is an entire industry making crypto co-processors to handle the load that millions of concurrent HTTPS connections place on an infrastructure.

On your client end, one connection is no problem. Scale that for 100 million logged-in users.

Re:HTTPS

[BitterOak]

The ISP could still proxy the connection though. Proxy to FB and Proxy to client would still be encrypted but the proxy would get the username and password. The client may have to click through a warning about a mismatched certificate but I reckon most would.

Probably not even necessary. How hard would it be for the Tunisian government to get a CA in Tunisia to sign a fake Facebook cert? Then there'd be no warnings at all. I mean SSL only works if you trust every CA whose root cert is in your browser, and really, why the hell should anyone do that?

Re:HTTPS

[MichaelSmith]

The ISP could still proxy the connection though. Proxy to FB and Proxy to client would still be encrypted but the proxy would get the username and password. The client may have to click through a warning about a mismatched certificate but I reckon most would.

Probably not even necessary. How hard would it be for the Tunisian government to get a CA in Tunisia to sign a fake Facebook cert? Then there'd be no warnings at all. I mean SSL only works if you trust every CA whose root cert is in your browser, and really, why the hell should anyone do that?

Yes.

Re:HTTPS

[kiwix]

Most browsers give you a very big and mean looking error message when certs mismatch. The kind that make people unversed in security call their computer geek friends before doing anything; I suspect that this won't be too huge a problem.

Since Firefox gives me the same alarming message every time I go to a website with a self-signed certificate, I just click through the warning without reading it (self-signed certificates are quite common, and pretty inoffensive). I guess many people do the same.

Sadly enough, SSL certificates aren't so much about security as they are about money...

Re:HTTPS

[vlm]

What I find amazing is not that Facebook isn't secure but people expect it to be. This is a place where you "publish" information on the internet. It is not now and never should have been considered a secure communication channel.

I deleted my facebook acct about a year ago, so excuse my terminology.

Imagine the scenario of a profile picture being changed to goatse.

You are correct that it is "published" to the internet and is not secret-secure.

Where you are wrong, is thinking that it is authorized-secure.

Much like this post was written by VLM. Or, was it? As if you'd know...

Re:HTTPS

[oogoliegoogolie]

I wish facebook would consider just switching all traffic to https.
Because typing in the "s" would confuse the majority of the userbase.

Re:HTTPS

[LWATCDR]

It would be at most annoying but not harmful. The people that know me would think that someone else did it. AKA that I was hacked. The risk to benifit ratio of me being on facebook is worth it time. I get to see when friends are expecting babies, get married, and or get new jobs. I guess if someone really wanted to make the effort they could hack my account but as I said it would be mildly annoying and not much else.

Big deal. But you deleted your profile so I guess you realize that facebook isn't secure or has no real value for you.
Sorry but is it unreasonable to think that everybody should put as much though in how they use sites like facebook as you and I do?
Folks use TOR and create a fake account. Frankly if you are using Facebook to make political statements in some totalitarian country I hope you are making some effort to hide. I mean having "your name here" likes let's overthrow the government on facebook can not be all that healthy to start with. Add in pictures of yourself, info on where you work....
I mean really folks treat Facebook like a business card.

Re:HTTPS

[heypete]

Hardware costs would soar if they switched entirely to HTTPS. There is an entire industry making crypto co-processors to handle the load that millions of concurrent HTTPS connections place on an infrastructure.

SSL accelerators are useful for offloading the CPU-heavy part of the SSL transaction: the RSA key-exchange part. The rest of the secured connection is quite light, particularly when using a fast cipher like RC4. The RSA part can be sped up by using shorter keys (e.g. a 1024-bit key, rather than 2048 or 4096-bits), while still providing modest security (anything is better than nothing).

That this guy, a Google employee, said the following about SSL:

In January this year (2010), 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 10KB of memory per connection and less than 2% of network overhead. Many people believe that SSL takes a lot of CPU time and we hope the above numbers (public for the first time) will help to dispel that.

If you stop reading now you only need to remember one thing: SSL/TLS is not computationally expensive any more.

Re:HTTPS

[MattskEE]

And nothing stops you from using https://facebook.com/ [facebook.com] does it?

If you go to https://facebook.com/ you do view an encrypted home page. But all of the links to everything are just non-encrypted http. Unless you copy each link, paste it into the address bar, and prepend 'https://' to it (or write a browser script to do the same) then most of your facebook session will not be secured.

Re:HTTPS

[heypete]

Forgive my second reply, but I failed to mention something in my previous post that is relevant: since Facebook already handles password logins over HTTPS, the heavy lifting (i.e. the RSA key exchange) is already taking place for every user. They can clearly handle that load. It's just that they're wasting those cycles by switching back to an insecure connection afterward.

Leaving the connection secure with a lightweight cipher like RC4 uses minimal additional resources, is extremely fast, and would be trivial to turn on.

Re:HTTPS

[oracleguy01]

I wish I had mod points for you. That is good information.

Re:HTTPS

[mcrbids]

You didn't bother to hit the scroll key on your keyboard or flick the roller on your mouse to notice that Slashdot is similarly unencrypted before posting this?

Re:HTTPS

[dargaud]

And nothing stops you from using https://facebook.com/ [facebook.com] does it?

The EFF plugin for firefox Https-Everywhere uses https on many website whenever available. A must-have.

Re:HTTPS

[azalin]

It has been awhile, but wasn't there an option once to log into Slashdot by adding login and password to the url and setting that as a bookmark?
The words "Terribly insecure, but also very convenient" come to mind.

Re:HTTPS

[LWATCDR]

It is handy but for a lot of sites I just don't see the need. Of course that is just me and how I use the sites like Facebook. What it all comes down to is that I feel that it is foolish to expect any serious security from Facebook, Twitter, or frankly slashdot. They are public sites where you pick what you put up and you decided to join.
Hey if you don't want people to know that you hate the government or have a furry fetish don't publish it on Facebook under you name and do not expect Facebook to make any more effort to protect your privacy than you expend.

Facefuck off

[Anonymous Coward]

Er, Facebook is willing to give up pretty much all your personal details to any third party that asks so I don't see why this is that much different. I'm surprised they didn't release some lame statement along the lines of 'Oh this is so you can log in much easier, just let your local government official do it for you and he can do all your shopping and check your Farmville while you are in prison.FUCK ZUCKERBERG!

Re:Facefuck off

[h00manist]

FUCK ZUCKERBERG!

You have logged in from Tunisia. Thank you for using Facebook.

Pay Up

[Anonymous Coward]

So Facebook's sales guy called the President of Tunisia and said "Dude, you have to pay for all that user data just like everyone else does. What makes you think you're special?"

Re:Pay Up

[Anonymous Coward]

Not trolling, and perhaps it's just a momentary deficiency in my Google-foo, but have there ever been any incidents of Facebook selling users information or is this just something we repeat without reason?

I've never seen a way to collect any user info from an ad campaign on their site, so it doesn't seem like advertisers get to leech personal info. That knocks out all the pending doom articles I've found from 2009. I do see reports of third party developers getting caught selling user info... but that's about as close as I can find (and obviously not the same).

Does Facebook proper actually sell any personal info?

Re:Pay Up

[T.E.D.]

They weren't just harvesting data, they were actively logging into hacked accounts and deleting data.

If you are married to your cynical view, then it should be ammended to Facebook deciding that it hurt the value of their site (to those same paying harvesters) to have all that data deleted.

Light on details

[sat1308]

The article is a little light on details, but am I right in thinking that people's session cookies were being sidejacked? AFAIK, despite FB not sending everything over https, the password is sent over https. So I don't see how a keylogger like approach would work to intercept the pw, unless the Tunisian government was smart enough to run something like Moxie Marlinspike's sslstrip where they did a MITM attack and sent unencrypted http traffic to the user and then stole their password. I doubt this was the case because a) they don't seem smart enough and b) no security measure would circumvent this unless people knew not to log in over http.

So now we just wait until the government uses sslstrip...

P.S. - It's unbelievable that in this day and age FB doesn't encrypt the whole session given how trivial session-jacking is.

Re:Light on details

[mlts]

There are a lot of places other than FB which don't encrypt their traffic other than the initial username/password. Mainly because it is cheap to do so (plain http connections after authentication can be cached, no need to set up and tear down encrypted sockets, etc.)

However what was par for security even last year before widespread sidejacking tools like FireSheep became available is now considered a wide open security risk. Just like how companies have to firewall their networks with the expense involved in having network security, separating departments, and such, companies will have to move to SSL for the entire transaction with their visitors or customers.

Re:Light on details

[Jimpqfly]

I'm sorry but even if you criticize a huge censorship, I find the fact that you saying "they don't seem smart enough" quite offended for Tunisians...
Don't forget they're not red necks, and that they are highly educated.

Re:Light on details

[Nemesisghost]

In TFA, it states that the only ones susceptible to this attack were those who logged in/out during the attack. If you kept yourself logged in then the attack failed. They were effectively running a keylogger type script.

Re:Light on details

[EvanED]

From what I picked up in an earlier story, what was going on was Tunsia was injecting Javascript into the initial page. Presuming that's correct, sending the password alone wouldn't be enough; the initial page would need to be HTTPS too.

Re:Light on details

[initialE]

As explained above in http://it.slashdot.org/comments.pl?sid=1964554&cid=34988134, it's not over yet. Tunisia can hijack your traffic by decrypting, re-encrypting it with their own certificate and presenting it to you as an SSL encrypted page from a trusted certificate provider. You are free to delete that trusted provider from your certificate store, but if you are using IE they can put it back - Microsoft allowed them to do it without your permission. Chances are you wouldn't even know that it happened.

Re:Light on details

[geggo98]

The article is a little light on details, but am I right in thinking that people's session cookies were being sidejacked? AFAIK, despite FB not sending everything over https, the password is sent over https. So I don't see how a keylogger like approach would work to intercept the pw, unless the Tunisian government was smart enough to run something like Moxie Marlinspike's sslstrip where they did a MITM attack and sent unencrypted http traffic to the user and then stole their password.

The Tunesian government has its own certificate authority whose root certificate is accepted at least by Internet Explorer and Google Chrome. So they could run their MIM attack over HTTPS with a real certificate accepted by the client. This root certificate was pushed by a Windows Update (KB931125).

they don't seem smart enough

They seem to be smarter than you thought: They lobbied Microsoft to enable a hard to detect MIM attack. Against this kind of attack SSL is nearly defenseless. Even when facebook would switch completely to SSL and all users would check for this, the Tunesian government could succesfully run a MIM attack.

Re:Light on details

[Anonymous Coward]

Unfortunately, even Yahoo and Windows Live Mail don't use SSL past the login. Gmail, and a few sites such as Hushmail, do. Hint: actually quite useful for a secure communication from mobile phones...

Fabebook security team discovers https

[Anonymous Coward]

Now, that's a story..

Every tunisian naked pics is leaked

[h00manist]

The real revolution-causing leak will be the naked pics leaks.

Executive summary

[93 Escort Wagon]

Facebook doesn't want anyone accessing their customers' personal information unless Facebook is being compensated.

Re:Executive summary

[pitchpipe]

Parent is modded funny. It is not funny. It is insightful.

Seinfeld

[Anonymous Coward]

Every time I see the words "very, very bad" I get a flashback of this:

Babu: You bad man! You very, very bad man!

With his finger saying "uh-uh", going left and right.

A lot of reading

[denshao2]

Just to find out that they rerouted to https and used the ability to recognize friend's faces to determine if someone was a legitimate account holder.

Wader

[Anonymous Coward]

facebook doesnt have encryption past the server because they dont use HTTPS with an SSL certificate... they use HTTP which simply exposes all information that passes to their server. Its only encrypted after it reaches their server

Everyone knows its insecure lol. Its the most easy site to hack because it uses client side coding...

Good thing Tunesian doesn't have a Root CA!

[foom]

At least, I guess they must not...unlike most every other government in the world... If they did, they could still pretend to be Facebook, even when facebook uses https!

Re:Good thing Tunesian doesn't have a Root CA!

[Anonymous Coward]

Well, they actually have a national certification authority ( http://www.certification.tn/index.php?id=4 )

And according to the site it is recognized as a root CA in internet explorer ( http://www.certification.tn/index.php?id=323 )

Re:Good thing Tunesian doesn't have a Root CA!

[Archwyrm]

I always knew IE was bad, but I didn't know it could get you killed..

Seriously though, the CA system is awful and needs replacing.

Re:Good thing Tunesian doesn't have a Root CA!

[bendodge]

I use Perspectives out of paranoia about this sort of thing. It's easy - just install and hope it never alerts you.
This is a tool activists should be aware of and employ religiously.

The real lesson

[Anonymous Coward]

Quote from TFA:

Though Sullivan is the unflappable type, the Tunisian situation seemed to force him into a bit of reflection. "When you step back and think about how Internet traffic is routed around the world, an astonishing amount is susceptible to government access," he noted.

Indeed. It happened in Tunisia today, but just remember that there is absolutely no technical reason why it couldn't happen here. Your ISP could do it, your government could do it, and every single last router along the way could do it.

In fact, we pretty much know it IS being done (remember those secret NSA rooms they found at AT&T and all that?); it's just done in a more professional fashion, and the government's not going to tip their hand easily (so if you have something to hide, you're probably safe: they'll know, but they won't act in a way that would give away that they know).

Why again isn't https standard? And why again doesn't Slashdot support https?

Why not protect all users?

[Gothmolly]

Why do you need a country-level solution? Why not a global solution, which implements ALL your country solutions at once?

Re:Why not protect all users?

[tnk1]

Why do you need a country-level solution? Why not a global solution, which implements ALL your country solutions at once?

Because:

a) Tunisia is in the news for the first time since the Punic Wars, so its topical. That gives positive PR value.
b) Tunisia is a small country that doesn't have the number of users as, let's say, the US, and so forcing https down their throat is not going to be a big deal
c) If this fails, people will forget about it as soon as people forget about Tunisia again. (About 2-4 weeks from now)

and....

d) "Holy shit, look at what's going on in Tunisia! Hey, wouldn't it be funny if we had Tunisians as customers? Wait! We do! Let's check out the traffic from there. Wait a minute... check this out....! Hey, Joe, can you upload those certs to the Netscaler today? Thanks! Go North Africa Ops! Now we have something to put in the department newsletter instead of our usual lame Spicy Falafel recipes. Eat THAT US Operations losers!"

Join the Facebook group

[Anonymous Coward]

Want to have HTTPS on Facebook as default? Show your support in favor of HTTPS. Join the Facebook page. :p

HTTPS Everywhere

[metrometro]

Once again, our friends at the EFF are ahead of the curve. Their HTTPS Everywhere extension, released a few months ago, probably would have beaten this attack by Tunisian security services, or at least made their jobs much harder.

Here's the extension: https://www.eff.org/https-everywhere

Work that donate button a little while you're there.

Re:HTTPS Everywhere

[loimprevisto]

I like HTTPS Everywhere, but I turned it off for Facebook. Several parts of the site's functionality just don't work on the HTTPS side. Chat was the worst example, but not the only one...

They turned on https for logins

[Culture20]

The country's Internet service providers were running a malicious piece of code that was recording users' login information when they went to sites like Facebook. By January 5, it was clear that an entire country's worth of passwords were in the process of being stolen right in the midst of the greatest political upheaval in two decades. Sullivan and his team decided they needed a country-level solution — and fast.

Please tell me that they turned on https for logins by default. Because that is what they should have done.

solution

[Syobon]

yeah, the solution is easy: encrypt fucking everything.

Re:solution

[MichaelSmith]

The only way that can be made to work is for all of us to control the hardware and software we use, and for each of us to have a private key which we share with selected people. Systems which rely on dynamic key negotiation can be broken by routers. Systems which rely on globally available certificates can be broken by the authorities which operate the certs.

Bandwidth isn't free

[rsborg]

As big a fan as I am of HTTPS, it's not only slower than HTTP for the end user, but costs a bunch more in bandwidth and compute (cacheing problems).

I'd say only HTTP is also more along the lines of Zuckerberg's infamous opinion of his users... in his view they get what they deserve.

Https as commonly employed isn't enough

[Giant Electronic Bra]

SSL3/TLS will only protect against MITM attacks if BOTH the client AND the server mutually authenticate. This would require the issuance of a signed certificate to the client, not something that any garden variety retail grade web service does. On the other hand it is quite possible that just using HTTPS would have thwarted the attack simply because it puts a rather higher technical barrier in place and makes it necessary to use more intrusive measures. In any case the point is a good one, HTTPS should be universal for any kind of authentication for a whole raft of reasons.

Re:Https as commonly employed isn't enough

[cayenne8]

On a less tech scale...where is this Tunisia and what kind of turmoil is going on there, and why should I care..?

Hmm...guess I could have googled first....

Re:Https as commonly employed isn't enough

[TheMidget]

it is quite possible that just using HTTPS would have thwarted the attack simply because it puts a rather higher technical barrier in place and makes

... probably it would have thwarted the attack in this case, as Tunisia doesn't run its own certification authority, as far as I know. There apparently is a joint CA project between Tunisia and Oman. Thanks to Oman's presence, it would make it more difficult for Tunisia to pull a fast one...

However, many other "less than democratic" regimes, such as China, do run their own certification authorities, which are recognized by the browsers. So plain https would not be a protection.

And even client certificates can be compromised, as the Luxembourgish Luxtrust guys had to experience (they foolishly bought the hardware tokens from France, which then turned out to be backdoored...)

Re:Https as commonly employed isn't enough

[Locke2005]

Where is this Afghanistan where Osama Bin Laden is helping to fight the Russians, and why should I care? Gee, I don't know... do you think that perhaps countries at risk of being taken over by militants might eventually have an effect on you? They might even interrupt American Idol with a special news report about the attacks, and that would be a tragedy for you!

Re:Https as commonly employed isn't enough

[Giant Electronic Bra]

Well, large services such as Facebook could in theory simply issue their own client certs which are self-signed. It is more of an issue of it being a customer service issue than anything else.

Re:Https as commonly employed isn't enough

[Mysteray]

In theory, only one end needs to authenticate the other.

In practice, the website depends on the client to do a good job of this. So if you're running MS Windows, the Tunisan government can put a trusted root certificate in your computer with the endorsement of Microsoft. So even running https everywhere will not save Facebook from Microsoft.

Try it yourself. If you have access to a Windows machine, visit http://bit.ly/eWYRbA in IE then check your personal cert store for Agence Nationale de Certification Electronique.

If you think this is a big deal, retweet it or spread the word in other ways. I'm at a loss to explain why people aren't realizing the magnitude of this.

Of course, what's even better is that it's a CODE SIGNING cert. ;-) Now that's what I call pwned!

Re:Https as commonly employed isn't enough

[Vegeta99]

Now why not just explain the issue in its response?

Tunisia is a small Islamic republic, the nothernmost country in Africa. Its population is smaller than that of the US state that I grew up in, Pennsylvania.

I'm not Islamic (or religious). I live in a big city, but the terrersts ain't gonna come here. To show a little US bigotry, why the hell should I care? "Up next: Poor people pissed off at Government."

I am being completely serious here, not being bigoted. You cannot expect the entire world to be up-to-date on some little date republic's problem. Hell, they're even running out of colors to call the various "Revolutions" over there - we're on jasmine now.

Re:Https as commonly employed isn't enough

[Anonymous Coward]

Even if browsers used PAKE (instead of PKI-based encryption, i.e. SSL) before even beginning the connection, there would still be the need for a way for a user and facebook to agree on a secret password. Which can indeed be hard, depending on how badly the government wants to continue spying on citizens.

In short, DOOOOOM.

Re:Https as commonly employed isn't enough

[Anonymous Coward]

Obviously it doesn't matter to you, since you're not important enough for them to hack.

Re:Https as commonly employed isn't enough

[aj50]

It depends who needs to trust who.

If only the server is authenticated, then the client knows it it talking to the right person and both ends know that the channel is secure, assuming the client is verifying the certificate correctly.

In the Facebook case this is enough because the client will then authenticate using its username and password over the secure channel so that the server knows who it's talking to.

The bigger problem on the web is that many sites only use https for the login process so anyone able to interfere with the preceding unencrypted conversation would be able to present a fake login screen which did not use https or directed the credentials somewhere else entirely.

Assuming that the whole public key infrastructure is working correctly, SSL does prevent MITM attacks when only one end is authenticated. Assuming no-one has been able to obtain a forged certificate for the server and the server's private key has not been compromised, the client is able to be sure that it's speaking directly to the server. The server knows nothing about the client but generally this isn't a problem because once the client is sure that it has a secure connection to the server, it can authenticate itself to the server securely using another method such as a password.

Re:Https as commonly employed isn't enough

[icebraining]

The client does authenticate: that's the purpose of the password.

As long as the site uses HTTPS, the browser is able to validate its cert against the domain. Of course, they could be spoofing the DNS results, but that's what DNSSEC is for.
No need for client side certs.

Re:Https as commonly employed isn't enough

[BBTaeKwonDo]

FWIW, since Chrome on Windows re-uses some (maybe all?) of IE's networking layer, you can use Chrome instead of IE to reproduce this. There is a caveat - you need the "Update Root Certificates" program which was included in Windows XP SP2.

This page has a nice writeup of the problem and mentions that Vista or higher behave differently (not really better, just differently).

Re:Https as commonly employed isn't enough

[cayenne8]

"They might even interrupt American Idol with a special news report about the attacks, and that would be a tragedy for you!"

Hey, that sounds like a plus!!

If they interrupt Family Guy, well then....that's a WHOLE new ballgame!!

Re:Https as commonly employed isn't enough

[Giant Electronic Bra]

Assuming you ever get the real certs. At some level if the network is hostile you have to have some initial mutual authentication mechanism to even know what you are starting with. Is a root DNS key enough?

Re:Https as commonly employed isn't enough

[Nursie]

SSL3/TLS will only protect against MITM attacks if BOTH the client AND the server mutually authenticate.

Nonsense.

You can't MITM an SSL connection in which a server has a trusted certificate and the client has a trusted authority key. The client most certainly doesn't need a certificate in order to be able to trust who it's talking to, and client trust is the issue at hand.

Where did you get the crazy idea a certificate was needed at both ends?

Re:Https as commonly employed isn't enough

[Mysteray]

No, only one party needs a certificate (call them party S for server). The other party (C for client) picks a random symmetric key and encrypts it to the public key of S. S decrypts it and the two ends can exchange data.

This is a (greatly oversimplified) overview of how SSL usually works, without client certificates. The CA is necessary because the client doesn't know the server's cert in advance. It does have the limitation that S cannot prove the absence of a man-in-the-middle, but C can. In practice, S relies on C to do a good job of this. If C trusts a corrupt CA, then all bets are off.

SSL was originally designed to make people feel comfortable typing their credit card numbers into web forms on the internet. So it didn't originally provide any way for the server to prove the security of the connection (hey as long as the card goes through, right?)

Apparently Mozilla doesn't accept Tunisia as a trusted CA at this time. I blogged about this issue regarding CNNIC.

Re:Https as commonly employed isn't enough

[Anonymous Coward]

I think you mean run their own CAs as a self-signed cert is vulnerable to MITM attacks which defies the whole point of using one in this scenario.

Re:Https as commonly employed isn't enough

[darkpixel2k]

SSL3/TLS will only protect against MITM attacks if BOTH the client AND the server mutually authenticate. This would require the issuance of a signed certificate to the client, not something that any garden variety retail grade web service does.

Hmm...sorta like gpgAuth?

Re:Https as commonly employed isn't enough

[icebraining]

Assuming you ever get the real certs.

Fake certs wouldn't be signed by a valid CA.

At some level if the network is hostile you have to have some initial mutual authentication mechanism to even know what you are starting with.

Client PKI authentication solves nothing. The problem is determining if the server is actually Facebook's, not if the client is user3435.

Is a root DNS key enough?

So the Turkish hackers have the root DNSSEC key? Then you have greater problems than Facebook password stealing.
I'm guessing they don't.

Re:Https as commonly employed isn't enough

[Giant Electronic Bra]

The problem is you are all assuming that given IP X that my packets will go to the real X. That isn't what is going to happen. You can have as many root signed DNS responses as you want, all they tell you is what to put in your packet headers, they don't guarantee the traffic is actually going anywhere in particular. Thus DNS signing doesn't help you if the network is untrusted.

And if I can direct you to my fako proxy somewhere then all I need is to fool you enough. As long as I can get one CA to sign my cert that you trust then I can MITM you all day and all night. A client-side cert would defeat that see, because at least then the guy in the middle can't pretend to be the client to the server.

In the face untrusted networks you actually DO need client certs in order for your HTTPS to really guarantee anything. Passwords are not enough because once I'm in the middle of your conversation I can see all of that and you'll happily provide it. If both sides use a cert then SSL won't even happen with someone in the middle, barring actual faults in the protocol or implementation.

I don't think that word...

[wealthychef]

... means what you think it does:

a revolution that could become a parable...

Bzzt. wrong

No Kudos to facebook

[Tmack]

Like others have said, this is easily preventable. HTTPS. Make the http login page redirect to https, and make pages default to https and no more login stealing-by-snooping (firesheep) will work. As is, you can login via https, but all the links on the page are http. VERY annoying.

Yes, https increases CPU and bandwidth, but if you also include the benefits: reduction in staff, support, bandwidth, cpu, etc currently wasted trying to fix the resulting stolen/hijacked accounts, it would come out ahead, probably way ahead.

Tm

Re:No Kudos to facebook

[jpmorgan]

Okay, so Facebook sets up the http login page to redirect to https. When you go to login, the MITM proxy connects to the https login page... but doesn't redirect the client.

So how does HTTPS help? Without even getting into the issue of malicious CAs, HTTPS only protects people who connect to HTTPS directly (i.e., they type in https://www.facebook.com/). If you're relying on an HTTP redirector, you're fucked.

Re:No Kudos to facebook

[Patch86]

I'd be willing to be that these are the most common ways of connecting to Facebook are as follows, in order:

1) Using a favourite, bookmark, or phone app. Bookmarking the site should reflect the end destination, not the redirect portal (so HTTPS, assuming you set up a new bookmark), and apps would soon be configured to point at the correct (HTTPS) URL if it were the only working option.

2) Typing the word "facebook" or "facebook.com" into the address bar. The redirect is then in the hands of your browser, usually powered by either Google or Bing (depending on browser), and you would assume this would point you straight at the "correct" address (HTTPS). Possible to put a MITM in there I suppose, but not as straight forward.

3) Going to a search engine and typing "facebook", an clicking on the resulting link. Again, the redirect is in the hands of your search provider, and would presumably point at HTTPS. Still possible to MITM, but again trickier.

I can't imagine that in this day and age anyone still actually types "http://" in their address bar, and would therefore be relying on Facebook to do the redirect.

Re:No Kudos to facebook

[aiht]

2) Typing the word "facebook" or "facebook.com" into the address bar. The redirect is then in the hands of your browser, usually powered by either Google or Bing (depending on browser), and you would assume this would point you straight at the "correct" address (HTTPS). Possible to put a MITM in there I suppose, but not as straight forward.

No.
Modern browsers may do a search (as you say) for "facebook", but if you give them "facebook.com" they will go to "http://facebook.com/". The traditional browser behaviour is to stick a "http://" in front of whatever you type.

Political Companies? BS

[Anonymous Coward]

I absolutely despise this statement FTFA:

"Facebook needs to own its position as a part of The Way the World Works and provide protections for political speech and actors."

Why is it that activists of all persuasions tend to think that Company X should apply some sort of political guidelines to their business? Facebook is a business, plain and simple. If Facebook as a business takes sides in some sort of political/religious/ethical issue, then the opposing side will stop using the company's services; hurting revenue and damaging or potentially destroying the tool in the first place. Facebook in my mind did the absolute right thing in this situation: they established a set of rules for the use of their service (real identities, no psuedonyms or impersonation of other people, and no hacking other people's accounts), and allow access to whomever wants to partake as long as they follow those rules. When one party attempted to circumvent those rules, Facebook responded in line with their policies and blocked the circumvention. Part of this article appears to imply that Facebook alters it's profile to protect political free speech, but it's value is far greater as a tool to allow speech of all forms and allow all access to all parties. Political changes belong in the cultural/political arenas of society, the economic arena should be left out of it.

HTTPS is NOT the answer

[Anonymous Coward]

The only thing that matters in a secure system is trust. A better method is for facebook to exploit the users and facebooks mututal knowledge of a shared password to establish a secure channel and prove to each other common knowledge of the password. This way the user knows they are talking to facebook and facebook knows they are talking to the user.

Layering plaintext authentication on top of https is better than nothing but how much better? Given the rediculous expanse of trusted third parties any of which have the capability to compromise or sublet the compromise of the entire global system is not particularly reassuring especially when a government is your advasary.

Secure solutions for password authentication without the ususal offline attack vectors such as RFC 5054 (TLS extension) have been around for several years yet I fear they may never be implemented due to lack of user demand, conspiracy theories regarding the potential for negative impact on the SSL market (Good riddance I say) and questionable patent issues (Relevent ones having only recently expired).

If facebook really cares about security they will push browser vendors to implement RFC 5054 (Code or patches are already available for all of the major SSL toolkits)

Facebook ... Security ...

[Kittenman]

'Nuff said.

Re:Facebook ... Security ...

[Kvasio]

thanks God, USA does not such a bad things (with Echelon) ... do they?

SSL Strip

[js_sebastian]

Agreed, but this part of the article had me intrigued:

It wasn't a totally perfect solution. Most specifically, ISPs can force a downgrade of https to http, but Sullivan said that Facebook had not seen that happen.

I do not know the ins and outs of internet routing well enough to understand this, but I was alarmed by it. Does anyone with more technical expertise in the area have any insight?

It's called SSL Stripping... It's an old issue, but a recent tool has made it a bit more mainstream. There's a presentation here: http://www.blackhat.com/presentations/bh-usa-09/MARLINSPIKE/BHUSA09-Marlinspike-DefeatSSL-SLIDES.pdf. And a tool here: http://www.thoughtcrime.org/software/sslstrip/

The slides are worth looking through. At the root it's a very simple concept: people do not type https into the browser, they usually get to https through a redirect from http. A MiTM can tamper with that and continue talking http with the client... or he can talk https with both client and server (two different connections), but then he needs to play some tricks to get a signed certificate for a domain that looks to the user like facebook.com.

but Sullivan said that Facebook had not seen that happen.

How would they know? the MiTM could easily talk https with facebook.

https doesn't necessarily solve this

[codegen]

Most security certificate only specifies the domain name of host. A reverse proxy and a DNS record giving the proxy as the address of the server on the certificate is the basis of the Pharming attack. https/ssh/etc require that you have a trustworthy translation from name to ipaddress. A corrupt ISP defeats it.

Re:https doesn't necessarily solve this

[Jon Stone]

https/ssh/etc require that you have a trustworthy translation from name to ipaddress. A corrupt ISP defeats it.

Not true. The reverse proxy would need a private key certified by a trusted CA in the name of the server. If we assume (big assumption...) that the root CAs trusted by the browser never make a mistake, then there isn't any practical way for the proxy to impersonate the server and get away with it. X509 protects you from corrupt ISPs meddling with DNS, as long as the trusted third parties (the CAs) are truly trustworthy.

Re:https doesn't necessarily solve this

[Ash-Fox]

Of course if people are typing in 'www.facebook.com' by hand, you can intercept it unencrypted first and never let them go encrypted to begin with.

'The Cloud"

[jaylen]

Ironically, the thing that concerns me the most about this article is not that ISP's were key-logging, but that a journalist refers to the Internet as 'the Cloud'.

Have a muse as to why those in power would love us to think that the Internet has now been replaced by 'the cloud' and maybe you'll share my concern.

Litany of the Not So Saintly

[Mana Mana]

Someone else eating their lunch not their problem?

* Those are MY bitches, playa!

* Using and abusing our users is OUR job!

* If someone is going to fuck them in the ass IT'S going to be ME. ... things that might be overheard in Facebook control.

Am I the only one who noticed...

[Veneratio]

Am I the only one who noticed that the article mentions that the consultant who they interviewed, a one ms. Rim Abida, didn't want her full name published yet they repeatedly do so? Even in the same paragraph.

Unless, of course, that is a fake last name. But it doesn't mention that anywhere.

Huh?

[RichiH]

> Anyone who logged in during the period of time where passwords were being captured was presented with photos and asked to pick the ones featuring their friends. Then they were asked to choose a new password.

I don't use facebook, but where did FB get those pics? And wouldn't that mean that a determined attacker could successfully bypass this in most/all cases?

Re:Huh?

[Anonymous Coward]

It’s a standard Facebook precaution for when they think your account might be compromised. I got it back when I tried to log in from a computer in Romania.

Basically it gives you a series of photos from your friends’ albums, featuring themselves (according to the photo tags). Each step gave you 2 photos which had the same friend tagged in both, gave you a list of a few of your friends, and asked you to select which friend was featured in both photos. You had to get a certain number of them correct. IIRC you could click “not sure / can’t tell” up to twice, which gave you a little leniency if you weren’t terribly familiar with that person or both photos happened to be poor enough that you couldn’t make out who was in them.

Facebook is AOL all over again - stupid users.

[Anonymous Coward]

Facebook is AOL all over again - stupid users.

Just because something is popular, doesn't mean you should use it. Tweeter falls into this group too.

And not just social networking sites...

[grimarr]

It's not just social networking sites that have this problem. Verizon's web site makes it really hard to log in with SSL. If you enter the URL https://www.verizon.com/ yourself, it redirects you to the non-SSL page. My favorite trick is to enter dummy username and password values, and click "Log in". Usually, the "login failed, please try again" page uses SSL. Not Verizon's. I eventually found some combination that got me an SSL connection before entering my info, but I don't remember what it was.

I think this is a result of their newly reimplemented web site. They sent out an email, saying that customer's web accounts had all been changed, and urging us to click on a link in the email to enter new ones. You know, just like all the phishing attacks. But this one is real: Verizon's web site even has a message saying that those email messages were legit. Most companies repeatedly warn their customers that they should never trust emails that claim to be from the company and ask for your login information (and rightly so). Not Verizon. I hope they fix this before too many of their customers have their info stolen.