> 2. With password-based systems, a malicious provider could also intercept reset emails,
He could also intercept the login attempts (e.g. webmail login form => the password is typically sent in plain text to the server [regardless of transport security]), the user will never notice.
> webmail login form => the password is typically sent in plain text to the server [regardless of transport security
I don't understand what you mean. If the form submit is over https, isn't the password neccesarily (not just typically, but always) _not_ sent in plain text to the server, but sent encrypted via SSL/TLS cause that's the whole point of https?
> isn't the password neccesarily [...] _not_ sent in plain text to the server, but sent encrypted via SSL/TLS cause that's the whole point of https?
https is transport security. The data goes over the 'net in encrypted form, but the endpoint will get it in plain text (same as the contents of the html page with the form, which your browser sees as plain text, even though you access it over https). Therefore, an attacker who operates the server (or has compromised it), can just grab the plaintext passwords as you log in over https.
I think the point is that if your email provider is hacked or malicious, your email password is hacked, but that's really only a problem if you use the same password on multiple sites. Don't do that.
If your email is hacked/malicious, and that's where your password reset requests from twitter, facebook, HN etc. are sent, it doesn't matter whether you reuse passwords or not; the attacker has the power to change them.
He could also intercept the login attempts (e.g. webmail login form => the password is typically sent in plain text to the server [regardless of transport security]), the user will never notice.