What do we do when passwords are not secure anymore?

Question

During an intense shower thought train. I began to think about a hypothetical world where passwords were no longer a safe way of protecting systems. Edit: W̶h̶e̶t̶h̶e̶r̶ ̶c̶o̶m̶p̶u̶t̶e̶r̶s̶ ̶b̶e̶c̶a̶m̶e̶ ̶t̶o̶o̶ ̶p̶o̶w̶e̶r̶f̶u̶l̶ ̶a̶n̶d̶ ̶c̶o̶u̶l̶d̶ ̶b̶r̶u̶t̶e̶ ̶f̶o̶r̶c̶e̶ ̶a̶n̶y̶t̶h̶i̶n̶g̶,̶ ̶o̶r̶ ̶s̶o̶m̶e̶ ̶m̶a̶g̶i̶c̶ ̶p̶r̶o̶g̶r̶a̶m̶ ̶w̶a̶s̶ ̶r̶e̶l̶e̶a̶s̶e̶d̶ ̶d̶o̶e̶s̶n̶'̶t̶ ̶m̶a̶t̶t̶e̶r̶ ̶h̶e̶r̶e̶.̶ (Let's not assume anything other than the 'fact' that conventional passwords cannot be used to secure systems)

If passwords where out of the picture, how would the general public go about securing their computers and online accounts?

Answer 1

We have no idea - yet.

Because passwords are insecure because of a combination of factors.

1. People choose bad (with only X bits of entropy) passwords.
2. Companies have bad password policy.
3. Passwords are stored in plaintext.
4. Password hashes are created with "bad" cryptographic hash functions.

All of these factors are theoretically "solvable".

1. We could tell people to use stronger passwords.
2. We could tell companies to have better password policies in place.
3. We could theoretically fine companies that store passwords in plaintext or when they create "easy" to brute force password hashes.

We (and a lot of other people) have been doing this for a long time and nothing or maybe little has changed. So your question is absolutely valid and has been asked before many times. The problem is, nobody has a good solution yet.

Why is that?
There are several fundamental problems: creation, storage, recreation.

Every factor that is used for authentication a) has to be created by something or someone, b) has to be stored on the client side (to transmit it to the server) and server side (to prove that it is correct) and c) it has to be possible to recreate a new one if it is lost.

All "new" proposals have at least a weakness in one of these categories. Take biometrics for instance:

1. creation: relatively easy, almost everybody has a fingerprint/veins/a face
2. storage (client): easy, on your body
3. storage (server): easy, either plaintext (several pictures are stored) or a hash is derived (both these solutions are suboptimal)
4. recreation if lost on the server side: not possible

There are other fundamental problems like usability, factor reuse, privacy etc. You can take every new proposal that is in the following list and is the topic of authentication research today and it will fail to solve at least one of the named problems.

What other solutions are discussed?
These: More biometrics (heart rate, voice, walking pattern), n-factor authentication, OTP everywhere, web of trust-like schemes, trust score system (scary!) and others.

In conclusion: We do not know what will come next, but there is a lot of research going on, because not only scientists but also companies are getting tired with all the problems that good old passwords have.

Answer 2

There are a few options, depending on what level of "magic" we are talking about. Bear in mind that some things, like simple brute-force attacks, are still possible to protect against with password-based systems regardless of how fast the attacking system is, unless its attempts are indistinguishable from those of a real user's login attempts (and thus cannot be filtered out using CAPTCHAs, timing, IP blocks, etc.), and even then all they can do is force services to disable password login out of fear of denial-of-service attacks. My password for this site is sufficiently high-entropy that if it takes StackExchange's servers only one microsecond to verify it - which would imply terrible things about the quality of their password hashing - you still couldn't brute-force it this millennium.

Anyhow, a handful of approaches already sometimes used today, presented in no particular order:

• TLS Client certificates: Established technology where, for each user, a server has a public key (generally generated by the client - that is, the user) stored in a certificate that identifies the user, the user has the corresponding private key, and in order to complete the TLS handshake the TLS client must prove to the server that it has the key to that cert (just as the server proves to the client that it has the key to its cert). Requires that the user distribute their keys to all of their devices, but in theory this is doable (all major mobile and desktop browsers already support this).
• Other forms of public-key authentication: There exist systems, such as SSH, which use public-key cryptography in a manner similar to TLS with client certificates, but do not actually use TLS. The private keys (as with TLS private keys, actually) are usually encrypted with a key-derived password, but that is just to slow down an attacker if one manages to obtain the key; the key's primary protection is that you never, ever let anybody else see it or use it, and the encryption (and thus the password) are entirely optional.
• FIDO U2F or similar: Using hardware "security keys" that communicate with your device over USB or NFC, combined with asymmetric encryption, you can provide evidence of your identity. While U2F is (as its name indicates) meant to be a second factor of authentication, there is also the WebAuthn standard, which grew from the same group and is implemented in some of the same hardware tokens available today, which is explicitly suitable for use as a single factor.
• Smart Cards: These chip-on-a-card devices are already widely used for proving identity - cell phone SIM cards are compact Smart Cards, for example, as are the "chips" in chip-enhanced credit or debit cards - and have also been supported for logging into Windows (and probably other OSes) for over a decade.
• Biometrics: While not ideal for protecting a secret (such as a disk encryption key) or for transmitting over a network, biometrics (most commonly fingerprints, but also things like iris scans) have been used for local authentication for decades, and most high-end laptops, tablets, and smartphones already support this.
• Key file on portable media: For systems like disk encryption and whatnot where a securely-stored secret is needed, the main alternative to passwords is key files. A key file is just what it sounds like - a cryptographic key stored in a file on a flashdrive or similar devise - and to unlock a machine you plug in the drive. The drive is only plugged in while authenticating, and lives on your physical keychain along with your house key, etc. With mobile devices increasingly supporting USB mass storage through their charging ports (especially those that use USB-C), this is viable even for mobile devices.