SpaethCo

> 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.)

TOTP or SMS, it's just another text password you're entering in that's fully phishable.

TOTP just "feels" more secure.

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.

So if a site is compromised and requires a password rotation, do you just never use that site again?

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.

This is technically true, but the most likely scenarios that result in the discovery of your secret key (128bits of entropy) + master password (?? additional bits) involve things like a device compromise. If your machine is compromised, you’re probably already exposed to things like session cookie stealing. At that point your attack surface is already blown wide open.

The biggest thing 2FA protects against is credential stuffing. If you’re using a password manager and have high entropy site-unique passwords, the additional entropy by TOTP is mostly moot anyway.

The backup function is moving to Finder before iTunes disappears entirely.

True, but these days you can disable iCloud backups without giving up all that much. (it also re-keys Messages in iCloud when you turn off backups)

Keychain, messages, and health data are all E2E encrypted and synced to iCloud.

By not doing iCloud backups, you're basically only giving up backups of app icon placement, home/lock screen background images, app data that isn't otherwise synced via iCloud or the app's dedicated sync service, and a handful of phone settings.

You can opt for the occasional iTunes backup to preserve those infrequently changing elements on the phone, and not have to compromise on recovery point for more important data like messages and security creds since all of that is synced in real time.

They offer ways to export your media via the Google Photos API, but you only get the "high quality compressed" version (even if you are storing in original quality) and it strips the location data out of the EXIF tags.

Unless I'm missing something, it looks like the only way to do a full quality bulk export now is using Takeout.

In all honesty, it's probably not worth worrying about. The implementation of 2FA you're referring to here is just adding a 2nd secret, with a small twist of having time component.

There are very few scenarios where your (high entropy) password would be compromised in a way that wouldn't also lead to the discovery of at least 1 functional 2FA code.

1) Website is breached. If they can get the account password hashes, chances are they're going to get the TOTP seeds as well.

2) You're phished. Your attacker passes through your credentials (scraping the password along the way), and they get a functional session token. With most services, you can turn off 2FA just by reconfirming the account password.

3) Your password manager is breached. 'nuff said.

The push behind 2FA isn't so much because high entropy passwords are vulnerable (except in a phishing context, but there TOTP is equally vulnerable) -- the momentum behind 2FA is because we can't convince people to stop using '123456' as a password.