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?
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.
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.'.
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.
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.
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:
Another potential solution is OpenID:
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.