Why aren't zero-knowledge proofs used in practice for authentication? I read on Wikipedia that zero-knowledge proofs are not used for authentication in practice. Instead (I think) the server is entrusted with seeing a password in plaintext form, which it should then add a salt to and hash. But for a split moment, the server knows the secret. Why should I implicitly trust the server like this? It could go rogue and record my password in plaintext form. I could use that same password for other sensitive things. Aren't zero-knowledge proofs a necessity? Why aren't they used? Or are they used?

Update, an alternative: What about never reusing your password and instead generating different passwords from a master password and website name using only a program that runs on the client? It seems much simpler, because you never reveal the master password. That way, you don't need to trust the website nearly as much.

This clarifies my previous question.
Answering the question in your title (and not addressing your proposed alternative which I don't quite understand) there is a zero knowledge proof of password protocol "SRP" which is fast and effective. 

SRP does not seem to have been given as wide publicity as it should get. Having implemented it, and being an advocate of its use, I don't really understand why everyone doesn't use it all the time. Some reasoning that I have seen for dismissing it are:


A belief that a server is either totally 'good', or totally 'bad', and that using HTTPS ensures you always talk to 'good' servers, which can be trusted with plaintext passwords. Real life just isn't like the movies; it is more complex. The Heartbleed debacle shows that an otherwise trustworthy site can be leaking bits of memory such that a plaintext password sent over HTTPS can be observed by 3rd parties. More common would be poor error handling in custom website code which would print out a plaintext password into a log file which can be read by an intruder who can only see the file system on the server. Large systems stream logs to a central local exactly to make it easier to look at errors in logs where many people can search for patterns.
A belief that the client is either fully secure, or totally compromised, such that an attacker can see nothing, else can record what is being typed. If an attacker can record what is being typed they can steal the password directly; SRP only protects against interception on the wire and the TLS protects the wire. In reality interception is much more routine than people realise even using well configured HTTPS. Large employers routinely decrypt and scan HTTPS to protect themselves from intellect property theft by their employees. Even if they are only doing this to protect their own digital property rights it increases the risk of bugs leaking plaintext passwords or else a rogue employee stealing passwords. Big laptop suppliers install things like superfish to decrypt customers HTTPS traffic to sell "smart ads" on pages. They might not be all bad people; but it increases the risks of bugs leaking passwords or else a rogue employee stealing them. There have also been examples of certs being compromised meaning that encrypted traffic can be snooped. All this means that it might often be the case that an attacker cannot directly record what the user typed at the keyboard; but can view anything passed over the network even when HTTPS is being used. SRP can protect against any such interception as it is a zero knowledge password proof. 
A belief that SRP is an positioned as an alternative to HTTPS. SRP does not (out of the box) verify the server (upon registration) so you might be talking to a fake server. So in an "either-or comparison" of SRP and HTTPS (assuming none of the problems detailed above) then HTTPS is often judged superior. This is a false dichotomy as in practice real world HTTPS has many weaknesses which can be addressed by using SRP over HTTPS. Performing SRP over HTTPS gives you server verification which strengthens SRP. So people should always be using both together. 
A lot of focus on two factor authentication as an enhancement to plaintext passwords. Companies who have identified that passwords are high risk tend to employ a second factor (say, a text to your phone). The site may still leak passwords, which users may be using on multiple sites, many of which don't use a second factor. If sites upgraded to use SRP and a second factor they would fully protect their users. 


When it comes to implementing SRP there are a couple of inhibitors: 


A historic lack of a pure JavaScript examples. An early authoritative demo used a Java applet. Recently after the Heartbleed debacle there has been a revival of SRP and there are now a few solid opensource JavaScript libraries and demos. 
An extra round trip to login. With plaintext you send username and password in one post. With SRP you first send username to get the salt (and a challenge) and then generate the password proof to send to the server. Most web security frameworks assume that everything is sent in one round trip. This can be addressed by an AJAX call for the first round trip and posting the password proof as the password. More sites are now splitting username and password across two pages to implement ”social login”. Based on your email given at the first page they present a password page that targets the correct social login server. This two page pattern fits well with SRP and end users are becoming more familiar with it. 


Having said all of that there is no good reason why every site doesn't now use SRP. So you are correct in being surprised that plaintext passwords are still in use. 

Update: I still encounter quite aggressive push back about SRP from crypto experts who are arguing about TLS being sufficient. I am sure they are only hired by high security outfits that (in theory) would never make the mistakes listed above. The fact that they use their theoretical knowledge to shoot down a practical additional defence in depth strategy of both TLS and SRP is a surprise to me. I didn't become a fan of SRP for theoretical reasons. I became a fan after the online banking system I had just upgraded failed its penetration testing with perfectly configured TLS with the external tester managing to harvestest live passwords. As my grandfather told me ”In theory, both theory and practice are the same. In practice, they are not.” Passenger airlines use redundancy to keep people alive. Security practitioners should use defence in depth rather than a theoretical model of security.