Hacker News Reader

Comment by mattferderer | Hacker News Reader

Your dislike is probably more due to the configuration setup in your instance.

As others pointed out, you can require matching a pin in the app with the one on the screen.

With many of the MFA apps I have tied to Microsoft products, they typically store a session expiration where they don't have me re-authenticate with MFA until the next day.

I've worked with many enterprises where the security group implements awful policies in an attempt to lock things down but instead create more risk by creating to much burden on employees which results in them finding clever hacks around the security.

Just guessing, but probably not the tool here. Though they maybe could improve their defaults, docs or UI/UX.

View on HN

> more due to the configuration setup in your instance

The obvious question here is, why does it have a configuration that allows an accidental or absent-minded employee to let in a hacker? Other authentication apps such as Symantec VIP does not use notifications, so the employee does not respond to a notification, instead he proactively starts the app to get a numeric code. Less convenient than saying Yes to a notification, but more secure.

I work with a few older employees. Its takes them longer to focus on the words on the screen and to read them (presbyopia happens). It takes longer to get into an app and read a code out. By the time they are ready the code is already changing in the app. It is much easier for them to touch an acknowledgement. We want security but we do not want to make security an impossible barrier for folks that need a little extra time (for whatever reason).

The code is valid for another full minute, typically, after it's rotated for a new one. This isn't much of a valid reason to prefer notification-based 2FA.

It is not obvious to everyone that a code may still be valid after its gone from your screen. You cannot use the first 3 digits from one code and the last 3 from another, so you start over when you don't have all 6 digits before the code changes on you.

Different strokes for different folks. I care to have folks be successful.

This sounds like an education issue; if you were to say "wait until the code changes, then go for it", they have thirty seconds to read and type six digits.

If this still doesn't work for them, perhaps a hardware token they can tap might be a better solution.

TBF the code still being valid doesn’t help much if the user hasn’t memorized and/or finished typing it all.

Sitting next to some family members, they really can’t remember more than one or two letters at a time, and will peck and hunt each of it. Except if they were typing the last digit, the code disappearing from screen is basically the end of it for them.

In cases like these, I tell them "wait until the code changes, then go for it", so that they have thirty full seconds to read and type six digits.

If this still doesn't work for them, perhaps a hardware token they can tap might be a better solution.

There certainly are people for whom "a full minute" is not sufficient - accessibility is important.

If you were to tell them "wait until the code changes, then go for it", they would have thirty seconds to read and type six digits.

If this still doesn't work for them, perhaps a hardware token they can tap might be a better solution.

Semi related: apps which display TOTP tokens should start their timer when the user opens the app (so the code doesn't change 5s after opening the app). The server in the backend is checking the previous+next N tokens anyways since the server needs to account for clocks not being 100% synchronized.

Unless the authenticator app was already open, in which case skipping to the next token should be possible on demand.

Alternatively, we just found the semantic use case for the <marquee> tag: a properly calibrated scrolling ticker would give readers the clear option (regardless of initial phase) to start reading the newest token or continue reading an older one, as the ideal selection may evolve unexpectedly based on distractions.

The trade off here is that many non tech organisations make MFA at all a political difficulty. I've sat in on several meetings about how we can reduce the difficulty of using Microsoft MFA, with people talking about preinstalling it on people's phones and of course, "let's do away with MFA" comes up quite often.

Many of those orgs looked into RSA tokens in years gone by. The only reason that MS auth got through when those devices were summarily rejected from ever being used, was the convenience.

The security industry needs to be careful here. Too much "Microsoft MFA is bad" and I'm certain many companies will simply revert to password-only, in much the same experience we had with SMS based MFA being bad and as such, web apps going live that simply didn't support MFA.

The problem with giving options regarding security is that sometimes the people who are responsible for setting up those, forget about "convenience versus security", or they get pressured by other groups to "forget" about that balance, and makes a lapse of judgement.

We could, by laws and software, enforce a certain standard of security for organizations. The question is how liable you should be for that. Would have to consider many variables like size of company, importance of information and such.

Reply on news.ycombinator.com