Did you know that by simply signing into most web services like Facebook, Google+, iCloud, etc., they have access to your cleartext password each time your login? Sure, your password is sent over SSL so only you and the service (and perhaps the NSA and your employer) would know what it is. I assumed that most services were using some form of Challenge-Response based on the browser encrypting some data with the user’s password (perhaps in javascript) before sending it to the service. Poking around on the web form of Facebook and other services, it *looked* like the unencrypted password is posted in form data just like any other data. However, I wasn’t sure. So I did what anyone else would do and grabbed HTTPFox Firefox add-on that lets you see the traffic sent over SSL, then headed over to some common sites. I logged into each using the password “xyzzy” and you can see the services I checked all posted the unencrypted data:
AWS Web console
Hotmail
Gmail
iCloud
Even though the data is sent over an encrypted channel via SSL, it still seemed to me a bad idea to send the cleartext password to the service unless the user is creating an account or changing their password. I am not the first one to notice this. My major concern is two fold:
1. Most people have 4 or 5 passwords that they use for most services, and if the first one fails, they try the others. This gives the services you are authenticating to a trail of all the common passwords you use. You may trust the larger sites, but what about for services that you are not that familiar with? Just giving them your “standard” password may be risky, but giving them all of your previous and common passwords seems like a bad idea. It is also possible that those services log each of your password attempts and may even capture the data to a database.
2. In some corporate environments, users are forced to use HTTPS proxies. This means that data is only sent in an encrypted channel between the proxy and the service, and IT would be able to see your cleartext password if you used one of these services.
It looks like the solution would be to use something like SJCL , jCryption or NoSSL. It seems that for compatibility-sake, this is common practice.
This does highlight using OAuth with smaller web services. If you already trust Facebook or Gmail with your password(s), and you use OAuth to log into these smaller sites, your password is never shared with those services. Your OAuth provider would still require authentication on their web form and would have access to any password you type in the login form, but at least you would not be sharing that information with unknown services. Recently, I have stopped using OAuth from Twitter or Facebook due to a service that required the ability to post to those services on my behalf as well as posted ads to that service without asking me first.
The bottom line: this password situation is not so great. Users need to figure out who to trust,even though that keeps getting more and more difficult. Also know, the should be basic fact that your trusted service might not really be about authentication but about social and sharing.
NOTE: Updated with copy edits for grammar on 14 April 2014.