alt Hacker NewsNot only SMS 2FA, but in the past maybe couple years, many sites have been making their logins worse in many ways.
For example, I'm actually liking Walmart.com more than Amazon in some ways lately, but logging into Walmart.com takes minutes while I wait for the 2FA after I already password authenticate. So Amazon wins all the casual browsing and impulse sales, and by the time I do log in to Walmart.com, it's only because I know I want to order something from there specifically, and it's already feeling tedious.
Some off-the-cuff suggestions, since the worsening authentication experience really bugs me:
1. Present the email/username and password fields simultaneously, so the browsers like Firefox can fill out both fields. (A lot of site have started showing only the email/username to start, and also making that rely on non-login form field filling. And only after you type in your admin/email, because you don't form autofill in general, does it present
2. After user opts to authenticate with a password rather than SMS/email code, let them in, unless you're something like a bank or a medical provider. (Don't then make them do the SMS/email code anyway.)
3. If your mega online store handles HIPAA-sensitive data for some small percentage of visits, and you need 2FA for that, maybe only do the 2FA to upgrade the authentication confidence for session. (Or maybe the more sensitive data is on a different backend anyway, so as not to encumber all the developers implementing Wheaties logistics, with all the additional protections that are needed for medical records, nor to add additional weak links leading to leaks.)
4. When SMS/email 2FA is really necessary, send it immediately and reliably, and make it copy&pasteable. (Sometimes I wait minutes, and other times it doesn't come through at all. And I've even gotten email ones where competent-user text-selection picks up whitespace somehow, or even a weird unprintable Unicode character, which breaks the code entry when pasted.)
5. Those buttons to authenticate a variety of other sites are needlessly leaking information, and creating additional ways to compromise the account. (That's what you do if you want to reduce friction to first visits to your site, for which people aren't interested enough to create a password to use -- but not for logins from recurring customers.)
6. Don't prompt for "remember this browser?", and don't otherwise rely on the persistent tracking data deposited on the user's browser, across explicit authentication sessions, such as to decide whether to 2FA. For one reason, those persistent data mechanisms are overwhelmingly for shady abuse by the adtech/surveillance industry in shady ways, and are frequently cleared by privacy-conscious users. Any why is a bank, for example, complicating the UI, to ask ordinary users whether to lower their authentication security on this device, and expecting much sense out of that at all. Keep it simpler, more secure, and more responsible or respectable.
7. If you must support 2FA, make TOTP an option. And not TOTP-incompatible codes that requires installing your app, or that depends on some oddball third-party proprietary authenticator app/fob that seemed like a good idea at the time but is not a reason not to support TOTP. (You can still grandparent in the legacy proprietary 2FA, for those long-time users who've been using it, and be clever about not complicating the UI for those those dwindling users, nor for the increasing users using the more current open standard.)
Putting the username and password fields together has other advantages than you mentioned. It means no additional requests (or JavaScripts or CSS) are required between entering the username and password, and it also makes it more difficult for attackers to guess usernames.
I would want to see X.509 client authentication used more often. It has many advantages, such as:
- Cookies and JavaScripts are not required.
- The credentials cannot be stolen. (With TOTP, the credentials can be stolen for one minute. I have been told that some implementations only allow thirty seconds, but that can cause problems with legitimate authentication if the clock is not precisely synchronized.)
- It does not require a web browser; it can also be used for command-line access as well (rather than using API keys, which are really just another kind of passwords, with the same problems).
- It is independent of HTTPS; it can be used with any protocol that uses TLS (which includes HTTPS but also others). Therefore you can authenticate with multiple protocols if wanted.
- The private key can be passworded for additional security, if desired. (This means that it can already be like a kind of 2FA, but on the client side instead of the server.) This password is never sent to the server.
- If permitted, the keys can be used to sign data which is distributed, allowing other receivers to verify it. This is true of using public/private keys in general, even without X.509. (If X.509 is used, the keys might or might not match those used with X.509, and this might be mentioned in extensions inside of the certificate.)
- They can be used to allow using credentials from one service to log in to a different service if the user intends to do so (and the service allows it, which it should not be required to do). No authentication server is needed for this, since the necessary information is included within the certificate itself. (The buttons to authenticate a variety of other sites, that you mention, also will be unnecessary.)
- Partial or full delegation of authorization is possible (if the service that you are authenticating with allows it). Each certificate in the chain can include an extension specifying the permissions, and the certificate chain can be verified that each each one has a (not necessarily proper) subset of the permissions granted to the issuer certificate.
- You could have an intermediate issuer certificate to fully delegate authorization to yourself (as mentioned above), where the corresponding issuer private key is stored on a separate computer that is not connected to the internet, in addition to being passworded, for additional security, if this is desirable. If the certificate that you are using to authenticate with the service is compromised, you can create a new one with a new key and revoke the old one.
- Some services may allow you to authenticate with any OpenID identity provider, including making up your own. X.509 is a better way to do something similar; if self-signed certificates are allowed, then anyone can make up their own, without requiring to set up an authentication server. OpenID also allows additional information to be optionally provided, and this is also possible with X.509 (without the additional information being limited to a fixed set of fields or being limited to Unicode). Also, OpenID requires a web browser but X.509 doesn't require a web browser.
- DER is a better format than JSON, in my opinion.
(However, I also think that TLS should not be mandatory for read-only access to public data. TLS should still be allowed for read-only public access though; it should not prohibit it. The use of X.509 client authentication means that you can't authenticate with unencrypted connections by accident, anyways.)
It would still be possible to support 2FA if this is desired because some users prefer it (and when doing so, it should do the things you mention, since they would avoid some of the problems with existing systems), but should not be required.