3 ms·

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

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 16y 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 16y 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 16y 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 16y 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.

sayrer 16y 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 16y 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 16y 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 16y 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.