> Yes, it can be phished if you fall for that, but it removes several attack vectors.
How was the first factor (the password) compromised?
Assuming the user is using site-unique passwords, in 99% of cases where an attacker obtains a functional password they can get at least one TOTP code or the seed in the same manner. (ie, if I can steal your password DB, odds are pretty good for me stealing your TOTP seed DB as well.)
The outcome of a single successful authentication is a longer-lived session cookie. Once an attacker has that they can reset your creds (usually just requiring re-entering the password) and the account is theirs.
IMO, the only 2nd factor that matters are those that mutually authenticate like PassKeys / FIDO keys.
That's assuming your attacker already has your password, or the service allows SMS password reset. (thus negating the second factor. Essentially SMS becomes the only factor.)
Those margins are misleading because they're _multi_ service operators, and accounting standards require that you can only list direct costs.
Revenue is easy: how much did you take in for video? phone? Internet access?
Costs are harder because you can only include business line direct costs. Since the cable plant is used by voice, video and data services it's not a direct cost of any of them. Same thing with the service vehicle fleet, call centers, etc. Most things get saddled in "administration" categories and obscure the true cost of providing the service. As a company overall, their margins been hovering around 8-12%.
> Integrating a password manager with a browser is too fragile and risky way of using both. It is best to have them fully separated so they can't communicate. They should communicate exclusively via the user.
Passwords are about proving identity. Using high entropy passwords for greater confidence of user identity is only part of the equation, the user needs to be able to identify the validity of the service as well.
The greatest benefit of an autofill enabled password manager is it handles the task of URL validation before offering up credentials. When you split up that function, now it's back to relying on humans to get everything right on verifying credentials get submitted only to the intended service.
All the encryption happens client-side. For this to be a problem you not only have to gain access to the blobs stored on their service, but you also have to be able to decrypt them.
I expect they probably pay more attention to abnormal access than most self-hosted users would as well, so you'd actually know about a data leak faster so you could rotate your passwords.
How was the first factor (the password) compromised?
Assuming the user is using site-unique passwords, in 99% of cases where an attacker obtains a functional password they can get at least one TOTP code or the seed in the same manner. (ie, if I can steal your password DB, odds are pretty good for me stealing your TOTP seed DB as well.)
The outcome of a single successful authentication is a longer-lived session cookie. Once an attacker has that they can reset your creds (usually just requiring re-entering the password) and the account is theirs.
IMO, the only 2nd factor that matters are those that mutually authenticate like PassKeys / FIDO keys.