The hassle and delay is part of how it works. If there was a seamless catch all then it wouldn’t be feasible to make it secure.
Having a second physical factor, as much as it can be a hassle, is much better than any single factor.
Your password can be breached, brute forced, bypassed if there’s an issue somewhere.
Your biometrics can’t be changed so anything that breaks them (such as the breach of finger prints in databases, etc) makes them moot.
A single physical token can be stolen and/or potentially cloned by some attack in physical proximity (or breach of an upstream certificate authority)
But doing multiple of those at the same time. That’s inordinately much harder to do.
I will say the point/gist of the article is a good one. The variety of types some used here and others used there does make it a hassle to try to wrangle all the various accounts/logins. Especially in their corporate and managed deployment which isn’t saving passwords and has a explicit expiration of credential cache (all good things)
The hassle and delay is part of how it works. If there was a seamless catch all then it wouldn’t be feasible to make it secure.
Having a second physical factor, as much as it can be a hassle, is much better than any single factor.
Your password can be breached, brute forced, bypassed if there’s an issue somewhere.
Your biometrics can’t be changed so anything that breaks them (such as the breach of finger prints in databases, etc) makes them moot.
A single physical token can be stolen and/or potentially cloned by some attack in physical proximity (or breach of an upstream certificate authority)
But doing multiple of those at the same time. That’s inordinately much harder to do.
I will say the point/gist of the article is a good one. The variety of types some used here and others used there does make it a hassle to try to wrangle all the various accounts/logins. Especially in their corporate and managed deployment which isn’t saving passwords and has a explicit expiration of credential cache (all good things)