User authentication is among common awkward things about computing: there are many incompatible methods, and every user has to deal with those.
For sensible digital identity guidelines, see NIST SP 800-63B. Most commercial and government services do not follow those, while inventing or using inappropriate rules, making passphrases harder to remember and easier to bruteforce. While below are notes and musings on relevant technologies.
There are plenty of APIs (PAM, SASL, LDAP, GSSAPI, etc), specialised protocols (Kerberos, RADIUS, SRP, etc), protocols that can be used for that (SSH, TLS, IPsec, etc), occasional additional authentication (sudo), various protocol-specific ones, and people keep making custom ones (that's most popular on the web, I guess). It is nice that there is a choice, and a vulnerability in one protocol (or in its commonly used implementation) wouldn't compromise about everything, but it is also quite a mess.
Users often fail to remember and enter their passwords (be that
for password-based authentication or for encrypted keys), so for
them there are netrc and secret service API, with the former
taking bits of private data for search (as does that
newer pass thing), and the latter being another
bloated and awkward dbus-based freedesktop project. There also
are ssh-agent and gpg-agent, just encrypted (or plain text in
many cases, I guess) files, various password managers (which may
or may not use the standard methods), plan 9's factotum, and
poor wheel reinvention for websites (in-browser password
managers, web-based ones, cookies, etc).
This is without taking into account distributed systems, access delegation, multi-factor authentication, and use of multiple devices with synchronisation of credentials between them.
The protocol and software support for all these tends to be messy too, complicating the usage further.
The Internet Threat Model (RFC 3552) is implied here, as usual for Internet protocols: the adversaries are scammers/businesses/governments, they can have near complete access to everything but endpoints, and we don't want any of their attacks to be successful.
SCRAM is a fine password-based challenge-response authentication mechanism. It is required and widely supported in XMPP, but may be tricky for other purposes: software--such as mail clients--does not always handle it, the server side may require plaintext passwords (especially if non-SCRAM-specific system-wide hashing is used for passwords).
Below is a sample dovecot SASL setup aiming SCRAM, similar
to dovecot's CRAM-MD5 HowTo. Password database file owner should
be set to dovecot, userdb should be
set, and hashes could be generated with doveadm pw -s
scram-sha-1.
auth_mechanisms = scram-sha-1
passdb {
driver = passwd-file
args = scheme=scram-sha-1 /etc/dovecot/scram-sha-1.pwd
}
userdb {
driver = passwd
}
As of 2019, emacs's smtpmail library only supported
CRAM-MD5 (though sasl.el supports more); a
workaround is to configure a local SMTP server relaying through
a remote one; with postfix (which does support SCRAM), though
with a password stored as plaintext:
# http://www.postfix.org/SASL_README.html#client_sasl smtp_sasl_auth_enable = yes smtp_tls_security_level = encrypt smtp_sasl_tls_security_options = noanonymous relayhost = [example.com] # Alternative form: # relayhost = [mail.isp.example]:submission smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
Having to deal with that, on both server and client, is not great though, especially if there are multiple users. And perhaps it is not even worth the effort if TLS is required.
Time-bassed one-time password (or "HMAC-based" one, HOTP) is an interesting approach, but software support is bad, and there is still a shared secret, making it rather like SCRAM, but with time instead of a server-generated challenge. It usually implies that the user keeps their copy of the secret on a separate device though, making is a bit easier to use with time than with SCRAM challenges, and potentially limiting the impact of compromise of one of the devices (especially if it is just one of the authentication factors). Though when it comes to multi-factor authentication, it is still better than SMS; OATH is supported fairly widely by 2022.
Asymmetric cryptography is convenient and versatile, though relatively complicated (both the algorithms and the management/usage by inexperienced computer users), common algorithms are vulnerable against quantum computers, and P≠NP is not proven (as of 2022), either.
Apart from storing a public key (or its fingerprint) on a server, one may rely on client certificates. In case of SSH, options/permissions can be set along with logins/principals in the certificate itself.
Beyond shell access on its own, SSH is handy and commonly used for DVCS (e.g., git over ssh), file transfer (e.g., rsync over ssh), proxying. All those rather easily reuse SSH's encryption and authentication, which is usually key-based, perhaps the best out of commonly used ones (though can be configured to be password-based, multi-factor, etc).
An email setup using only SSH connections/authentication is described in my Email note, along with its drawbacks.
Client authentication can be used with TLS, sometimes via SASL EXTERNAL method. As SSH, it's not strictly public-key (there's TLS-PSK, for instance), but primarily used as such. Not widely supported or used for client authentication, I've only tried it with XMPP. No handy common tools like ssh-agent and gpg-agent.
Smart cards seem handy and secure for key-based authentication
(when it's available; also usable for TOTP), though the
situation with ECDSA support there is unclear, as well as the
standards themselves. While OpenPGP includes ECDSA since 2012,
and SSH includes ECDSA since 2011, apparently some smart cards
(e.g., Yubikey, the website of which is not very informative, or
the technical information is just well-hidden there) don't
handle it. As GnuPG's source code suggests and
doc/gnupg-card-architecture.pdf pictures, software talks to
USB smart cards via CCID (see CCID specification), with ISO/IEC 7816 on
top of it. The cryptographic functions seem to be defined
in ISO/IEC 7816 part 8, but it costs $165 (+ time and risks of dealing with
purchasing on their semi-broken website), with no publically available
copies in sight, so I didn't check further. Paywalled standards are
frustrating.
Biometrics have an advantage of being easy to use, with no need to remember or carry anything. But the biometrics issues outweigh that in most cases, even for using them as just one of the factors.
Basic access authentication is indeed very basic, but simple and usable with TLS. Yet most of the time web developers (or their clients) feel like they should reinvent it in order to be able to reinvent the UI, so they make something comparable, but custom (hence not supported by generic HTTP clients), turning the OSI layers inside out even further. The attempts to add custom key-based authentication were ugly, but now there is a W3 web authentication standard, which is just a JS API to work with authenticators and doesn't have much to do with HTTP authentication, or with interlinked hypertext documents.
It's a trainwreck stretched out for decades; doesn't seem like there will be proper HTTP authentication anytime soon.
In local systems it is often simpler to rely on kernel-controlled ACLs (e.g., Unix domain sockets with properly set permissions instead of TCP and authentication on top), maybe host-based authentication (especially with IPsec, other VPNs, or in a local network while controlling the routers and physical connections), possibly just on physical connections -- eliminating cryptography, secrets, and all the issues surrounding them altogether. Just as with private information in general, the best way to avoid compromising it is to not store it.
Similarly, identity providers (and "single sign-on") may help at least to reduce the number of credentials and their usage in larger networks, including the Internet. Though they come with reliability and trust issues, the standards keep appearing seemingly at a higher rate than adoption of those, and functionality other than decentralized authentication is emphasized sometimes (e.g., access delegation with OAuth, and Kerberos includes service authorization step too: handy for account management within an organization, but perhaps less useful for unrelated Internet services).