Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I recently bought a newsreader app for my tablet that connects to Google Reader. To do so, it required my Google account password. Isn't this effectively the same as handling the password to the developers of said app? I wouldn't care about someone else reading my feeds, but this could be used to access my private email as well... Isn't this an extremely efficient method of gathering passwords and a terrible security risk for users?

share|improve this question
    
Are you sure it was actually asking for your Google account password itself rather than redirecting you to Google to request permission via OAuth (see answers below)? –  jrdioko Sep 6 '11 at 16:32
1  
Not sure, but it presented a form consistent with the look and feel of the application, so no way to tell what was happening behind the scenes, but looked suspicious... –  UncleZeiv Sep 6 '11 at 22:25
add comment

4 Answers

up vote 5 down vote accepted

Can apps be trusted when requesting your credentials?

No. In modern applications and web applications users have become numb to the requests for username, password, and various other innocuous details. The commonality has led users to believe that these information nibblets are useful to the application. However, this is wrong. With rare exception, authentication is unnecessary to application function.

In fact I believe application use of authentication is detrimental to the user. It makes authentication too common, making users less prudent and careful in cases where authentication is needed. It structures the identity space making it easier for attackers to guess your identity. It simplifies the keyspace making it easier for attackers to find your keys. It dampens operation security and degrades security practice for assets with value.

Isn't this effectively the same as handling the password to the developers of said app?

Yes, with rare exceptions. Even in cases where the protocol is not directly delivering the password to the application or developer, but is instead delivering an authentication token, the potential for misuse and abuse is high. Even OAuth has vulnerabilities 'This protocol makes no attempt to verify the authenticity of the server.'.

Isn't this an extremely efficient method of gathering passwords and a terrible security risk for users?

Yes, even when it is unintentional, poorly designed authentication schemes can provide a wealth of information for attackers. Even if the username and password you use for a typical application is not the same as the username and password you use for more important assets, the patterns you use help attackers narrow in on the valuable authentication. In contrast, well designed protocols like OAuth have a bright side: they reduce the number of pairs of usernames and passwords, as well as the number poorly design, poorly implemented authentication interfaces.

However, we also need to look at the OAuth service providers: Google, Yahoo, and Facebook. These are companies with an interest in collecting and aggregating information about users specifically to make money from that information. Using these companies as authentication providers is in part a bizarre contortion of trust. You are trusting these companies to handle authentication of your identity only to parties you specify. While they have a conflicting interest in providing data about you with as high resolution as possible to parties your are unaware of. Their most effective claim is that the information they provide about you to third parties is anonymous. They hold that this will be true despite the fact that they now know your identity and have authenticated it, potentially many times. I have been unable to find any policy specifically stating that these providers will never allow your authenticated identity to be connected to other collected. Caveat emptor.

The application in question: 'newsreader app for my tablet that connects to Google Reader'

The purpose of this application is to monitor no-cost publically available online content (web sites and RSS feeds) for new content, to notify you when new content is detected, and to display the content on request. The online content is not unique to you, meaning that you do not need to identify yourself to obtain the data.

The data that is unqiue to you is the list of sites and what content you have marked as not-new. Uniqueness requires identity but not necessarily authentication. The application uses Google Reader, although it could simply implement its own functions without the need to use Google Reader. Likely the application is doing this to keep your data coherent (synchronized). You want to be able to check online content from a number of different devices and not need to manually update changes on one device that you made on another. Note that the application could still synchronize with other devices without using Google Reader.

Your unique data (site lists and read-content) is transfered to and from your device. Authentication does not provide confidentiality (privacy). So authentication is not protecting others from seeing your site lists and read-content. Authentication does not provide integrity, so your data could be corrupted or maliciously modified while in transit. What authentication provides is a way to control the reciept and storage of the data. If the data is from you then it must be valid and thus an update from your current device to all your other devices should be accepted so your data is kept in sync.

share|improve this answer
    
Thank you for your interesting thoughts. Going back to the specific case at hand, a newsreader application that interfaces with my Google Reader feeds will need some sort of authentication to access them. Even if granted with OAuth, this effectively gives the application the permission to read, for instance, my email which is way more sensitive. Heck, I could make my Google Reader feeds public and I wouldn't care. Ultimately, I see this as Google's fault, there should really be a way to access the less sensitive parts of your account without putting at risk the others. –  UncleZeiv Sep 7 '11 at 9:30
    
You are falling into the authentication trap. Unless you are paying for the feeds, there is no functional reason to authenticate. If the content is free and you are not making any modifications, the data you recieve is identical to the data provided to anyone else. Authentication proves identity. Identity is only required if the data you recieve is different from the data someone else recieves. –  this.josh Sep 7 '11 at 14:31
    
Hm, either I can't understand what you are saying, or I'm under the impression that you are not familiar with Google Reader. It's a feed reader, I follow a selection of RSS feed that is my own, and this, along with the unread status of the post, is what is stored in my Google account. That's why an app that works as a Google Reader client requires authentication. Again, this data is not sensitive, I wouldn't mind to have it public, but unfortunately all Google services share the same authentication, so the developer of the app could also read my email once he knows my Google Reader password! –  UncleZeiv Sep 7 '11 at 15:41
1  
@UncleZeiv, if the app developers used their own servers (rather than Google's), the app would not need to the authenticate the user. When the app is installed onto your phone, it could create a new account on the servers using a new random identifier. When the user launches the app subsequently, the app could connect to the server and synchronize, using the same identifier to identify itself. If you want to prevent others from looking at your feed (e.g., for privacy or to prevent mischief), the app could generate a new public keypair at install time and authenticate -- all invisibly. –  D.W. Sep 8 '11 at 6:09
    
Ok I see what you mean now, but I should have made clearer that in this case connecting to Google's servers is actually a requirement, unfortunately. I read my feeds using other clients as well, and they need to be all synchronized. –  UncleZeiv Sep 8 '11 at 10:01
show 1 more comment

I agree with @Sebo that this is a risk. Because the Google account is shared for many Google services, disclosing your Google account password to the newsreader app feels a bit iffy. Someone who gets access to a user's Google account password could potentially get at an awful lot of sensitive information about the user.

I agree with @Steve Dispensa that OAuth would be a good solution for this. In fact, it looks like Google already supports OAuth access to Google Reader -- so there's nothing stopping the newsreader app from taking advantage of this solution. If your newsreader app was written to use OAuth, it wouldn't need to store your Google password. Unfortunately, OAuth is not as widely known as it could be.

share|improve this answer
1  
how can a user tell if an app is using OAuth? –  UncleZeiv Sep 6 '11 at 9:04
    
@UncleZeiv: On Android, the app would ask you for permission to use your Google account to identify (but not the name or password!). –  Piskvor Sep 6 '11 at 12:33
add comment

You're right to be concerned. Most users reuse passwords in one context or another, and most can't remember exactly what they've done where (unless they just use the same one or two passwords everywhere).

One possible solution to this problem:

https://secure.wikimedia.org/wikipedia/en/wiki/OAuth

Another potential solution is OpenID:

https://secure.wikimedia.org/wikipedia/en/wiki/OpenID http://myopenid.com

share|improve this answer
    
It's worse than that. This is a security risk even for a user who never reuses any password -- because the one Google account password provides access to all Google properties, not just Google Reader. –  D.W. Sep 6 '11 at 7:08
    
I confess I don't immediately see how OpenID would solve this problem. Can you elaborate? –  D.W. Sep 6 '11 at 7:16
    
Well, the idea is that, rather than giving your password to a bunch of different applications and websites, you use a single OpenID credential that does a single sign-on. I said "potential" because it's really tied to the web, rather than to API-based integrations, but it could be made to work. –  Steve Dispensa Sep 6 '11 at 12:56
add comment

I think there is a huge security risk. Even if it's an iPhone app and apple reviewed it.

It would be nice, if google introduced some alias logins. So that you can set up a different username and password. With that username only certain services from google could be accessed.

I usually create me a separate account for google reader.

share|improve this answer
1  
sadly, google reversing their decision on aiming for 'real identities' doesn't seem likely –  Rory Alsop Sep 6 '11 at 8:36
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.