5 ms·

This seems like a transparently disingenuous way to further platform lock-in using security as a pretext. I question the level of "security" this provides, espe

This seems like a transparently disingenuous way to further platform lock-in using security as a pretext. I question the level of "security" this provides, especially given that there's little difference on the client side from using an app-specific password and using an OAuth2 bearer token, except the latter is more annoying to acquire and use. Either way, it's a small blob of text managed via Gsuite that the user has to have on their device and that an attacker could steal.

jiveturkey 7y ago
from the client side, yes. but from their side, ASPs are a codebase they apparently would like to free themselves from. it's understandable, given that most client apps by far (by %use) support oauth. oauth2 is definitely more annoying for a client to implement, much more annoying. but it's much easier for a user than ASPs.
- deleted 7y ago
  [deleted]
zozbot234 7y ago
The blogpost mentions that an attacker could use a normal username and password to access your account via some app that they control, and this is a channel they're trying to get rid of. Even if all that OAuth does is meaningfully enforce the "app-specific" part (including providing the user with a workflow to authorize app access or reject it) this is a meaningful improvement in security.
knorker 7y ago
Except app-specific passwords are not app-specific at all. You maybe have a calendar app, but then someone steals that and uses it to read email, and delete account recovery emails sent, owning you to hell and back. ASPs are a real problem and a liability. A read-only view into your calendar or email is not as much. I'm not saying you're wrong about what their motivation actually is (but you are just speculating), but you can't throw a rock without hitting a security expert who can easily argue why ASPs are a huge security liability.
- icedchai 7y ago
  Perhaps they could support app specific passwords that behave similar to bearer tokens, with a scope that limits API access, etc. Not saying this is a good thing. OAuth is simple enough to set up.

jiveturkey 7y ago

from the client side, yes. but from their side, ASPs are a codebase they apparently would like to free themselves from. it's understandable, given that most client apps by far (by %use) support oauth. oauth2 is definitely more annoying for a client to implement, much more annoying. but it's much easier for a user than ASPs.

deleted 7y ago
[deleted]

zozbot234 7y ago

The blogpost mentions that an attacker could use a normal username and password to access your account via some app that they control, and this is a channel they're trying to get rid of. Even if all that OAuth does is meaningfully enforce the "app-specific" part (including providing the user with a workflow to authorize app access or reject it) this is a meaningful improvement in security.

knorker 7y ago

Except app-specific passwords are not app-specific at all. You maybe have a calendar app, but then someone steals that and uses it to read email, and delete account recovery emails sent, owning you to hell and back. ASPs are a real problem and a liability. A read-only view into your calendar or email is not as much. I'm not saying you're wrong about what their motivation actually is (but you are just speculating), but you can't throw a rock without hitting a security expert who can easily argue why ASPs are a huge security liability.

icedchai 7y ago
Perhaps they could support app specific passwords that behave similar to bearer tokens, with a scope that limits API access, etc. Not saying this is a good thing. OAuth is simple enough to set up.