4 ms·

I thought this too, but if you go look at what was actually done, 'keylogger' is a fairly accurate description. They were injecting a Javascript keylogger, not

I thought this too, but if you go look at what was actually done, 'keylogger' is a fairly accurate description. They were injecting a Javascript keylogger, not doing packet sniffing or the like. Not the same as a keylogger actually running on your OS, but I would say still the correct term. Facebook sends login credentials over HTTPS, they aren't so dumb as to authenticate over HTTP. But they serve their login page over HTTP which is what allowed the Javascript keylogger to be 'installed'. (edit) PS Here's a link to the purported exploit: http://www.hackerzvoice.net/node/105 http://www.hackerzvoice.net/node/105

pak 16y ago
Whoa, this is by far the most interesting news here. It occurred to me that an evil government could hijack all HTTP requests, slip a script into the <head> and literally monitor every keystroke and click and mousemove for their web users, using their browser as the key logger and with little knowledge by the end user (unless they scan the source of every script). That's freakishly powerful spying capability, beyond just tracking and logging requests/IPs/contents.
- dansingerman 16y ago
  Agreed, which is why describing it as a 'key logger' seems to miss the point. Although admittedly I guess The Atlantic are not targeting the HN crowd. However, the problem would have been (mostly) avoided by serving the login form over HTTPS. As most people who have used a browser have some notion of HTTPS vs HTTP, couldn't the Atlantic have credited their users with some intelligence, and mentioned the significance of that in the exploit?
pasbesoin 16y ago
I've spent time arguing with some fairly large and supposedly security-minded entities, about just this practice -- delivering login forms over HTTP. It doesn't matter that the specified destination is HTTPS. A MITM can do whatever they want to the form and its enclosing page while it's on its way to the client browser. There's a quite successful startup, much beloved by HN, that has exactly this problem with one version of their sign on page. I won't say which one, because I don't want to make targeting too easy. I've been having a back and forth on a support ticket with them, after noticing the problem. They did say they followed up and looked into my concern. But they compared their design to Facebook et al. and said they were following "best practices". An aside: Once you start using the term "best practices", you need to take a serious look at your design and engineering perspective. Especially in security, your thinking should always be challenging the established model. You may not find a better way, and you should be very skeptical of yourself when you think you have. But you need to be a bit... paranoid, always challenging the "established truths". EDIT: To that company, if you happen to read this. I posted this after emailing you. And before the coffee fully kicked in. It wasn't my intention to create so blatant a cross reference for you to follow between me here and me in email. (I.e. not some twisted version of karma; just trying to make the point.)
- metageek 16y ago
  The RFC curmudgeon in me says we shouldn't be using login forms anyway; we should be using HTTP Digest authentication. No passwords are sent over the wire, in the clear or not.

pak 16y ago

Whoa, this is by far the most interesting news here. It occurred to me that an evil government could hijack all HTTP requests, slip a script into the <head> and literally monitor every keystroke and click and mousemove for their web users, using their browser as the key logger and with little knowledge by the end user (unless they scan the source of every script). That's freakishly powerful spying capability, beyond just tracking and logging requests/IPs/contents.

dansingerman 16y ago
Agreed, which is why describing it as a 'key logger' seems to miss the point. Although admittedly I guess The Atlantic are not targeting the HN crowd. However, the problem would have been (mostly) avoided by serving the login form over HTTPS. As most people who have used a browser have some notion of HTTPS vs HTTP, couldn't the Atlantic have credited their users with some intelligence, and mentioned the significance of that in the exploit?

pasbesoin 16y ago

I've spent time arguing with some fairly large and supposedly security-minded entities, about just this practice -- delivering login forms over HTTP. It doesn't matter that the specified destination is HTTPS. A MITM can do whatever they want to the form and its enclosing page while it's on its way to the client browser. There's a quite successful startup, much beloved by HN, that has exactly this problem with one version of their sign on page. I won't say which one, because I don't want to make targeting too easy. I've been having a back and forth on a support ticket with them, after noticing the problem. They did say they followed up and looked into my concern. But they compared their design to Facebook et al. and said they were following "best practices". An aside: Once you start using the term "best practices", you need to take a serious look at your design and engineering perspective. Especially in security, your thinking should always be challenging the established model. You may not find a better way, and you should be very skeptical of yourself when you think you have. But you need to be a bit... paranoid, always challenging the "established truths". EDIT: To that company, if you happen to read this. I posted this after emailing you. And before the coffee fully kicked in. It wasn't my intention to create so blatant a cross reference for you to follow between me here and me in email. (I.e. not some twisted version of karma; just trying to make the point.)

metageek 16y ago
The RFC curmudgeon in me says we shouldn't be using login forms anyway; we should be using HTTP Digest authentication. No passwords are sent over the wire, in the clear or not.