Once a year, I have to pay my renter's insurance bill. I get an email from Progressive, go to the website and find that I can't remember the password. I pull up the password manager and find Progressive-Homesite in the list, but the password is incorrect. Oh, I forgot, 4 months ago I needed to print proof of insurance while I wasn't home and had to reset the password to log in on the office computer. I reset the password again and pay my bill, saving the new password. The same basic scenario plays out every year for every infrequent account I have: insurance, internet, electricity.
So, if I never know what my password is, how am I really being authenticated? It comes down entirely to having access to my email address, but the process is tedious:
Click lost password/forgot password/trouble logging in
Enter email address
Wait for email to arrive, check spam, etc.
Click a link, where I create a new password, sometimes with confusing results:
Log in with the newly created password
These are effectively all low security websites. Contrast this with my bank, where if I were to forget my password, I would need to make a phone call and verify my identity in another way or visit a branch in person. That said, security questions, common personal details for verification, etc. are all pretty bad ways to verify someone's identity because they get reused and cannot be changed, so it's possible that the actual security in those processes is still quite low. For the sake of argument, however, let's classify this as a low security website because the password reset is automated and doesn't even offer the opportunity for another human to notice something may be amiss, in contrast with one where a person might stop and ask why someone is asking for access to my account but is unable to pronounce my last name consistently in conversation.
This process sucks. It's already established that if I have access to email, I can access anything that uses that email as a lost password address--we should cut out the middle man and use email directly to authenticate. Google already has a solution to this with Google Identity Platform, which is much faster to use, doesn't require me to store additional credentials, and easier to build and use correctly than homemade authentication systems might be (cf. Homesite requiring special characters in the password and tripping over the ones my random generator produced above). But Google isn't the only one that does this, and OpenID has been developed and deployed widely for authenticating users through third parties. If you don't like Google, you could use Facebook, or Twitter, or Steam. Just stop creating password-based logins. For the reboot of my blog I've used Google Identity Platform, and for the Dota 2 league I run, players sign in through Steam. So in both cases the login security is handled by companies with better security teams, and a data breach on my end also reveals no private information--the account names and IDs are public in both cases, after all, and I store no passwords or security questions.
At the end of the day, though, OpenID is somewhat inconsistently implemented, so most stable providers--the big names we can reasonably expect to continue to exist in five years--have unique-ish APIs for it, or in some cases (like Steam) don't really support OpenID and instead use OAuth with a basic permission to read account details. So currently, you end up needing to support each authentication provider separately, and the identity details they provide are not linked: you cannot programmatically tell that the same "person" operates both a twitter and facebook account, even if they wish to make that information public, without having them log in to both during the same session on your site.
Ideally, users could register themselves with a public key that they provide. Both RSA and ECC are standardized and have robust library support; plus they are already available on every client and server. Digital signature algorithms provide a means for a user to prove that they can access the private key associated with a public key. I know the HTTP spec currently supports client authentication, but I don't remember if it permits the use of unsigned certificates or if this varies by implementation. In this case, because the user is providing their public key at registration, the issuer doesn't need to be verified: we just need to see the same key again plus proof of ownership to authenticate.
Specialized applications, like the DoD's Common Access Card have already deployed this strategy and proven to be very successful, but there are challenges with a widespread deployment for a hardware security token, because people are very good at losing their tokens. For the CAC and other truly sensitive situations, the recovery procedure makes sense: you have to go in person and answer a lot of questions, but for my reddit account there's no need to travel to California if I lose my key or it is stolen. Nonetheless, it'd be nice if some keys could be recovered or replaced, which requires that the keys take advantage of existing public key infrastructure, but without requiring a central authority.
In particular, users should be able to federate their keys: use a master key to sign certificates for secondary keys. Then, authentication can be done by presenting a signed certificate, although no external certificate authorities have been involved: I sign my own secondary key to use on a mobile device, so that the master key for an identity does not need to be risked. Key revocation is more complicated, but a couple of options come to mind. (1) Since we are the masters of our own destiny, signed registration certificates could include a URL to check for related revocation status when the matching key is presented in the future. However, an attacker could disable this singular service to use the stolen key along with its identity chain. (2) Use a distributed revocation network that allows a master key to publish both the creation and (later, if necessary) the recovation of a secondary key. With a blockchain the history of a key is immutably documented, easy to consult by identity consumers, and not controlled by a central authority. There are, however, a lot of technical details to figure out there, and the best solution may be (3) require users to log in with a "more authoritative" key of some kind (for instance in a 3 tiered scheme the intermediate key in between the master and the daily key could be used for this) to discredit a lost/stolen key at affected services, with no networked or third party server checks.
Something like that is pretty far away, but for now, I'd just be happier if most services switched to identity providers rather than storing usernames and passwords. It's easier for end users, increases security, and reduces the damage of data breaches.