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.

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.

[0]http://www.dot.state.mn.us/rampmeter/study.html [1]https://en.wikipedia.org/wiki/CoDel

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.

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.

[0]https://github.com/ustayready/CredSniper

You can be in control of your actual data pretty easily with gmail. One of the better options I’ve found for maintaining a local archive is the Got Your Back[0] script. It maintains an SQLite DB with all of the message tag associations, and stores all your emails in standard .msg format text files.

If you want additional peace of mind, you can spend a few pennies and use restic[1] to do regular incremental backups of the archive to Backblaze B2 to add yet another storage location and version index.

[0] https://github.com/jay0lee/got-your-back/wiki

[1] https://restic.net

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.

Fidelity already has best-in-class checking account features?

The CMA account has mobile image deposit, free online bill pay, check writing (with free checks), free ACH transfers, free wire transfers, ATM/debit card (with ATM fee reimbursement at any ATM worldwide, no less), etc.

The only “best-in-class” factor that Robinhood has presented is setting the interest at 3%.

While the new funds are attracting all the attention, I find these other changes more interesting:

Expense Ratios have been slashed across existing funds: https://www.fidelity.com/mutual-funds/investing-ideas/index-...

Premium, Investor, and Institutional classes are all being merged into 1 class with lower fees and no minimums: https://www.fidelity.com/bin-public/060_www_fidelity_com/doc...

For people holding existing Fidelity index funds, you just start paying less now without having to do anything.

You find examples like this all over the place:

https://security.stackexchange.com/questions/49521/does-two-...

It gets worse if you search around for people talking about how they use 2FA codes to protect their accounts when logging into services on public computers.

The perception of the security added by 2FA emboldens people to make all kinds of poor security choices.

This was also my first thought when reading this. It almost makes me wonder if it was really a SMS exploit at all — when someone has the user, pass, and 2FA code, that sounds to me like the target clicked on a convincing URL and readily supplied all the things their attacker would need.

At least IPv6 is getting developed and it's is easier to update than DAB, so one can hope that one day in the far future it becomes usable to people like me.

Millions of people unknowningly use IPv6 every day: smartphone users on mobile networks. You either get an IPv4 address in 100.64.0.0/10 Carrier Grade NAT space or RFC1918 10.0.0.0/8 space, and a fully routeable IPv6 address. Your mobile application experience tends to be far better with services that can take advantage of native IPv6 connectivity.

Proxying the authentication isn't really an "advanced" attack. In a 19 minute video[0] the author of CredSniper[1] gives a complete walk-through for setting up his proof of concept tool, including building the login pages and registering for LetsEncrypt SSL certs. The hardest part still remains choosing the domain name and getting people to click the link, and still people find ways to overcome those hurdles.

As TOTP use has increased, the basic phishing toolkit has evolved to match. Attackers want accounts, not passwords, so they're just adjusting to get working sessions. The passwords were only ever just a means to an end.

[0] https://www.youtube.com/watch?v=TeSt9nEpWTs [1] https://github.com/ustayready/CredSniper

Google and Apple both have mobile (non-SMS) based two factor prompts that seem equally immune to phishing?

Any "type in a code" or "approve this login (yes/no)?" authentication factor is technically vulnerable. All the phishing site needs to do is proxy the authentication to the actual site in real time.

These guys put together a great overview of the approach: https://www.wandera.com/bypassing-2fa/

TOTP is very useful! Just use a TOTP authenticator app on your phone, and don't put them in 1Password.

I was fully in that camp before I started talking with friends on red teams that were allowed to actually start using realistic phishing campaigns. Now I'm fully in the "U2F, client certs, or don't bother" camp.

Maybe I'm jaded, but it feels like the exploit landscape has improved enough that TOTP is as hopeless as enabling WEP on a present-day wireless network. Not only does setting it up waste your time, you're presumably doing so because you have the false belief it will actually offer protection from something. It may have been useful at one point, but those days are disappearing in the rearview mirror.

The only place I see TOTP still offering value is for people who re-use passwords, but only because it becomes the single site-unique factor for authentication.

This is where it comes down to user behavior. One of the security engineers from Stripe gave a talk about this at Blackhat last year -- she had phishing campaigns that had users ignore that autofill didn't work and manually copied/pasted their password manager credentials into the phishing sites.

https://www.youtube.com/watch?v=Z20XNp-luNA

They got around 2FA over SMS because a number of services like GMail offered password reset via SMS as well as 2FA over SMS.

It was the password reset process that was the most vulnerable, and strangely the part that kept getting glossed over when people reported on the takeover incidents.

This is the thing I struggle with: name a scenario where you would have your unique site password compromised but not have at least 1 valid 2FA code compromised at the same time.

The best answer I have for where TOTP can provide value: you can limit a potential attack to a single login.

I wanted to say you could stop someone doing MitM decryption due to timing (you use the 2FA code before they can), but if they're decrypting your session they can most likely just steal your session cookie which gets them what they need anyway.

If there's a MitM attack, you've already lost. Sure, they can only login one time, but they're in once you provide the authentication steps.

Phishing sites collecting and using the 2FA creds in real time was discussed here, among other places: https://security.stackexchange.com/questions/161403/attacker...

With available open source like https://github.com/ustayready/CredSniper readily available, you're only going to stop lazy phishing attempts.

You only get protection if you assume the scripts are just passively collecting information for use at a later time. If they're actively logging in to establish sessions while they're phishing, it's game over.

If you're using a password manager to have unique passwords for every site, what does TOTP 2FA even protect you against?

Since 2FA only comes into play for protection if the password is compromised, if you're using a password manager that should mean that data breaches at unrelated sites shouldn't be a risk.

So we're down to phishing and malware/keyloggers being the most likely risk -- and TOTP offers no protection against that. If you're already at the point that you're keying your user/pass into a phishing site, you're not going to second guess punching in the 2FA code to that same site. I'd even argue push validation like Google Prompt would be at a significant risk for phishing, unless you are paying close attention to what IP address for which you're approving access.

Whenever I see solutions like this I think back to an org I worked at where a high-visibility day-long database outage gained upper level management attention. The response, after the managers talked to our vendor (IBM), was to re-architect everything to use HACMP clusters for all of our production databases company-wide.

That was followed by a couple years of 100+ hour/year cumulative outages due to HACMP stability issues, and an environment that everyone was deathly afraid to touch.

The hardcore network engineer in me appreciates the detail in these kinds of solutions, but these days the practical side of me is satisfied with usability and maintainability of SPOF cable access with a manual failover to mobile hotspot on the rare occasions that drops offline.

No.