Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Regardless of what any company/product doing specifically, I do not think it is unreasonable to require a fresh token out of an authenticator if you wish to remove said authenticator from your account.

Hypothetically, what if you had 2 forms of 2nd factor to access your account? One is a passphrase you receive via SMS and another is a hardware token you possess. Should you be able to remove the hardware token based on an SMS authenticator response? Should you be able to remove both factors if you have a current session that was authorized at some prior time via one of the factors?

I think the answers boil down to just how secure the application needs to be. If you have 2FA protection, but any authorized session is valid for a year, is this actually providing any protection? I have zero problems with the idea of being required to 2FA into my brokerage app every time I want to use it. I feel like the equation can be partially reduced to:

"If your app is not so security critical that any prior-authorized session up to 30+ days can arbitrarily remove 2FA tokens, then why have 2FA in the first place?"

The amount of time a 2FA-authorized session is valid for seems to be the hangup for me. If its really short (<24 hours), then I would say don't require a reauth to remove a token. But, if a session can be valid for months, then it is much more likely that a bad person has your laptop and wants to maliciously remove your token. The longer the session can be valid for, the more a 2FA re-auth seems to be necessary to ensure a bad actor is not involved.

But, I recognize that there are so many UX considerations when talking about massive scale products that Google puts out. Supporting mandatory 2FA re-auth for token removal would probably be an extremely expensive process, as manual verification with live persons would be required to recover accounts with lost tokens.





Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: