3 ms·

(I work for Mozilla, but no real bone to pick here) I dunno dude, that looks pretty bad. Isn't this kind of exposure fodder for the wall of shame at every hack

by sayrer 15y ago

(I work for Mozilla, but no real bone to pick here) I dunno dude, that looks pretty bad. Isn't this kind of exposure fodder for the wall of shame at every hacker conference? If The Register is accurate[1], the token will expire in 14 days, but that's plenty of time to read lots of email. Hopefully they can fix it on the server. Otherwise, it'll take a while to update all of those Android devices. [1] I know, I know

drivebyacct2 15y ago
It is bad and it's trivial to fix and it should have been obvious. But it's not leaking your username/password like the title implies (at least to me). This is just like logging into ANY website without using SSL... except that it's much more likely that they're on 3G since it's a mobile device rather than a laptop.
- sayrer 15y ago
  It's trivial to fix, then? Can this issue be fixed by changing the server? Otherwise this trivial fix will take a long time to deploy.
  - drivebyacct2 15y ago
    Well, trivial from a code perspective. I would presume that attempting to fix it from the servers would not work, unless they can 302 to an SSL server, but I don't know exactly how that would work, if ClientLogin can handle that. Additionally, as noted elsewhere, security fixes are distributed to more devices and faster than os upgrades for Android devices.
    - mike-cardwell 15y ago
      Even if they can modify the server to 302 to an HTTPS URL, that still wouldn't prevent MITM. An attacker could still intercept the HTTP request and forward on to the HTTPS URL. It would have some value because it would prevent passive sniffers, but it wouldn't be a complete fix. The fix needs to be on the client side.
    - jerrya 15y ago
      So let's summarize: 1. The AuthToken's are easy to sniff 2. Hard for the end user to fix and require code changes to fix completely which may not be available for your model of phone from your carrier 3. Valid for 14 days 4. "the adversary can subsequently use the captured authToken to access any personal data which is made available through the service API. For instance, the adversary can gain full access to the calendar, contacts information, or private web albums of the respective Google user. This means that the adversary can view, modify or delete any contacts, calendar events, or private pictures. This is not limited to items currently being synced but affects all items of that user." And in conclusion not a big deal and we should ban the register for spreading such vicious truths. And we know all of this because of our love of god.

by sayrer 15y ago

drivebyacct2 15y ago

It is bad and it's trivial to fix and it should have been obvious. But it's not leaking your username/password like the title implies (at least to me). This is just like logging into ANY website without using SSL... except that it's much more likely that they're on 3G since it's a mobile device rather than a laptop.

sayrer 15y ago
It's trivial to fix, then? Can this issue be fixed by changing the server? Otherwise this trivial fix will take a long time to deploy.
- drivebyacct2 15y ago
  Well, trivial from a code perspective. I would presume that attempting to fix it from the servers would not work, unless they can 302 to an SSL server, but I don't know exactly how that would work, if ClientLogin can handle that. Additionally, as noted elsewhere, security fixes are distributed to more devices and faster than os upgrades for Android devices.
  - mike-cardwell 15y ago
    Even if they can modify the server to 302 to an HTTPS URL, that still wouldn't prevent MITM. An attacker could still intercept the HTTP request and forward on to the HTTPS URL. It would have some value because it would prevent passive sniffers, but it wouldn't be a complete fix. The fix needs to be on the client side.
  - jerrya 15y ago
    So let's summarize: 1. The AuthToken's are easy to sniff 2. Hard for the end user to fix and require code changes to fix completely which may not be available for your model of phone from your carrier 3. Valid for 14 days 4. "the adversary can subsequently use the captured authToken to access any personal data which is made available through the service API. For instance, the adversary can gain full access to the calendar, contacts information, or private web albums of the respective Google user. This means that the adversary can view, modify or delete any contacts, calendar events, or private pictures. This is not limited to items currently being synced but affects all items of that user." And in conclusion not a big deal and we should ban the register for spreading such vicious truths. And we know all of this because of our love of god.