3 ms·
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.
by 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 agoWell, 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 agoEven 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 agoSo 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.