5 ms·

Multi-factor authentication isn't necessarily strong

66 points by hsnewman 7y ago

blfr 7y ago
A password manager and a handful of YubiKeys are pretty perfect. And they make for a good, simple advice to give to people if they're worried about security.
- gcthomas 7y ago
  Yup. The target for MFA is not perfect security, but security better than passwords alone — the bar is quite low to start with. And all of the above techniques offer that to varying degrees. I use strong passwords on all sensitive accounts, stored in a local password manager, with an authenticator app for those that don't accept my Fido2 Yubkey. Seems good enough to me.
  - eeZah7Ux 7y ago
    If a workstation is compromised, having multi-factor authentication is useless for most services: The real targets become the HTTPS session cookies and files on disk.
    - robcohen 7y ago
      This is correct, which is why I am a big fan of FIDO U2F software like https://Krypt.co https://Krypt.co . This requires your phone which is essentially a second workstation to authenticate. So now you need to exploit two workstations.
      - eeZah7Ux 7y ago
        No. Once you authenticated your sessions are the target.
    - scient 7y ago
      Even then the external services will still require first and second factors of authentication. If your workstation is compromised on an ongoing basis, then nothing matters. If its an one-time even, 2FA will protect the external services still.
    - acdha 7y ago
      Note that responsible sites do variations on IP / location fixation to reduce the value of exfiltrated session cookies and, of course, they're only valid for as long as you go between verifications. One really nice thing about FIDO is that it affords a low-pain “tap the button to confirm it's you” verification instead of a full password challenge.
      - eeZah7Ux 7y ago
        The attacker can very easily use your workstation as a vantage point. Even used directly your browser and your SSH sessions. It's makes it even more difficult to detect and trace.
        acdha 7y ago
        Yes, which is a different threat than what was under discussion. Don't argue that we don't need seatbelts because they don't help when the driver is a kidnapper.
- sebazzz 7y ago
  How does Yubikey prevent against SSL spoofing?
  - wcip 7y ago
    What do you mean by SSL spoofing? Someone getting a public CA validated cert for a domain they do not own? I'd consider that a game over level threat myself, I can't imagine much of anything protecting against that completely. Certificate pinning can help mitigate the threat though.
  - Spooky23 7y ago
    Totally different threat. The lock on your car door won’t stop a tow truck.
  - graton 7y ago
    Somewhat related. U2F, which Yubikey supports does help prevent against DNS spoofing. A DNS name which looks very similar but is not the true DNS name of the site you want to connect to. Something that a human might not notice or get confused by will be stopped by U2F.
- rb808 7y ago
  What if they keys get lost/stolen or your house burns down. Do you keep a backup somewhere?
  - graton 7y ago
    They mentioned having a handful of Yubikeys. The nice thing about U2F is that many providers support having multiple U2F tokens. For example Google, Github, and Gitlab do. Though others do not, for example AWS (last time I checked). So you can keep one or two on your keychain and keep others in different locations as backups. One nice thing about the Yubikeys is that they can also support TOTP like Google Authenticator. So you could store your authenticator token on both your phone and on the Yubikey. Then use the Yubikey Authenticator app to get the code from the Yubikey. I do recommend requiring touch to access the code from the Yubikey. You most likely need to setup this up at the same time on both your phone and Yubikey. As most authenticator apps (but not all) don't let you have access to the secret once stored on your phone.
    - tzs 7y ago
      > The nice thing about U2F is that many providers support having multiple U2F tokens. For example Google, Github, and Gitlab do. Though others do not, for example AWS (last time I checked). Note that in the case of AWS it is not as bad as it seems, if you use your AWS account they way Amazon recommends. When you initially create your account, the credentials you make (email and password) have full privileges on the account. This is called the "root" user. The root user can create other users on the account, and delegate to them most of the privileges of root (but not all). Amazon recommends that you make one or more admin user accounts to wield all the privileges that can be delegated, and then no longer use the root account except for those few tasks that can only be done with root. Use the admin user(s) to create regular user accounts for everything else. If you have N U2F tokens, make N admin users and associate each with a different token. Associate each regular user account with one of the tokens you carry on your key chain. If you lose a token, use one of the remaining tokens with the admin account it is associated with to reset the accounts that were using the lost token and then associate them with one of the remaining tokens. If you use U2F with the root account and lose its token you can do a reset of your 2FA setup via email and phone. You should only rarely need to use the root account, so its token should probably be one of the ones you keep in some safe spot like in your fireproof safe, not one you carry around on your key chain.
- brians 7y ago
  These are great for operators in an ops center or devs at workstations. They’re not enough for managers on email or execs traveling across interesting borders.
notlukesky 7y ago
There are many types of multi-factor authentication and randomly generated dynamic passcodes. There is time-based and counter-based (aka event-based) and combination of both. There is also MFA that have and don’t have seed registration. There is MFA for corporate use and different ones for end users. End user MFA often consists of TOTP, HOTP, FIDO U2F, WebAuth and SMS OTP. Each one of these have different security and usability profiles. SMS OTP has the lowest security profile but the broadest reach (no mobile app or token key necessary). Most mobile Authenticator apps support the TOTP and HOTP formats. But few of them are cross-platform and on multiple devices with auto-filling capabilities with an optional integrated password manager and Authenticator like SAASPASS. In addition most Authenticator apps do not have secure backup and restore capabilities. But the weak link in most consumer implementations of MFA is not the MFA but the automated account recovery process that is often susceptible to SIM Swap attacks (you are only as strong as your weakest link - irrespective of MFA usage). The SAASPASS mobile app has a Security Scan function that identifies duplicate and weak passwords and in addition services that have the Authenticator (TOTP/HOTP) format of MFA in the password manager. As for corporates the choices of configurable MFA can vary from (from SAASPASS): Manual OTP (offline supported) Push Login Approval Scan Encrypted Barcode Remote Login 2FA (IoT) Remote Lock 2FA (IoT) Mobile On Device Login Mobile Web URL callback Proximity (offline supported) App to App (with SDK) SAASPASS Connect SAASPASS system offerings: SMS OTP Email OTP 3rd Party Tokens: HOTP tokens TOTP tokens FIDO U2F (offline supported) Yubico OTP Biometric Methods: FaceID - iPhone TouchID - iPhone Fingerprint on Android Facial on Android Facial Authentication (offline supported on-premise) - Corporates should still use Access Control policies (even with the strongest of MFA implementations like Scanning Encrypted Barcodes). Disclosure: I work in the IAM space and a reseller of SAASPASS.
rasengan 7y ago
If the system you are authenticating to is hacked then MFA becomes useless immediately.
- scient 7y ago
  Whats your point? That its pointless to use 2FA because of it not being a perfect protection for all scenarios?
- acdha 7y ago
  This is like arguing that a seatbelt is useless because it doesn't help if someone plants a bomb in your car. You have to have a threat model to talk about security: in the case of MFA, it protects against someone getting your password without your knowledge — whether or not the remote site is compromised is outside of that scope. MFA does help in one scenario related to that, however: when someone compromises SiteA and gets your password which you also used on SiteB, they can't use it if SiteB has MFA setup — even if they compromised SiteA's MFA implementation. That's a pretty useful characteristic in an era where breaches are common.
zimbatm 7y ago
Another one is when the user puts the password manager on the same phone that receives the 2nd factor by SMS or in an OTP app. Now all the data is available and unlocked at the same time on the same device again. Or when the user puts the OTP 2nd factor in 1password. The best way to prevent that type of cheating is to enforce the user of physical keys like Yubikeys
- acdha 7y ago
  > Now all the data is available and unlocked at the same time on the same device again. This really depends on the device in question: if you're talking about an iPhone 3GS or later or an Android phone which is less than a couple years old, the device has pretty strict protections against cross-application access. It's still technically possible for a rooted device to compromise both but in practice that's not true for most users — call it 1.5-factor auth or something but it's a lot different than the classic desktop model where any running code has access to all of the data which you care about.
  - leroy_masochist 7y ago
    If you have the latest iPhone/Mac, you can still get iMessages delivered to your desktop, easily facilitating a state in which (almost by default, given how eager Google is to remember your passwords) anyone who has access to your unlocked computer can log into your bank account just by visiting the bank's website and get immediate access to the 6-digit verification code that they text you. Sending codes within a native app that exists only and specifically on your handset is a much more robust solution; I'd imagine the reason why it's implemented so infrequently is that its upshot is a lot of angry, frantic calls to tech support.
    - acdha 7y ago
      > If you have the latest iPhone/Mac, you can still get iMessages delivered to your desktop … to your unlocked computer can log into your bank account just by visiting the bank's website and get immediate access to the 6-digit verification code that they text you. What you're thinking of is the Handoff feature which allows your desktop to get access to SMS, not iMessage, and that's been recommended against for exactly this reason for many years. It's also somewhat dwarfed by the fact that SMS is inherently insecure and not a responsible choice for MFA in any scenario. In the case of banks, they really need to be pushing FIDO since that protects against this threat and also the phishers who create very realistic sites including requests for SMS/TOTP codes.
acdha 7y ago
The material in here isn't terribly wrong but it seems like an elaborate way to say “you should have a threat model when making security decisions” and “RSA is overselling their software tokens to the point where legal authorities should investigate”. In particular, it's about 5 years obsolete with no mention of U2F/FIDO, which avoids all of the problems mentioned and prevents phishing attacks from succeeding if they capture TOTP/SMS challenges.
- lonelappde 7y ago
  Nothing wrong with elaborating on a true thing to educate people. Leagues ahead of the usual fare, elaborations on opinions, exaggerations, and false statements.
  - maxymajzr 7y ago
    But it's not educating anyone. A handful of people who deal with this particular area on daily basis are capable of understanding what the blog post is about. Gist of the post is that if you have all the info needed to construct the secret used to extract 6 numbers - you can copy it around and have copies of the device that produces one time passwords. Obtaining the shared secret and knowing the user's credentials is difficult to achieve (obtaining both). Even if it were to happen, you, as a service provider, have undeniable evidence that the user was negligent because leaking out the secret for MFA isn't exactly easy to do. Data leaks due to malicious employees is often the attack vector in these cases. I'd argue that safe-keeping the data in a way that employees can't access it easily is what's actually a big deal in data breaches, not the actual mechanisms (RFC4226 and RFC6238 algorithms and their derivatives) that rely on keeping data safe. Attacking a service that's been breached by leaking shared secrets is still extremely hard - you have to know the credentials and corresponding shared secret out of hundreds of thousands of leaked ones. Only way to attack the service is brute-forcing it. That doesn't go unnoticed. Plausible attacks are extremely rare and difficult to achieve and edge cases that are possible only when extremely sensitive data is leaked aren't an argument against MFA. The post we're commenting on mentions U2F - that particular approach completely obviates all the problems mentioned in this blog post, on top of being vastly easier to use to the end user (stick the token in the usb port, press the flashing button, job done).
brians 7y ago
It seems like “delegation” is the idea that would most help build on this. I’ve had assessors tell me that I had only a single factor in the cookie on disk after an authentication process that involved TLS client certs and an off-device OTP.
ericalexander3 7y ago
U2F > TOTP > Any MFA > no MFA Why? About 23% of the classified breaches in this data set are due to compromised valid accounts and any MFA would probably have prevented the breach. Often security isn't about out running the bear, it's about out running the person next to you. data set: https://github.com/ericalexanderorg/SecurityBreach https://github.com/ericalexanderorg/SecurityBreach
- tialaramex 7y ago
  New systems should implement WebAuthn rather than U2F.
mindslight 7y ago
Real security is hard work, because it requires imposing a burden on users, as well as diligent design to not then squander it. Snake oil is profitable, because you can sell it in place of security while not making the users and developers do that work. "Multi factor authentication" has trickled down into snake oil drip pan. That is what a "soft token" is. That is what text message / email verification is. That is what additional passwords are (eg "what is your favorite high school"). These "solutions" let companies check an "MFA" box with no substantive changes. Not that I want any of these companies pushing "MFA" onto users to insist on more invasive methods either. I like that their bullshit SMS challenge goes to a cloud provider and pops up in a terminal ready to be pasted, because frankly that challenge wasn't wanted by anybody except whomever in their company needed to check that box! It's Sturgeon's / Gresham's law all the way down.

66 points by hsnewman 7y ago

blfr 7y ago

A password manager and a handful of YubiKeys are pretty perfect. And they make for a good, simple advice to give to people if they're worried about security.

gcthomas 7y ago
Yup. The target for MFA is not perfect security, but security better than passwords alone — the bar is quite low to start with. And all of the above techniques offer that to varying degrees. I use strong passwords on all sensitive accounts, stored in a local password manager, with an authenticator app for those that don't accept my Fido2 Yubkey. Seems good enough to me.
- eeZah7Ux 7y ago
  If a workstation is compromised, having multi-factor authentication is useless for most services: The real targets become the HTTPS session cookies and files on disk.
  - robcohen 7y ago
    This is correct, which is why I am a big fan of FIDO U2F software like https://Krypt.co https://Krypt.co . This requires your phone which is essentially a second workstation to authenticate. So now you need to exploit two workstations.
    - eeZah7Ux 7y ago
      No. Once you authenticated your sessions are the target.
  - scient 7y ago
    Even then the external services will still require first and second factors of authentication. If your workstation is compromised on an ongoing basis, then nothing matters. If its an one-time even, 2FA will protect the external services still.
  - acdha 7y ago
    Note that responsible sites do variations on IP / location fixation to reduce the value of exfiltrated session cookies and, of course, they're only valid for as long as you go between verifications. One really nice thing about FIDO is that it affords a low-pain “tap the button to confirm it's you” verification instead of a full password challenge.
    - eeZah7Ux 7y ago
      The attacker can very easily use your workstation as a vantage point. Even used directly your browser and your SSH sessions. It's makes it even more difficult to detect and trace.
      - acdha 7y ago
        Yes, which is a different threat than what was under discussion. Don't argue that we don't need seatbelts because they don't help when the driver is a kidnapper.
sebazzz 7y ago
How does Yubikey prevent against SSL spoofing?
- wcip 7y ago
  What do you mean by SSL spoofing? Someone getting a public CA validated cert for a domain they do not own? I'd consider that a game over level threat myself, I can't imagine much of anything protecting against that completely. Certificate pinning can help mitigate the threat though.
- Spooky23 7y ago
  Totally different threat. The lock on your car door won’t stop a tow truck.
- graton 7y ago
  Somewhat related. U2F, which Yubikey supports does help prevent against DNS spoofing. A DNS name which looks very similar but is not the true DNS name of the site you want to connect to. Something that a human might not notice or get confused by will be stopped by U2F.
rb808 7y ago
What if they keys get lost/stolen or your house burns down. Do you keep a backup somewhere?
- graton 7y ago
  They mentioned having a handful of Yubikeys. The nice thing about U2F is that many providers support having multiple U2F tokens. For example Google, Github, and Gitlab do. Though others do not, for example AWS (last time I checked). So you can keep one or two on your keychain and keep others in different locations as backups. One nice thing about the Yubikeys is that they can also support TOTP like Google Authenticator. So you could store your authenticator token on both your phone and on the Yubikey. Then use the Yubikey Authenticator app to get the code from the Yubikey. I do recommend requiring touch to access the code from the Yubikey. You most likely need to setup this up at the same time on both your phone and Yubikey. As most authenticator apps (but not all) don't let you have access to the secret once stored on your phone.
  - tzs 7y ago
    > The nice thing about U2F is that many providers support having multiple U2F tokens. For example Google, Github, and Gitlab do. Though others do not, for example AWS (last time I checked). Note that in the case of AWS it is not as bad as it seems, if you use your AWS account they way Amazon recommends. When you initially create your account, the credentials you make (email and password) have full privileges on the account. This is called the "root" user. The root user can create other users on the account, and delegate to them most of the privileges of root (but not all). Amazon recommends that you make one or more admin user accounts to wield all the privileges that can be delegated, and then no longer use the root account except for those few tasks that can only be done with root. Use the admin user(s) to create regular user accounts for everything else. If you have N U2F tokens, make N admin users and associate each with a different token. Associate each regular user account with one of the tokens you carry on your key chain. If you lose a token, use one of the remaining tokens with the admin account it is associated with to reset the accounts that were using the lost token and then associate them with one of the remaining tokens. If you use U2F with the root account and lose its token you can do a reset of your 2FA setup via email and phone. You should only rarely need to use the root account, so its token should probably be one of the ones you keep in some safe spot like in your fireproof safe, not one you carry around on your key chain.
brians 7y ago
These are great for operators in an ops center or devs at workstations. They’re not enough for managers on email or execs traveling across interesting borders.

notlukesky 7y ago

There are many types of multi-factor authentication and randomly generated dynamic passcodes. There is time-based and counter-based (aka event-based) and combination of both. There is also MFA that have and don’t have seed registration. There is MFA for corporate use and different ones for end users. End user MFA often consists of TOTP, HOTP, FIDO U2F, WebAuth and SMS OTP. Each one of these have different security and usability profiles. SMS OTP has the lowest security profile but the broadest reach (no mobile app or token key necessary). Most mobile Authenticator apps support the TOTP and HOTP formats. But few of them are cross-platform and on multiple devices with auto-filling capabilities with an optional integrated password manager and Authenticator like SAASPASS. In addition most Authenticator apps do not have secure backup and restore capabilities. But the weak link in most consumer implementations of MFA is not the MFA but the automated account recovery process that is often susceptible to SIM Swap attacks (you are only as strong as your weakest link - irrespective of MFA usage). The SAASPASS mobile app has a Security Scan function that identifies duplicate and weak passwords and in addition services that have the Authenticator (TOTP/HOTP) format of MFA in the password manager. As for corporates the choices of configurable MFA can vary from (from SAASPASS): Manual OTP (offline supported) Push Login Approval Scan Encrypted Barcode Remote Login 2FA (IoT) Remote Lock 2FA (IoT) Mobile On Device Login Mobile Web URL callback Proximity (offline supported) App to App (with SDK) SAASPASS Connect SAASPASS system offerings: SMS OTP Email OTP 3rd Party Tokens: HOTP tokens TOTP tokens FIDO U2F (offline supported) Yubico OTP Biometric Methods: FaceID - iPhone TouchID - iPhone Fingerprint on Android Facial on Android Facial Authentication (offline supported on-premise) - Corporates should still use Access Control policies (even with the strongest of MFA implementations like Scanning Encrypted Barcodes). Disclosure: I work in the IAM space and a reseller of SAASPASS.

rasengan 7y ago

If the system you are authenticating to is hacked then MFA becomes useless immediately.

scient 7y ago
Whats your point? That its pointless to use 2FA because of it not being a perfect protection for all scenarios?
acdha 7y ago
This is like arguing that a seatbelt is useless because it doesn't help if someone plants a bomb in your car. You have to have a threat model to talk about security: in the case of MFA, it protects against someone getting your password without your knowledge — whether or not the remote site is compromised is outside of that scope. MFA does help in one scenario related to that, however: when someone compromises SiteA and gets your password which you also used on SiteB, they can't use it if SiteB has MFA setup — even if they compromised SiteA's MFA implementation. That's a pretty useful characteristic in an era where breaches are common.

zimbatm 7y ago

Another one is when the user puts the password manager on the same phone that receives the 2nd factor by SMS or in an OTP app. Now all the data is available and unlocked at the same time on the same device again. Or when the user puts the OTP 2nd factor in 1password. The best way to prevent that type of cheating is to enforce the user of physical keys like Yubikeys

acdha 7y ago
> Now all the data is available and unlocked at the same time on the same device again. This really depends on the device in question: if you're talking about an iPhone 3GS or later or an Android phone which is less than a couple years old, the device has pretty strict protections against cross-application access. It's still technically possible for a rooted device to compromise both but in practice that's not true for most users — call it 1.5-factor auth or something but it's a lot different than the classic desktop model where any running code has access to all of the data which you care about.
- leroy_masochist 7y ago
  If you have the latest iPhone/Mac, you can still get iMessages delivered to your desktop, easily facilitating a state in which (almost by default, given how eager Google is to remember your passwords) anyone who has access to your unlocked computer can log into your bank account just by visiting the bank's website and get immediate access to the 6-digit verification code that they text you. Sending codes within a native app that exists only and specifically on your handset is a much more robust solution; I'd imagine the reason why it's implemented so infrequently is that its upshot is a lot of angry, frantic calls to tech support.
  - acdha 7y ago
    > If you have the latest iPhone/Mac, you can still get iMessages delivered to your desktop … to your unlocked computer can log into your bank account just by visiting the bank's website and get immediate access to the 6-digit verification code that they text you. What you're thinking of is the Handoff feature which allows your desktop to get access to SMS, not iMessage, and that's been recommended against for exactly this reason for many years. It's also somewhat dwarfed by the fact that SMS is inherently insecure and not a responsible choice for MFA in any scenario. In the case of banks, they really need to be pushing FIDO since that protects against this threat and also the phishers who create very realistic sites including requests for SMS/TOTP codes.

acdha 7y ago

The material in here isn't terribly wrong but it seems like an elaborate way to say “you should have a threat model when making security decisions” and “RSA is overselling their software tokens to the point where legal authorities should investigate”. In particular, it's about 5 years obsolete with no mention of U2F/FIDO, which avoids all of the problems mentioned and prevents phishing attacks from succeeding if they capture TOTP/SMS challenges.

lonelappde 7y ago
Nothing wrong with elaborating on a true thing to educate people. Leagues ahead of the usual fare, elaborations on opinions, exaggerations, and false statements.
- maxymajzr 7y ago
  But it's not educating anyone. A handful of people who deal with this particular area on daily basis are capable of understanding what the blog post is about. Gist of the post is that if you have all the info needed to construct the secret used to extract 6 numbers - you can copy it around and have copies of the device that produces one time passwords. Obtaining the shared secret and knowing the user's credentials is difficult to achieve (obtaining both). Even if it were to happen, you, as a service provider, have undeniable evidence that the user was negligent because leaking out the secret for MFA isn't exactly easy to do. Data leaks due to malicious employees is often the attack vector in these cases. I'd argue that safe-keeping the data in a way that employees can't access it easily is what's actually a big deal in data breaches, not the actual mechanisms (RFC4226 and RFC6238 algorithms and their derivatives) that rely on keeping data safe. Attacking a service that's been breached by leaking shared secrets is still extremely hard - you have to know the credentials and corresponding shared secret out of hundreds of thousands of leaked ones. Only way to attack the service is brute-forcing it. That doesn't go unnoticed. Plausible attacks are extremely rare and difficult to achieve and edge cases that are possible only when extremely sensitive data is leaked aren't an argument against MFA. The post we're commenting on mentions U2F - that particular approach completely obviates all the problems mentioned in this blog post, on top of being vastly easier to use to the end user (stick the token in the usb port, press the flashing button, job done).

brians 7y ago

It seems like “delegation” is the idea that would most help build on this. I’ve had assessors tell me that I had only a single factor in the cookie on disk after an authentication process that involved TLS client certs and an off-device OTP.

ericalexander3 7y ago

U2F > TOTP > Any MFA > no MFA Why? About 23% of the classified breaches in this data set are due to compromised valid accounts and any MFA would probably have prevented the breach. Often security isn't about out running the bear, it's about out running the person next to you. data set: https://github.com/ericalexanderorg/SecurityBreach https://github.com/ericalexanderorg/SecurityBreach

tialaramex 7y ago
New systems should implement WebAuthn rather than U2F.

mindslight 7y ago

Real security is hard work, because it requires imposing a burden on users, as well as diligent design to not then squander it. Snake oil is profitable, because you can sell it in place of security while not making the users and developers do that work. "Multi factor authentication" has trickled down into snake oil drip pan. That is what a "soft token" is. That is what text message / email verification is. That is what additional passwords are (eg "what is your favorite high school"). These "solutions" let companies check an "MFA" box with no substantive changes. Not that I want any of these companies pushing "MFA" onto users to insist on more invasive methods either. I like that their bullshit SMS challenge goes to a cloud provider and pops up in a terminal ready to be pasted, because frankly that challenge wasn't wanted by anybody except whomever in their company needed to check that box! It's Sturgeon's / Gresham's law all the way down.