SMS 2FA is a code that you're entering from a phone number. The "risk" is that your phone number can be ported without your permission, and then someone else can get the code.
TOTP is more secure because it isn't tied to a phone number. You're right that it's still phishable but that's not the point.
In both cases, the primary benefit to the general population is to have a rotating credential that, if one website is hacked, is useless on another website.
No, TOTP is far more secure because it has no dependence on a third-party who can mess up in many ways (Denial of service like in this case by being unavailable, Impersonation by allowing SIM swaps or intercepting messages directly).
You fully control how to store the TOTP seed and how you compute the value, so it is far more secure.
Yes, it can be phished if you fall for that, but it removes several attack vectors.
> 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%.
They report all of the services using the cable as a single segment of their business. Of course they are attributing operating costs to that segment.
Like 40% of the segment cost is "programming" (TV), so the internet part of the service likely has even better operating margin than the segment overall (basically, slightly higher revenue than TV with considerably lower costs).
> 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.
Yes it has benefits but also drawbacks; I don't like the tradeoff. You have to give the password manager too great capabilities to achieve the autovalidation+autofill. Maybe if you check and compile the password manager yourself.
Also automating the process entirely means the login process can happen and succeed (or fail and disclose the password to attacker) without the knowledge of the human.
I don't have time for that, so I just run both browser and password manager isolated and copy and paste the password.
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.
Passwords - protect against unauthorized access of my service accounts, and 1Password - can be compromised via logging or breaches or just plain peeping
Secret key - acts as 2FA for my 1Password and thus protects my master password from unauthorized use - can be compromised if someone steals the physical paper on which it's stored
TOTP - protect against unauthorized use of my service accounts - can be compromised if someone compromises my mobile phone or phone number. Highly unlikely someone would spend that kind of effort and €€€ on me though
All in all its a pretty nicely tiered system. If someone gets my master password, they still need the secret key. If a burglar steals my secret key, they don't have my master password. If someone somehow compromises both of those, they still don't have access to my TOTPs and thus can't login into any of my 'cricital' accounts (basically e-mail, hosting providers, finance, etc. etc.)
Now imagine you have an malicious spouse or housemate or whatever: they could easily learn your master password by peeping over your shoulder, piecing it together bit by bit (ha). They have a lot of opportunity to search for your secret key as well. If you put your TOTPs on 1Password, you're boned. But if you have them in an authenticator app, even having access to your password manager means jack because they can't login without your TOTPs.
I know one of the big faux pas is to talk about your security but most of this stuff can be deducted pretty easily so I don't feel too exposed.
> Not at all. TCP already does its own rate limiting without external throttling.
Individually, cars brake on the freeway to avoid hitting the car in front of them.
Collectively on a busy freeway, that sets off a chain reaction that results in the familiar rush hour crawl.
Minnesota did a study in 2001 on the effect of ramp meters, and disabling the meters (ie, removing throttling) resulted in statistically significant increase in overall freeway travel times.[0]
Statistically multiplexed shared networks like mobile wireless face similar issues. For a single TCP session the only metrics that can be divined by the endpoints are round-trip time and loss. As the shared network reaches capacity, larger numbers of TCP connections all back off around the same time, but large flows are more aggressive at ramping up than smaller flow (email/instant messaging, etc) and can result in an effective breakdown of network usability. A network control that has visibility to multiple flows and awareness of capacity of the system can influence overall performance much more effectively.
Ideally mobile providers would be trying to shoot for maintaining uniform latency per flow, similar to what queuing strategies like CoDel[1] achieve, but that's likely beyond the CPU and buffering capabilities of their existing hardware. Lacking the perfect solution, it's human nature to move on to the next approach: managing the biggest problem. Video is usually easy to identify, and so it wins the "able to be managed" prize.
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.
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.
TOTP just "feels" more secure.