|
|
|
|
|
|
by stevew20
2756 days ago
|
|
|
I think he's saying that in the persuit of security, Google has engineered the usefulness and useability out of this application. There are good, sane, safe ways to hold login credentials. Instead of those ways, Google has picked one that is incredibly inconvenient, and with opening a server on your machine, also opens a new attack surface... I hope they deviated from their aweful coding practices and made the server right... |
|
|
Sure the interface could be tweaked a little by maybe offering to select which browser to login with or othering the user a “copy sign in link to clipboard” button or something for few people using multiple browser slash containers to keep there accounts separated.
As for the localhost server listening for the code from oauth, it only needs to run for the duration of processing the first login (if you are going to use a keep signed in feature) reducing the window anyone could attack the server. It doesn’t need to punch a hole in your nat, it just needs to bind to localhost instead of your network card so only processes running locally could access the server during the process.
Using a state field could remove any csrf attack surface.
All the server should be receiving in this case is a single use code which can be exchanged for an access token to use the account depending on the scope you have defined during to login process. The data in transit it’s still encrypted all the way back to your browser. It’s only after you have successfully logged in with the auth site send you a redirect header so your browser does the final step of passing the code to the application.
If you captured the code in the redirect you would have to use the code before the application could and if you managed that the application can not use the code to the user in asking the user to log in again, if the user is able to successfully login to the application then your access token will probably be revoked once it’s regenerated when the application exchanges the code it got from the successful login for a account bearer token.
Considering all this I would say it would be easier to just intercept the access token over the network, the application memory or from where ever the application stores it for its next use (it’s keep me signed in functionality) which could be exploited from any other locally running application on your system.
I don’t see how this is any less secure than sending the users password over the wire from your application, having to dead with any 2fa the user has.