Passwords - the worst kept secret

So I'm writing some training material and I'm making a note that we don't use HTTP Authentication on the Internet anymore, it has loads of disadvantages.  Well it is supposed to anyway, I really couldn't find much detail on exactly what those disadvantages were?  I mean sure if there is a MITM then if you use Basic Auth then the MITM will get your password, or if you use Digest Auth then a MITM can downgrade to Basic Auth, or perhaps mount a dictionary-attack on your password.

Still, since the vast majority of web sites use forms-based authentication, what is the real difference (assuming you are using SSL/TLS)?  You are still sending your password over the inter-tubes.  Maybe I am missing something, I don't know.

To me though both Basic and Digest Auth had one advantage, the browser asked for my password and not the web page.  Why is that important?  Well there are a lot of spoofing attacks out there that try to fool users into entering their passwords into fake pages.

Entering passwords into fake pages is clearly a problem but really it isn't the fundamental problem.  The fundamental problem is that I am entering my password into a web page and that my password is being sent to the server at all.  Authentication is based on something you know, have or are, and so passwords fall into something you know, which means they should be a secret.  It's much easier to keep a secret if you never have to enter it into a web page and send it across the Internet and have it processed and stored (in some form) by someone else.

The 'what you know' requirement is merely proving that you know something, and while telling someone what you know does prove it, there are other ways to prove you know something without giving it away (see zero-knowledge password proof).

This does of course assume that a user and a site have agreed on a password already, and although I couldn't dig up much on schemes that don't have this requirement, I don't see why it shouldn't be possible.  A user could register a f(password) (a function of their password) and then authenticate at any time by providing g(password) where the site can convert f to g.  Note, I say possible, not easy, I haven't really given this much thought.

If the browser could be relied upon to do this securely on behalf of the user then it would eliminate many authentication concerns plaguing the Internet today, such as; spoofing authentication pages, MITM authentication attacks, server-side password or password hash disclosure, user password re-use.

Seems like it is definitely worth some more investigation ...