A simple observation about another risk involving plaintext passwords sent across the network…

This has nothing to do with whether the channel in encrypted (typically HTTPS - HTTP over SSL). Rather this has to do with whether the remote server is receiving plaintext passwords.

If you use applications on the web, there are likely several if not dozens of sites on which you are required to enter both a username and password. With so many different sites requiring passwords, you have a couple of choices.

The easiest choice is to use the same username and password on as many sites are possible. Using the same username and password everywhere is easiest to remember, but likely will not work everywhere as different sites have sometimes in different requirements (minimum and maximum username and password lengths), and on more popular sites the username you wish to use may already be in use. This is also the least secure as once anyone gets ahold of your username/password they can use gain entry to all the sites where you have used that combination. For sites where someone gaining access to your account (online bulletin boards and the like) is inconvienent but not harmful - a use of single common username/password is only a modest risk.

Using a different username/password for login to every site is simply impractical. With too many different logins to remember you will be forced to record (on paper or elsewhere) all the different logins used. If you ever lose than record - and it falls into the wrong hands - then whoever obtains the record now has access to all your recorded accounts.

Another aspect to this problem is the information that can be collected from subverted sites. With so many different web applications in use managed by so many different people, there is a good chance one or more are easily subverted. From a subverted site successful logins can be monitored to obtain username/password logins valid for that site - but the failed logins may be nearly as or more interesting. A failed login may represent a case where the user entered a valid login for another site! In fact if the attacker has enough control over the subverted site, a good approach would be to occasionally reject a valid login, and record the alternatives tried by the user. The valid login would tell you the identity of the person trying to login, and the alternatives tried by the user would tell you possible username/password combinations to try at other sites where the person has accounts.

The solution to all this is easy to imagine, but more difficult to implement. A user should only have to ever remember one password, and the plaintext password should either never be sent across the network, or only ever be sent to one trusted site.

The “one trusted site” approach is similar to Microsoft’s Passport service. Given Microsoft’s history as a sometimes rapacious competitor, folks were not universally willing to trust Microsoft, so Passport was never widely adopted. Also a single “trusted site” for everyone to use represents a single point of failure - always something to avoid in a design. What this means in the case of a like Microsoft’s Passport service is that the service becomes a single point of attack, and if any attack were successful the amount of information disclosed is huge.

A better approach is to have multiple “trusted sites” run independently, where you get to pick the one you trust. This is similar to the Liberty proposal (and somewhat to OpenID - not exact equivalents, BTW).

Another alternative is to only ever enter one good password on your local machine, and compute a one-way hash from the one master password (which is not stored and never leaves your machine) to generate a unique password for each individual site. One example of this approach is PasswordMaker (there are others).

The risk of manually entering passwords to so many sites deserves a bit more emphasis.