Security mechanism for CL access

[GoogleCodeExporter]

Granting 'anonymous' access to Google Docs (or likewise Contacts, Calendar, 
etc) seems very undesirable just to use the googlecl tool.  Some security 
mechanism should be used to confirm that user has password for account, or at 
very least that permission is only granted to a name that can be kept somewhat 
secret.

What steps will reproduce the problem?

$ google -u david.mertz docs list
(Hint: You can automatically launch your browser by adding "auth_browser = 
<browser>" to your config file under the GENERAL section, or define the BROWSER 
environment variable.)
Please log in and/or grant access via your browser at 
https://www.google.com/accounts/OAuthAuthorizeToken?oauth_token=4%2FlkHeQIZ2oxQP
wMto6V4_R3eJLeuD then hit enter.

Authorization can be performed via the produced link, but it requires 
authorizing 'anonymous' (I have done this experimentally, but revoked that 
permission afterwards).

What version of the product are you using? On what operating system?

$ uname -a
Darwin MacBook-3.local 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 
PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386

$ google --version
google 0.9.5

Please provide any additional information below.

The ideal solution here would be to provide a password option that would pass 
in a Google accounts password.  I suppose this might be OK to give the password 
on a command-line, e.g.:

$ google -u david.mertz --password='MyPassword' docs list
(Hint: You can automatically launch your browser by adding "auth_browser = 
<browser>" to your config file under the GENERAL section, or define the BROWSER 
environment variable.)
Please log in and/or grant access via your browser at 
https://www.google.com/accounts/OAuthAuthorizeToken?oauth_token=4%2FlkHeQIZ2oxQP
wMto6V4_R3eJLeuD then hit enter.

However, showing that in plaintext (not my actual PW in the example, of course) 
seems bad.  Better would be producing a prompt with getpass.getpass('Google 
Account PW:') or the like.

Original issue reported on code.google.com by david.me...@gmail.com on 19 Jun 2010 at 12:33

[GoogleCodeExporter]

While an actual password for access is certainly better, the idea I mentioned 
about a "somewhat secret" name can be fleshed out.  One might put a flag in 
~/.googlecl/config such as:

[DOCS]
anonymous-account = 0b0e1071d27aff3a5a20323f2afb9b33

If the user must grant that "anonymous" access to the CL user, the actual name 
authorized might be something not easily guessed.  It is not great security, 
since it is only as good as the protection of a plaintext name in my 
~/.googlecl/config file; but at least a random person anywhere in the world who 
happens to know my user account name will not be granted access just by using 
googlecl.

Original comment by david.me...@gmail.com on 19 Jun 2010 at 12:38

[GoogleCodeExporter]

The security in place is the same as any other authorized website afaik. What 
concerns me is that it's registering it's name as 'anonymous' which doesn't 
"feel" right. I'd much rather the tools register themselves explicitly as 
googleCL so that I can easily tell looking at my authorization list.

Original comment by lusis....@gmail.com on 19 Jun 2010 at 2:06

[GoogleCodeExporter]

I complete agree with this bug. anonymous doesn't "feel" right.

Original comment by Mr.etern...@gmail.com on 19 Jun 2010 at 2:13

[GoogleCodeExporter]

OK, some more details.  It appears this isn't the security issue I thought, 
merely confusing.

I did the authorization above on one machine, the OSX machine indicated.  That 
let me run 'google docs list' on that machine.  Switching to another machine 
(Ubuntu 10.04) on the same internal network (i.e. sharing a WAN address), I 
require a new authorization using a different Google Accounts authorization 
URL.  So there is different authorization information being stored on each 
machine (WHERE is the relevant key information stores?!)

However, looking at https://www.google.com/accounts/IssuedAuthSubTokens, I see 
a report like:

-----
Authorized Access to your Google Account

You have granted the following services access to your Google Account: 

Websites 

anonymous — Google Docs [ Revoke Access ]
www.google.com — Google Latitude [ Revoke Access ]
-----

That same "anonymous" name masks two separate authorizations.  If I click 
"Revoke Access", I get a message that I have successfully revoked access, but 
the 'anonymous' authorization still appears.  This turns out to be because that 
same line was reporting the authorization of both machines that have the same 
name.  Revoking indeed removes the privileges from ONE of the two machines, 
while the other still has credentials.  In particular, it seems to follow a 
FIFO pattern with authorization/revocation, but there is no way to revoke one 
particular machine, just the "first authorized" machine.  Or maybe it is just 
revoking the one that has the earlier key alphabetically or some other pattern.

There should really be some way of revoking the permission from a specific 
machine, presumably by giving a distinct NAME to each machine being authorized. 
 Maybe this should be standard network names, maybe something else.  But 
definitely names that are distinguishable and that are reported as different 
authorizations in the My Account page.

Original comment by david.me...@gmail.com on 19 Jun 2010 at 4:10

[GoogleCodeExporter]

Interesting. OAuth (the method of authorization now in place) was added to 
GoogleCL fairly recently, and I haven't read through all of the documentation.

To address the most immediate concern, Issue 41 contains a patch that will 
display a more reassuring request for authorization message. This change has 
also been pushed to the svn repository.

I'm not sure about revoking permissions for certain machines through the web, 
but you can erase ALL access tokens from a machine for a single user by 
deleting the appropriate file from the machine's GoogleCL folder (currently 
~/.googlecl). The file will be called "access_tok_<username>". Deleting that 
file will ensure that anyone using that machine will have to re-authenticate as 
you.

Original comment by tom.h.mi...@gmail.com on 19 Jun 2010 at 4:07

[GoogleCodeExporter]

I solved this by introducing new commandline option --node. By default it's set 
to <current username>@<current hostname>. I also added node to the application 
name and now I can see "GoogleCL ed@mydomain.com" (or whatever I specify as a 
node) as a name of application on 
[https://www.google.com/accounts/IssuedAuthSubTokens My Accounts] page. Works 
for me just fine.

I'd really appreciate if somebody would try the attached patch.

Original comment by bart...@gmail.com on 11 Jul 2010 at 8:38

Attachments:

• Issue57.diff

[GoogleCodeExporter]

Sounds like a good solution. 

Original comment by tom.h.mi...@gmail.com on 12 Jul 2010 at 3:44

• Changed state: Started

[GoogleCodeExporter]

This issue was closed by revision r342.

Original comment by tom.h.mi...@gmail.com on 12 Jul 2010 at 7:06

• Changed state: Fixed