Comment by xavdid | Hacker News Reader

Comment by xavdid | Hacker News Reader

Parent Full thread

> if you're storing the passwords in the same place as the MFA secrets, then it's not actually MFA anymore.

I see this sentiment a lot and IMO it over-simplifies the security model pretty drastically. It's unlikely that a 1P vault is breached or leaked. For most people, the most likely threat vector for a random internet account is:

  1. they re-use a password across sites
  2. one site gets breached and that password is included in a hash dump (probably associated with their email)
  3. one the hashes are broken, an attacker can try that password on another site

In this situation, MFA stored in their password manager is still MFA because the TOTP secret wasn't leaked with the password (or it was and then it doesn't matter where you store it on your end).

The only case in which storing MFA secrets with your passwords becomes an issue is if other people have access to your laptop (and password manager). Then you'd probably want passwords on the laptop and MFA on your phone (or something else kept on your person).

Nobody questions leaving a yubikey in a laptop (which is also full of passwords). Even if doing so means anyone with your laptop can use your yubikey, it narrows your attack vector from "anyone who got your password" to "anyone with physical access to your laptop", which is a great reduction in scope (for most people).

That's not the only attack vector that is mitigated by TOTP. If a hacker is somehow able to intercept your password and your TOTP for a short period of time (e.g. because you're in an unsecured network at Starbucks or something), they can do exactly nothing with that knowledge afterwards. They won't be able to perform a replay attack, and they won't be able to guess your next TOTP, or any that comes after. The "only" thing they can do is attack you right at the moment where you're using the insecure network (e.g. with some sort of MITM attack).

An unsecured network doesn’t help an attacker gain your TOTP and password unless you’re using a website without HTTPS or that otherwise messes up by putting the credentials as query parameters.

The most an attacker might be able to view is the addresses of the sites you are connecting to.

> The most an attacker might be able to view is the addresses of the sites you are connecting to.

With TLS 1.2 or earlier the attacker can almost certainly discern the real DNS name of the site you're connecting to, in TLS 1.3 this is merely likely (and ECH might some day largely eliminate this risk) but not certain depending on how you connect.

In practice your client hates wasting bandwidth and so precise size measurements are also surprisingly effective. If six people who I'm snooping watch movies from the Fast & Furious franchise on a streaming service and one watches "The Imitation Game" I can tell them apart with more or less 100% reliability. If they all read Wikipedia, six looking at stuff about dinosaurs and one reading about the Senate Intelligence Committee report on CIA torture, I can tell again.

Clients (e.g. your web browser) could do more to hamper this, but they do almost nothing. For example, suppose I'm sending an encrypted HTTP request with some data in it, and it'll fit easily into 4 Ethernet packets. I could pad that last packet so it's always full, and have the decryption step remove that padding for free but clients don't bother, so a bad guy can measure how long my data is to within maybe 16 bytes.

Yes, you're correct. An unsecured network is not enough. A honeypot wifi that the attacker controls would work, though, because they could just perform a MITM attack and thus decrypt your TLS traffic.

That’s not true either, as they won’t possess https certificates for whatever the domain is and your browser would flag/block you from continuing.

huh, if they can MITM your connection, then they can just forward the certificates from the real host.

They will be able to view the public certificate but will not be able to sign or decrypt anything because they do not have the corresponding private key, which is never sent over the wire.

HTTPS protects against MITM attacks.

When the owner of the domain originally obtained a certificate, the obtained signed attestation from a trusted provider that they were able to field requests to that domain. Those requests can come from anywhere and are not possible to MITM. This attestation pertains to a public key/private key pair.

You're right, I misremembered. Thanks for pointing it out.

They already have the session and can do anything with it, they don't need a replay.

It will depend on the application, how often sessions expire, how often you need to input a new TOTP, etc.

In particular, think about bank transfers, each requiring a different transaction code (not technically a TOTP, but similar in spirit).

> The only case in which storing MFA secrets with your passwords becomes an issue is if other people have access to your laptop (and password manager). Then you'd probably want passwords on the laptop and MFA on your phone (or something else kept on your person).

The problem is that a lot of the major package managers - at least nodejs npm/yarn, PHP composer, Apache Maven, Gradle - allow code execution of whatever packages were specified as part of the installation or build process.

That means there are an equal lot of very juicy targets for a takeover - just look at the most popular build plugins... and a few minutes are enough to deploy a keepass and browser credential store stealer to a ton of people. Getting local code execution isn't that difficult if you manage to spray your payload over a huge enough area.

Getting access to a target and their MFA device however is vastly more complicated.

pypi doesn't require 2fa to upload.

They use 2fa to login onto the website and make you create a token. After that you just save the token within your project and have a script to upload new versions.

Reply on news.ycombinator.com