20 ms·

Right; if an attack gains access to your password vault, then one vector MFA can protect against (the multi-factor part) isn't valid. But that's not the only ve

by 015a 5y ago

Right; if an attack gains access to your password vault, then one vector MFA can protect against (the multi-factor part) isn't valid. But that's not the only vector. The biggest vector MFA protects against isn't really brute forcing (though it helps there); its password phishing. This is literally the only reason behind why Google's "account compromises dropped to zero after we required MFA internally" thing is a thing. Its easy to phish a password; but phishing MFA codes is a lot harder because, primarily, they're temporal. Phishing one is possible, but it would require the attacker to immediately use the code they phished, which significantly protects against broad phishing campaigns (as, automating a password phish + an MFA phish + logging in with that info within 30 seconds + navigating to the change password and remove MFA screen + phishing for a second and third MFA code to change the password and remove MFA is near-impossible). Spear-phishing can still be a threat vector, but its much rarer and also made more difficult.

deleted 5y ago
[deleted]
thaumasiotes 5y ago
> (as, automating a password phish + an MFA phish + logging in with that info within 30 seconds + navigating to the change password and remove MFA screen + phishing for a second and third MFA code to change the password and remove MFA is near-impossible) Well... You get the MFA phish for free with the password phish, because the user actively expects to be prompted for the MFA code. Automating a login with the information is easy, and automating the requests to change password and remove MFA is also easy.[1] Phishing for followup MFA codes is a real obstacle, but probably not that difficult - assuming the source of codes is the same TOTP secret that was used for login, you can just tell your victim that their login failed and they should try again. That's a routine flow and it's unlikely to cause any alarm. [1] Among other things, there are decent odds that you can't remove MFA because of e.g. a corporate policy. But you can just automate whatever it is that you want the compromised account to do, and do that.
- dwaite 5y ago
  > [1] Among other things, there are decent odds that you can't remove MFA because of e.g. a corporate policy. But you can just automate whatever it is that you want the compromised account to do, and do that. The NIST 800-63 series has slowly been turning that ship around on ancient corporate password policies. The big step is to get the enterprise tooling to support newer policies. Multi-factor doesn't need to mean the user has to go through multiple steps. Kerberos, Mutual TLS and Web Authentication all can use physical possession of the device (e.g. embedded TPM in your laptop or phone, USB or NFC key, lanyard smart card) as one of the factors, which means then you just have to enter a PIN or supply a biometric.
dwaite 5y ago
> The biggest vector MFA protects against isn't really brute forcing (though it helps there); its password phishing. This is literally the only reason behind why Google's "account compromises dropped to zero after we required MFA internally" thing is a thing. To be clear, there are phishing resistant authentication methods. Specifically: 1. Kerberos 2. Mutual TLS 3. Web Authentication All other authentication methods (passwords, SMS, TOTP, QR code scan) are vulnerable to phishing. Google's announcement about dropping to zero wasn't about adding just any new MFA (they already had MFA) but in mandating Web Authentication. Some people get confused about phishing risk because passwords are vulnerable to passive phishing (e.g. log to file to attempt later), while the other mechanisms on this require active phishing (connect to a service in an attacker's browser, and parrot that authentication flow to the legitimate user). These active attacks are becoming more common, as you would expect. Password managers greatly reduce the susceptibility to phishing because they care about the site that one is currently on; the person will have to perform different steps to release their password (or TOTP) to the wrong site. There is a proposal to put semantic tagging in SMS challenges such that platforms will only offer to auto-fill on the specified site for the same reason. However, the three authentication methods above do not have user overrides such as manual SMS code entry - they simply won't work. You instead need to instead compromise the service, fronting application or hosting infrastructure/certificates. That isn't to say that the phishing-susceptible secondary factors doesn't help the site in other ways. There is simply no good way to guarantee that someone isn't reusing their email and password on several other sites until the password shows up on a breach list. This is especially a problem for corporate logins (using corporate email addresses). However, such secondary factors don't provide any benefit to the user with good password hygiene.
UncleMeat 5y ago
TOTP does not protect against phishing. Automating a phishing of a TOTP is not only not "near-impossible", there are SDKs sold on the black market that do exactly this for a modest fee.

by 015a 5y ago

deleted 5y ago

[deleted]

thaumasiotes 5y ago

> (as, automating a password phish + an MFA phish + logging in with that info within 30 seconds + navigating to the change password and remove MFA screen + phishing for a second and third MFA code to change the password and remove MFA is near-impossible) Well... You get the MFA phish for free with the password phish, because the user actively expects to be prompted for the MFA code. Automating a login with the information is easy, and automating the requests to change password and remove MFA is also easy.[1] Phishing for followup MFA codes is a real obstacle, but probably not that difficult - assuming the source of codes is the same TOTP secret that was used for login, you can just tell your victim that their login failed and they should try again. That's a routine flow and it's unlikely to cause any alarm. [1] Among other things, there are decent odds that you can't remove MFA because of e.g. a corporate policy. But you can just automate whatever it is that you want the compromised account to do, and do that.

dwaite 5y ago
> [1] Among other things, there are decent odds that you can't remove MFA because of e.g. a corporate policy. But you can just automate whatever it is that you want the compromised account to do, and do that. The NIST 800-63 series has slowly been turning that ship around on ancient corporate password policies. The big step is to get the enterprise tooling to support newer policies. Multi-factor doesn't need to mean the user has to go through multiple steps. Kerberos, Mutual TLS and Web Authentication all can use physical possession of the device (e.g. embedded TPM in your laptop or phone, USB or NFC key, lanyard smart card) as one of the factors, which means then you just have to enter a PIN or supply a biometric.

dwaite 5y ago

> The biggest vector MFA protects against isn't really brute forcing (though it helps there); its password phishing. This is literally the only reason behind why Google's "account compromises dropped to zero after we required MFA internally" thing is a thing. To be clear, there are phishing resistant authentication methods. Specifically: 1. Kerberos 2. Mutual TLS 3. Web Authentication All other authentication methods (passwords, SMS, TOTP, QR code scan) are vulnerable to phishing. Google's announcement about dropping to zero wasn't about adding just any new MFA (they already had MFA) but in mandating Web Authentication. Some people get confused about phishing risk because passwords are vulnerable to passive phishing (e.g. log to file to attempt later), while the other mechanisms on this require active phishing (connect to a service in an attacker's browser, and parrot that authentication flow to the legitimate user). These active attacks are becoming more common, as you would expect. Password managers greatly reduce the susceptibility to phishing because they care about the site that one is currently on; the person will have to perform different steps to release their password (or TOTP) to the wrong site. There is a proposal to put semantic tagging in SMS challenges such that platforms will only offer to auto-fill on the specified site for the same reason. However, the three authentication methods above do not have user overrides such as manual SMS code entry - they simply won't work. You instead need to instead compromise the service, fronting application or hosting infrastructure/certificates. That isn't to say that the phishing-susceptible secondary factors doesn't help the site in other ways. There is simply no good way to guarantee that someone isn't reusing their email and password on several other sites until the password shows up on a breach list. This is especially a problem for corporate logins (using corporate email addresses). However, such secondary factors don't provide any benefit to the user with good password hygiene.

UncleMeat 5y ago

TOTP does not protect against phishing. Automating a phishing of a TOTP is not only not "near-impossible", there are SDKs sold on the black market that do exactly this for a modest fee.