Probably my wording was wrong. I was thinking more of a system where the password itself was generated and stored on a hardware device. The user need not interact with any application, whatsoever, like 1Password or Lastpass to generate or store a password at all. Everything happens behind the scenes on the device. The user would be responsible only for keeping the hardware device safe.
This probably makes 2FA moot for some scenerios. For scenarios where losing the token is a real risk, you would implement 2FA.
I understood you, my point is that you are sacrificing significant security with a one-factor approach, especially if that one factor is a password! You're open to attacks where the password is exposed in between the keyboard and the requestor, attacks on the distant end system, as well as attacks on the password device itself. Passwords make it tricky to audit if they've been duplicated.
Use 2fa everywhere. It's cheap, easy, and significantly more effective.
Consider the following attacks which your suggestion provides no coverage for:
- Http downgrade (both SSLstrip and export-grade downgrade)
- Spear-phish
- Key-logger
- Spear-phish
- Shoulder-surf
- Spear-phish
- Evil maid (borrows device and compromises passwords)
I do not believe that spearphishing would not be prevented by a hardware token. The device would be responsible for authenticating the identity of the service being accessed. If the user can be fooled into handing over their hardware token, I do not see it far fetched that they will not be influenced to not hand over their 2FA token.
Again, if a hardware 2FA token can deal with key-loggers, so can a password token.
Why would someone be able to shoulder-surf a display-less password token? You log on to the website, insert the device and the website proceeds to authentication without revealing anything.
Evil maid is the only legitimate attack I can agree with.
>attacks on the distant end system, as well as attacks on the password device itself.
This is not something that a hardware 2FA token is also foolproof against.
>Passwords make it tricky to audit if they've been duplicated.
This is a valid point.
My point may not be applicable for super sensitive systems but for a lot of services it should be sufficient enough. I'm saying so because I'm having a hard time getting my family/friends to use a password manager (specifically 1Password). They do not see the need, find it additionally complex and are turned off by the subscription pricing (I'm paying for my family though!). Syncing is also hard. I was hoping that a pure hardware token would make it more convenient and a one time 20-40 USD price is more palatable than 60 USD every year.
Ha. Perfect. That is exactly what I was imagining. Apologies for the long conversation.
Do you have any idea why this is not popular? Is it too hard to implement or is it just that business's do not see security as something to invest a lot in?
Most major SaaS apps support it, the major hardware provider I see recommended is yubikey although Google makes one as well. See also U2f. It's super easy to implement, try it out for yourself in Flask.
Indeed. I spent 10 or 15 minutes trying to figure out if they are selling a physical device, like a usb 'key' or are just selling 2 factor authentication with mobile phones. And I'm still none the wiser. It's pages upon pages of buzzwords and nonsense.
2FA only helps if it's a 2-way authentication mechanism like U2F.
TOPT codes are completely phish-able using ridiculously easy to setup kits out there like CredSniper[0]. Set up a MITM proxy authentication site, get the user to live authenticate through the proxy, steal the session cookie, game over.
Some of the feedback that has come out of internal campaigns has been things like "I thought the URL looked weird, but the email said it was a beta site, and I got the Duo push notification for the second factor so it seemed legitimate."
That's the real danger in 2FA mechanisms outside of U2F: people believe it protects against phishing, and it absolutely does not.
This is dangerously untrue; while totp is clearly not as secure as a hardware token, it's much more secure than just username/password. It requires the adversary to do more work, and also provides more clues for the server that something phishy is going on. It's also much easier to sell to users, especially for free-but-critical services like webmail. You're not going to convince everyone to buy a $30 hardware token to protect their free Gmail account; meet your users where they are.
By all means, move towards a hardware-based 2fa setup. But don't let that prevent intermediate steps to improve security along the way.
Your example is also deeply flawed as it can be used to steal auth tokens for 2fa sites, even if they use Fido. Mitm is game over.
This probably makes 2FA moot for some scenerios. For scenarios where losing the token is a real risk, you would implement 2FA.