34 ms·

Using a local password manager isn’t MFA. How is that verifiable to the authentication service?

by peblos 3y ago

loup-vaillant 3y ago
And storing my TOTP code in the same password manager I use to store my GitHub password is not more of an MFA than using the password alone. They may hope I'm using my phone, but they can't know. And they shouldn't. My security, my business. Overall there are 2 cases to consider: one where a compromised users screws the user, and one where a compromised user screws the service. In the first case, which is most online services, the only reason the service cares about the security of an account is to protect the user. They have no business policing how said user handles their own security. Propose and nudge, sure, but verify? That goes one step too far. In the second case, which would be most enterprise networks, I would recommend that the company issues a security key to each employee, and ensures (with some form of remote attestation if need be) that employees log in with that key.
- peblos 3y ago
  In scenario 1, I can see the reasoning if we’re talking a low value account e.g. pseudo-anonymous account that holds no personal/financial info. In this case the service isn’t worried about you but the platform as a whole where a person or group can control many accounts Scenario 1.5 is non enterprise but with a financial or something of value aspect e.g. rewards/loyalty programs. The service has to protect against fraud Scenario 2: if we’re having this discussion about the need for MFA, how it ties us to devices and all the other reasons mentioned already, then using a security key with remote attestation is even more difficult for the end user. I don’t see how this is an improvement. It is in fact MFA itself, just with a different, more cumbersome, type of factor
  - loup-vaillant 3y ago
    How exactly in scenario 1 would the service protect itself against sock-puppets? How can they make sure that two different accounts are tied to two different users? How do they prune "false" accounts? We see that kind of stuff being done by Facebook for instance (real name policy), and it has basically nothing to do with MFA. In scenario 1.5 the service has to make sure users are protected. I believe it is counter productive there to force users beyond some reasonable step. For instance, it would be unacceptably discriminatory for a bank to require users to have an Android or iOS phone application to be able to make payments online. (Flip phone users should not be second class citizens.) Scenario 2 is almost exclusively about employees. Issuing hardware to employees is not difficult. I have 2 company-issued laptops, one from my company, one from my client. If my client wanted to increase security, it would be trivial for them to just give me a USB security key, and it would be trivial for me to just plug that key and touch it whenever there's a pop-up saying I should touch it. I don't see the difficulty here. In fact, given the choice of installing Okta on my personal phone, or using a security dongle, I would take the security dongle every time. Not only does it better separate work stuff from personal stuff, it's actually more convenient.
- FreakLegion 3y ago
  > And storing my TOTP code in the same password manager I use to store my GitHub password is not more of an MFA than using the password alone. Of course it is. Unlocking your passwords in KeepassXC isn't MFA in this context because it's completely orthogonal to phishing, brute force attacks, and data breaches. OTPs are far from great but help with all three, no matter where you store them.
  - loup-vaillant 3y ago
    Oh yeah? How does that help exactly? If the password database leaks, the TOTP shared secret can be used by attackers (one can't hash the TOTP shared secret like we do passwords). Phishing? They can just take my TOTP code and redirect it to the legitimate service. I may be able to stop them by asking the service to end the session (if I even find how to do that), but as long as the session is up they can do pretty much whatever they want. At best they'll be barred from doing important operations like changing the password, if the service asks for the TOTP code for such things. The only thing TOTP really mitigates is brute force attacks, and they do so only for people who use weak passwords. Since I'm using randomly generated passwords with over 120 bits of entropy, I'm basically immune to brute force to begin with. We have much better than TOTP to stop those attacks.
    - FreakLegion 3y ago
      > If the password database leaks, the TOTP shared secret can be used by attackers (one can't hash the TOTP shared secret like we do passwords) OTP secrets are stored encrypted, not in plaintext. > they'll be barred from doing important operations like changing the password, if the service asks for the TOTP code for such things. Yes, that's what "help" means here. OTPs limit the access lifetime and rights of the session. They help. They're strictly better than a password alone, whereas you claimed they're "not more of an MFA than using the password alone". To reiterate: 1. The password to unlock a password manager isn't MFA for the services the password manager protects because it's part of the authentication flow of your local system, not of those services. This is also why it does nothing to combat phishing, brute force attacks, or data breaches. 2. Where OTP secrets are stored, on the other hand, is irrelevant for those same threat models. Their value, limited as it is, is the same either way. In fact, if you use a password manager with OTP autofill and never type codes in by hand, you're basically doing as well against phishing as people using FIDO. But again, U2F and FIDO2 are strictly better.

Using a local password manager isn’t MFA. How is that verifiable to the authentication service?

by peblos 3y ago

Using a local password manager isn’t MFA. How is that verifiable to the authentication service?

And storing my TOTP code in the same password manager I use to store my GitHub password is not more of an MFA than using the password alone. They may hope I'm using my phone, but they can't know. And they shouldn't. My security, my business. Overall there are 2 cases to consider: one where a compromised users screws the user, and one where a compromised user screws the service. In the first case, which is most online services, the only reason the service cares about the security of an account is to protect the user. They have no business policing how said user handles their own security. Propose and nudge, sure, but verify? That goes one step too far. In the second case, which would be most enterprise networks, I would recommend that the company issues a security key to each employee, and ensures (with some form of remote attestation if need be) that employees log in with that key.

peblos 3y ago
In scenario 1, I can see the reasoning if we’re talking a low value account e.g. pseudo-anonymous account that holds no personal/financial info. In this case the service isn’t worried about you but the platform as a whole where a person or group can control many accounts Scenario 1.5 is non enterprise but with a financial or something of value aspect e.g. rewards/loyalty programs. The service has to protect against fraud Scenario 2: if we’re having this discussion about the need for MFA, how it ties us to devices and all the other reasons mentioned already, then using a security key with remote attestation is even more difficult for the end user. I don’t see how this is an improvement. It is in fact MFA itself, just with a different, more cumbersome, type of factor
- loup-vaillant 3y ago
  How exactly in scenario 1 would the service protect itself against sock-puppets? How can they make sure that two different accounts are tied to two different users? How do they prune "false" accounts? We see that kind of stuff being done by Facebook for instance (real name policy), and it has basically nothing to do with MFA. In scenario 1.5 the service has to make sure users are protected. I believe it is counter productive there to force users beyond some reasonable step. For instance, it would be unacceptably discriminatory for a bank to require users to have an Android or iOS phone application to be able to make payments online. (Flip phone users should not be second class citizens.) Scenario 2 is almost exclusively about employees. Issuing hardware to employees is not difficult. I have 2 company-issued laptops, one from my company, one from my client. If my client wanted to increase security, it would be trivial for them to just give me a USB security key, and it would be trivial for me to just plug that key and touch it whenever there's a pop-up saying I should touch it. I don't see the difficulty here. In fact, given the choice of installing Okta on my personal phone, or using a security dongle, I would take the security dongle every time. Not only does it better separate work stuff from personal stuff, it's actually more convenient.
FreakLegion 3y ago
> And storing my TOTP code in the same password manager I use to store my GitHub password is not more of an MFA than using the password alone. Of course it is. Unlocking your passwords in KeepassXC isn't MFA in this context because it's completely orthogonal to phishing, brute force attacks, and data breaches. OTPs are far from great but help with all three, no matter where you store them.
- loup-vaillant 3y ago
  Oh yeah? How does that help exactly? If the password database leaks, the TOTP shared secret can be used by attackers (one can't hash the TOTP shared secret like we do passwords). Phishing? They can just take my TOTP code and redirect it to the legitimate service. I may be able to stop them by asking the service to end the session (if I even find how to do that), but as long as the session is up they can do pretty much whatever they want. At best they'll be barred from doing important operations like changing the password, if the service asks for the TOTP code for such things. The only thing TOTP really mitigates is brute force attacks, and they do so only for people who use weak passwords. Since I'm using randomly generated passwords with over 120 bits of entropy, I'm basically immune to brute force to begin with. We have much better than TOTP to stop those attacks.
  - FreakLegion 3y ago
    > If the password database leaks, the TOTP shared secret can be used by attackers (one can't hash the TOTP shared secret like we do passwords) OTP secrets are stored encrypted, not in plaintext. > they'll be barred from doing important operations like changing the password, if the service asks for the TOTP code for such things. Yes, that's what "help" means here. OTPs limit the access lifetime and rights of the session. They help. They're strictly better than a password alone, whereas you claimed they're "not more of an MFA than using the password alone". To reiterate: 1. The password to unlock a password manager isn't MFA for the services the password manager protects because it's part of the authentication flow of your local system, not of those services. This is also why it does nothing to combat phishing, brute force attacks, or data breaches. 2. Where OTP secrets are stored, on the other hand, is irrelevant for those same threat models. Their value, limited as it is, is the same either way. In fact, if you use a password manager with OTP autofill and never type codes in by hand, you're basically doing as well against phishing as people using FIDO. But again, U2F and FIDO2 are strictly better.