Google's TOTP is not as good as it could be being HMAC-SHA1 of a symmetric secret and Unix epoch. WebAuthn with a hardware device is less prone to losing and compromising secrets.
I use all 2FAs allowed.
Tangent on passwords. What the world needs is a path to automated, interoperable secret management in 3-4 RFCs:
User-operable, standardized password change REST API that:
0. Sends a session token/nonce
1. Describe the password policy declaratively and precisely, to be validated client-side with boilerplate client code
2. Offer a list of supported PBKDFs and their required and allowed parameter values
3. Includes both client- and server-side PBKDF hashing with minimum values for a given risk type AND adjusted with the "inflationary" Moore's Law costs of tech resources (CPU, GPU, RAM, ASIC, FPGA, QC) over time
---> This would then permit a password manager app to automatically change every password perhaps every day. I'm thinking the future should be like this but use user certificates as a primary AA mechanism and passwords as a break-glass-backup.
I use all 2FAs allowed.
Tangent on passwords. What the world needs is a path to automated, interoperable secret management in 3-4 RFCs:
User-operable, standardized password change REST API that:
0. Sends a session token/nonce
1. Describe the password policy declaratively and precisely, to be validated client-side with boilerplate client code
2. Offer a list of supported PBKDFs and their required and allowed parameter values
3. Includes both client- and server-side PBKDF hashing with minimum values for a given risk type AND adjusted with the "inflationary" Moore's Law costs of tech resources (CPU, GPU, RAM, ASIC, FPGA, QC) over time
---> This would then permit a password manager app to automatically change every password perhaps every day. I'm thinking the future should be like this but use user certificates as a primary AA mechanism and passwords as a break-glass-backup.