Hacker News Reader

Comment by overeater | Hacker News Reader

I don't understand why authentication usually requires you to type in some 6-digit number from your phone. From an ideal user experience point of view, why not just pop up a dialog on your phone, wait 1 second (to prevent accidental taps), show "decline" or "approve" options, and that triggers the authentication to proceed? This seems like an experience that Apple would design.

Even better, use a thumbprint to authorize on the phone, to add one more layer of security. Then you hit the trifecta of verifying 1) something you know (the password entered on the website), 2) something you own (your phone), and 3) something about you (your fingerprint).

View on HN

Push notification 2FA certainly has some UX benefits over manually entering a TOTP, but there are documented cases of attackers gaining access by triggering the 2nd factor push and a user dutifully pressing "approve". Office365 is an especially bad vector for this risk as it prompts for auth throughout the day at seemingly random intervals while using o365 services. Users are trained to hit accept to keep going even if there isn't a password entry dialog that obviously triggered the 2nd factor ask.

WebAuthN makes this a moot point though. All the auth is handled under the hood. There is no password or TOTP code to enter and yet in the right setup can be 2FA with minimal user interaction. The keys are stored resident on your device (something you have) and there is interaction to unlock them (finger/are or PIN/know). Best of all it's unphishable since the keys are unique per domain, so lookalike domains won't work.

Google actually has this implemented for signing into Google with desktop Chrome and Android, but I'm not sure it's standardized yet. Ideally Google will make this mechanism usable with all WebAuthn-supporting sites.

(It seems like there's two different forms of this that Google has implemented. One form is done simply: when you log into Google, Google tells your phone to show a prompt, but this form is still phishable, because if you're using a phishing site while an attacker is proxying your login, they could still trigger it. The other form involves desktop Chrome talking over Bluetooth to your phone to verify what domain you're looking at. This method is immune to phishing domains like other WebAuthn authentication methods so presumably this is what they'd try to standardize. It does involve multiple moving parts so it's not too surprising it's not standardized yet.)

> From an ideal user experience point of view, why not just pop up a dialog on your phone, wait 1 second (to prevent accidental taps), show "decline" or "approve" options, and that triggers the authentication to proceed?

Because it's insecure. Because you as a user don't know which login attempt the prompt is for. This is especially bad when combined with applications with persistent connections that occasionally decide they need to re-up their credentials. It allows for attacks where you just spam someone with login requests until they either misclick or just get fed up.

Those seem trivially correctable?

Seems to me the MFA app could, with the approve/deny prompt, display the application the request is for.

If you delay the request of the MFA until after the password has been verified, then even a single "unexpected" MFA would be an indicator of the password having been compromised.

… and if it's insecure, well … MS is using that flow.

Simply displaying the application is insufficient; the spamming issue would remain as they would spam the most common app that asks for auth at random intervals. An actual fix would involve displaying a randomly generated sequence in the app and in the notification and training users to check, but there would still be plenty of people who would just say yes without thinking.

MS has that flow as an option and it can be disabled. In my job life I've already heard from regulators who want it off.

The actual fix is to move to webauthn where the user experience is excellent and the security is much stronger than any password flow could ever be no matter what stuff you pile on top.

For now it is mostly just that "pull-based" TOTP is cheaper/easier and works in more "offline" or "partially-disconnected" scenarios. Your phone and the website only have to directly "communicate" once: that QR code to bootstrap the secret key. After that all of the math is independent: the math to generate codes is done entirely on the phone and the math to verify it is done entirely on the website.

There is a growing support for "Push" style authorization tools that more directly communicate between the devices. Up to now the tools have been mostly vendor-specific. Google has push notification authorization in the Google ecosystem. Apple has push notification authorization in the Apple ecosystem. Microsoft has push notification authorization the Microsoft ecosystem. The growing WebAuthn standards (for which the linked post is a Guide to working with them) are exactly the sorts of standards that are being built to increase inter-operability between vendors and trying to make "push" style authorization cheaper/easier/more ubiquitous on the web. (Those standards aren't 100% there yet for multi-vendor interoperability as other comments in these threads accurately nitpick, but this is still a giant step forward in that direction.)

Also, if your TOTP Authenticator app isn't already using your device's fingerprint or Face ID biometric locks, consider moving to a TOTP app that does. Most of the major ones do, exactly for that "trifecta" reason of layered security.

Google does this for their accounts and Twilio/Authy has a solution for it, but I find it to be pretty expensive.

https://www.twilio.com/authy/features/push

The 6 digit number is TOTP, it's an RFC and has nothing to do with webauthn.

Webauthn is basically what you are asking for (thumbprint). It's basically Apple's TouchID brought across platforms and across the Web.

I'm not an expert in authentication but afaik TOTP (and HOTP) work completely offline. That means you could store your keys on a device that doesn't have internet access. On that device you can do whatever you want. Some TOTP apps allow you to lock your keys with an additional passphrase or a biometric factor.

From my (maybe naive) POV as a user I tend to agree, it would be nice to have a standard for push-based authentication so that I can actually see when someone else has made it past the password prompt. Although email notifications would largely solve that problem (if more websites used them).

I"m not seeing a huge benefit of the personal device being offline, while you're trying to log into an online service. But let's say there was a need for that, what about using bluetooth or wifi direct to push to the device?

Why? We've already got better standards, there's no need to add complexity to TOTP.

Like I said, I don't know the standards, so I don't know the authors' intentions. But there are actually specialized devices which do nothing but generate TOTP tokens, so that seems to be a use case. (The keys don't have to be on a phone or in a particular app.)

A push token usually means you're utilizing a service such as Okta, RSA, Symantec VIP, etc. whereas RFC TOTP can just be managed locally and the user can choose a 2FA app of their liking.

> I don't understand why authentication usually requires you to type in some 6-digit number from your phone.

Because it proves that the user logging in is in control of a device that they've linked to the account. When you add an account to whatever app you're using (Google Authenticator, Authy, etc.) what it's actually doing is receiving a cryptographic key that it uses to generate the 6 digit code based on the current time. Without that key, the proper 6 digit code can't be generated.

I think the procedure I described also can do this, but the 6-digit code is sent in the background. I don't see why a human has to physically write out 6 digits from phone to computer, instead of it just happening automatically.

I main difference here is usability. The current process is going into an app, finding+choosing the website from a list, tapping that website, manually copying from one screen to another, checking that you copied the digits correctly, then confirming. This is stressful and takes about a minute. A process where you just confirm a dialog, or use your fingerprint takes 2 seconds, and doesn't require the mental effort of memorizing and writing out 6 digits. If the people working on security can't see the enormous difference between the two workflows, then this is hopeless.

It's the same issue that plagues the security-minded people who think regular users will go around copying and storing each others' PGP keys.

Okta already supports what you suggest.

The problem, IMO, is the lack of standardization. Okta has its own implementation, Google has its own implementation, etc. TOTPs in stark contrast are pretty universal and not that much harder to deal with, provided you have some way to backup and recover your TOTP keys (this is Authy's selling point, for example).

The main value-add is to replace passwords entirely.

The Microsoft authenticator does exactly that.

It is still a phone-based fenced authentication system, so it still sucks. But not due to usability.

Authenticating to Google services while owning an Android phone works exactly like that.

Reply on news.ycombinator.com